Informationssysteme im Personalmanagement : Architektur, Funktionalität, Anwendung ; [mit Online-Service] [1. Aufl] 9783834803108, 3834803103 [PDF]

Zitiervorschau

Stefan Strohmeier Informationssysteme im Personalmanagement

Stefan Strohmeier

Informationssysteme im Personalmanagement Architektur – Funktionalität – Anwendung Mit 96 Abbildungen STUDIUM

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

1. Auflage 2008 Alle Rechte vorbehalten © Vieweg +Teubner Verlag |GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Sybille Thelen | Andrea Broßler Der Vieweg +Teubner Verlag ist ein Unternehmen von Springer Science+Business Media. www.viewegteubner.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0310-8

Vorwort Personalmanagement ist eine in allen Organisationen auftretende Funktion, deren Kernaufgaben die Bereitstellung und der zielorientierte Einsatz von in abhängiger Stellung beschäftigten Personen ist (vgl. Gaugler et al. 2004, 1663ff.). Bereits seit mehr als einem halben Jahrhundert werden auch im Personalmanagement Informationssysteme eingesetzt, die – einem breiten Verständnis folgend – menschliche und maschinelle Komponenten umfassen und das Ziel der Bereitstellung von Information und Kommunikation nach wirtschaftlichen Kriterien verfolgen (vgl. Wissenschaftliche Kommission WI 1994, 80). Umfang und Tiefe der Anwendung von Informationssystemen im Personalmanagement haben dabei kontinuierlich zugenommen und zu einer inzwischen substantiellen Überlappung beider Bereiche geführt. Dabei ergeben sich durch Informationssysteme für das Personalmanagement sowohl umfangreiche Chancen wie Ernst zu nehmende Risiken (vgl. Strohmeier 2002 und 2004). Der konstruktive Umgang mit Informationssystemen bildet daher eine der aktuellen Herausforderungen des Personalmanagements. In der Folge kommt informationssystembezogenen Qualifikationen im Personalmanagement mittlerweile eine erhebliche Bedeutung zu (vgl. etwa Hempel 2004). Das vorliegende Buch wendet sich daher an Praktiker, Studierende und Dozenten, die grundlegende Kenntnisse auf dem Gebiet personalwirtschaftlicher Informationssysteme erwerben wollen. Dazu wird speziell die aus Sicht des Personalmanagements besonders relevante Softwaredimension von Informationssystemen thematisiert. Aufbauend auf einer Darstellung architektonischer, organisatorischer und rechtlicher Grundlagen werden Architektur, Funktionalität und Anwendung einzelner Systemkategorien in kompakter und einheitlicher Weise dargestellt. Die Ausführungen zielen dabei auf die idealtypischen Gemeinsamkeiten der dargestellten Systemkategorien. Auf spezifische Einzelsysteme und deren konkrete Unterschiede wird entsprechend nicht eingegangen (vgl. dazu Huss 2006 sowie Jessel et al. 2007). Das Buch behandelt weiter speziell solche Systemkategorien, die im Personalmanagement eine besondere Verbreitung und/oder besondere Potenziale aufweisen. Dies impliziert zum einen, dass auch generelle Systemkategorien wie Datenbanksysteme oder Portalsysteme aufgenommen werden, zum anderen stellt das Buch damit eine Auswahl wesentlicher, aber eben nicht aller Systemkategorien des Personalmanagements dar. Die gewählte KategorisieV

Vorwort rung trennt dabei grob zwischen Datenhaltungs-, Anwendungssowie Integrations- und Präsentationssystemen. Die im weiteren verwendete Detailkategorisierung orientiert sich an aktuellen Systemstrukturen und bemüht sich um Konsistenz, ist aber – wie jede andere denkbare Kategorisierung – nicht frei von Überschneidungen. Die zu behandelnde Thematik ist sprachlich durch zahlreiche Anglizismen gekennzeichnet, die – als meist feststehende Begriffe – im Buch unkommentiert übernommen werden. Die meist verwendete männliche Form bezieht sich auf beide Geschlechter. Anke Diederichsen, Franca Piazza, Claudia Thiele und Martin Burgard danke ich für ihre Unterstützung bei der Erstellung des Buches. Frau Thelen und Herrn Schulz vom Vieweg Verlag danke ich für die Übernahme und die redaktionelle Betreuung des Projektes. Die Abbildungen des Lehrbuches können unter www.mis.uni-saarland.de kostenlos herunter geladen werden. Hinweise zur Verbesserung des Buches sind mir willkommen ([email protected]). Ich wünsche mir, dass dieses Buch einen kleinen Beitrag zur Bewältigung der Herausforderungen der Informationstechnik im Personalmanagement leistet.

Saarbrücken, im Oktober 2007

VI

Stefan Strohmeier

Inhaltsverzeichnis TEIL A GRUNDLAGEN 1

Architektonische Grundlagen................................................................................... 3 1.1 Schichtenmodell der Systemarchitektur .......................................................... 3 1.2 Varianten der Makroarchitektur....................................................................... 7 1.2.1 Monolithische Makroarchitektur ........................................................... 7 1.2.2 Modulare Makroarchitektur................................................................... 9 1.2.3 Fragmentierte Makroarchitektur.......................................................... 10 1.2.4 Serviceorientierte Makroarchitektur.................................................... 12

2

Organisatorische Grundlagen................................................................................. 15 2.1 Überblick......................................................................................................... 15 2.2 Systemplanung................................................................................................ 16 2.3 Systembereitstellung ....................................................................................... 18 2.3.1 Systementwicklung .............................................................................. 18 2.3.2 Systembezug ........................................................................................ 20 2.4 Systemimplementierung ................................................................................. 26 2.5 Systembetrieb.................................................................................................. 30 2.6 Systemanwendung.......................................................................................... 30

3

Rechtliche Grundlagen ........................................................................................... 39 3.1 Datenschutz..................................................................................................... 39 3.2 Mitbestimmung ............................................................................................... 46 3.3 Gleichbehandlung .......................................................................................... 49 3.4 Datenübermittlung.......................................................................................... 50 3.5 Lohnbuchhaltung............................................................................................ 51

TEIL B DATENHALTUNGSSYSTEME 4

Datenbanksysteme.................................................................................................. 55 4.1 Architektur und Funktionalität von Datenbanksystemen ............................ 55 4.1.1 Datenbank............................................................................................ 56 4.1.2 Datenbankverwaltungssystem............................................................. 61 4.1.3 Entwicklungswerkzeuge...................................................................... 65 4.2 Anwendung von Datenbanksystemen .......................................................... 66

5

Data Warehouse-Systeme ....................................................................................... 69 5.1 Architektur und Funktionalität von Data Warehouse-Systemen.................. 69 5.1.1 ETL-Komponente................................................................................. 71 VII

Inhaltsverzeichnis 5.1.2 Staging Area ......................................................................................... 74 5.1.3 Datenhaltungskomponente ................................................................. 75 5.1.4 Metadatenbank..................................................................................... 77 5.1.5 Administrationskomponente ............................................................... 78 5.2 Anwendung von Data Warehouse-Systemen ............................................... 79 6

Dokumentenmanagementsysteme ......................................................................... 81 6.1 Architektur und Funktionalität von Dokumentenmanagementsystemen.... 81 6.1.1 Eingabekomponente............................................................................ 82 6.1.2 Ablagekomponente ............................................................................. 85 6.1.3 Ausgabekomponente........................................................................... 86 6.1.4 Administrationskomponente ............................................................... 87 6.1.5 Metadatenbank..................................................................................... 88 6.2 Anwendung von Dokumentenmanagementsystemen ................................. 89

TEIL C ANWENDUNGSSYSTEME 7

Personalbedarfsplanungssysteme........................................................................... 95 7.1 Architektur und Funktionalität von Personalbedarfsplanungssystemen ..... 95 7.1.1 Ereignisdatei......................................................................................... 96 7.1.2 Bedarfsplandatei .................................................................................. 96 7.1.3 Planungskomponente.......................................................................... 97 7.1.4 Analysekomponente .......................................................................... 104 7.2 Anwendung von Personalbedarfsplanungssystemen ................................. 104

8

Personaleinsatzplanungssysteme ......................................................................... 107 8.1 Architektur und Funktionalität von Personaleinsatzplanungssystemen .... 107 8.1.1 Datenhaltungskomponenten............................................................. 108 8.1.2 Planungskomponente........................................................................ 109 8.1.3 Analyse- und Dispositionskomponente ........................................... 116 8.2 Anwendung von Personaleinsatzplanungssystemen.................................. 118

9

Personalentwicklungsplanungssysteme............................................................... 121 9.1 Architektur und Funktionalität von Personalentwicklungsplanungssystemen........................................................................................................ 121 9.1.1 Datenhaltungskomponenten............................................................. 122 9.1.2 Planungskomponente........................................................................ 126 9.1.3 Analyse- und Dispositionskomponente ........................................... 130 9.2 Anwendung von Personalentwicklungsplanungssystemen ....................... 131

10

Personalkostenplanungssysteme.......................................................................... 133 10.1 Architektur und Funktionalität von Personalkostenplanungssystemen .... 133 10.1.1 Datenhaltungskomponente ............................................................... 134 10.1.2 Planungskomponente........................................................................ 135 10.1.3 Administrationskomponente ............................................................. 142

VIII

Inhaltsverzeichnis 10.1.4 Analysekomponente .......................................................................... 142 10.2 Anwendung von Personalkostenplanungssystemen .................................. 143 11

Online Analytical Processing-Systeme................................................................. 145 11.1 Architektur und Funktionalität von OLAP-Systemen.................................. 145 11.1.1 Analysekomponente .......................................................................... 145 11.1.2 Datenhaltungskomponente ............................................................... 151 11.2 Anwendung von OLAP-Systemen................................................................ 154

12

Data Mining-Systeme ............................................................................................ 157 12.1 Architektur und Funktionalität von Data Mining-Systemen....................... 157 12.1.1 Vorgehensmodell............................................................................... 158 12.1.2 Datenzugriffskomponente................................................................. 159 12.1.3 Vorverarbeitungskomponente .......................................................... 159 12.1.4 Analysekomponente .......................................................................... 160 12.1.5 Visualisierungskomponente .............................................................. 163 12.1.6 Analyseprozesskomponente ............................................................. 163 12.1.7 Datenhaltungskomponente ............................................................... 165 12.2 Anwendung von Data Mining-Systemen..................................................... 165

13

Personalabrechnungssysteme............................................................................... 167 13.1 Architektur und Funktionalität von Personalabrechnungssystemen ......... 167 13.1.1 (Mitarbeiter-)Stammdaten.................................................................. 168 13.1.2 Bewegungsdaten................................................................................ 169 13.1.3 Bruttolohnkomponente ..................................................................... 169 13.1.4 Nettolohnkomponente ...................................................................... 171 13.1.5 Abrechnungsdatei .............................................................................. 173 13.1.6 Analyse- und Übermittlungskomponente ........................................ 174 13.2 Anwendung von Personalabrechnungssystemen ....................................... 176

14

Arbeitszeitmanagementsysteme ........................................................................... 179 14.1 Architektur und Funktionalität von Arbeitszeitmanagementsystemen ...... 179 14.1.1 Datenbankkomponente..................................................................... 180 14.1.2 Authentifizierungskomponente......................................................... 181 14.1.3 Zeiterfassungskomponente ............................................................... 183 14.1.4 Zeitplanungskomponente ................................................................. 184 14.1.5 Bewertungskomponente ................................................................... 185 14.1.6 Analysekomponente .......................................................................... 186 14.1.7 Zutrittskomponente ........................................................................... 187 14.1.8 Zusatzkomponenten .......................................................................... 187 14.2 Anwendung von Arbeitszeitmanagementsystemen.................................... 188

15

Zutrittsmanagementsysteme ................................................................................. 191 15.1 Architektur und Funktionalität von Zutrittsmanagementsystemen............ 191 15.1.1 Datenbankkomponente..................................................................... 193 IX

Inhaltsverzeichnis 15.1.2 Authentifizierungskomponente......................................................... 194 15.1.3 Steuerungskomponente..................................................................... 194 15.1.4 Analysekomponente .......................................................................... 197 15.2 Anwendung von Zutrittsmanagementsystemen.......................................... 197 16

Beschaffungsmanagementsysteme....................................................................... 201 16.1 Architektur und Funktionalität von Beschaffungsmanagementsystemen . 201 16.1.1 Datenhaltungskomponente ............................................................... 202 16.1.2 Administrationskomponente ............................................................. 204 16.1.3 Kommunikationskomponente........................................................... 205 16.1.4 Assessmentkomponente.................................................................... 208 16.1.5 Analysekomponente .......................................................................... 209 16.2 Anwendung von Beschaffungsmanagementsystemen ............................... 211

17

Testsysteme ........................................................................................................... 215 17.1 Architektur und Funktionalität von Testsystemen...................................... 215 17.1.1 Datenhaltungskomponenten............................................................. 216 17.1.2 Profilerstellungskomponente ............................................................ 217 17.1.3 Entwicklungskomponente................................................................. 217 17.1.4 Dispositionskomponente .................................................................. 218 17.1.5 Instruktionskomponente ................................................................... 219 17.1.6 Durchführungskomponente.............................................................. 219 17.1.7 Analysekomponente .......................................................................... 220 17.1.8 (Probanden-)Anwenderschnittstelle ................................................. 222 17.2 Anwendung von Testsystemen.................................................................... 223

18

Szenariosysteme .................................................................................................... 225 18.1 Architektur und Funktionalität von Szenariosystemen............................... 225 18.1.1 Datenhaltungskomponenten............................................................. 226 18.1.2 Durchführungskomponente.............................................................. 226 18.1.3 Instruktionskomponente ................................................................... 230 18.1.4 Diagnosekomponente ....................................................................... 231 18.1.5 (Probanden-)Anwenderschnittstelle ................................................. 232 18.2 Anwendung von Szenariosystemen............................................................. 233

19

Computer Based Training-Systeme...................................................................... 235 19.1 Architektur und Funktionalität von CBT-Systemen .................................... 235 19.1.1 Lernobjektdatenbank ......................................................................... 236 19.1.2 Metadatenbank................................................................................... 240 19.1.3 Präsentationskomponente ................................................................. 240 19.1.4 Lernprozesssteuerungskomponente ................................................. 241 19.1.5 Kommunikationskomponente........................................................... 243 19.2 Anwendung von CBT-Systemen .................................................................. 244

X

Inhaltsverzeichnis 20

Learning Management-Systeme............................................................................ 247 20.1 Architektur und Funktionalität von Learning Management-Systemen ...... 247 20.1.1 Administrationsdatenbank................................................................. 249 20.1.2 Content-Datenbank............................................................................ 251 20.1.3 Administrationskomponente ............................................................. 252 20.1.4 Lernprozesssteuerungskomponente ................................................. 256 20.1.5 Autorenkomponente.......................................................................... 256 20.1.6 Kommunikationskomponente........................................................... 257 20.1.7 Analysekomponente .......................................................................... 259 20.1.8 Anwenderschnittstelle ....................................................................... 260 20.2 Anwendung von Learning Management-Systemen .................................... 260

21

Performance Management-Systeme ..................................................................... 263 21.1 Architektur und Funktionalität von Performance Management-Systemen 263 21.1.1 Datenhaltungskomponenten............................................................. 264 21.1.2 Administrationskomponente ............................................................. 266 21.1.3 Zielfestlegungskomponente .............................................................. 267 21.1.4 Beurteilungskomponente .................................................................. 269 21.1.5 Analysekomponente .......................................................................... 271 21.2 Anwendung von Performance Management-Systemen ............................. 272

22

Vergütungsmanagementsysteme.......................................................................... 275 22.1 Architektur und Funktionalität von Vergütungsmanagementsystemen .... 275 22.1.1 Datenhaltungskomponenten............................................................. 276 22.1.2 Stellenbewertungskomponente......................................................... 279 22.1.3 Leistungsbeurteilungskomponente ................................................... 280 22.1.4 Budgetierungskomponente............................................................... 280 22.1.5 Vergütungsplanungskomponente..................................................... 282 22.1.6 Verwaltungskomponente .................................................................. 285 22.1.7 Analysekomponente .......................................................................... 286 22.2 Anwendung von Vergütungsmanagementsystemen .................................. 286

23

Enterprise Resource Planning-Systeme................................................................ 289 23.1 Architektur und Funktionalität von ERP-Systemen..................................... 289 23.1.1 Datenhaltungskomponente ............................................................... 291 23.1.2 Applikationskomponente .................................................................. 295 23.1.3 Workflowkomponente ...................................................................... 296 23.1.4 Implementationskomponente ........................................................... 298 23.1.5 Administrationskomponente ............................................................. 299 23.2 Anwendung von ERP-Systemen .................................................................. 300

TEIL D INTEGRATIONS- UND PRÄSENTATIONSSYSTEME 24

Business Process Management-Systeme.............................................................. 305 24.1 Architektur und Funktionalität von BPM-Systemen ................................... 305 XI

Inhaltsverzeichnis 24.1.1 Datenhaltungskomponenten............................................................. 306 24.1.2 Prozessdesignkomponente................................................................ 307 24.1.3 Prozessanalysekomponente .............................................................. 311 24.1.4 Prozess-Engine und Integrationsdienste .......................................... 312 24.2 Anwendung von BPM-Systemen ................................................................. 314 25

Portalsysteme......................................................................................................... 317 25.1 Architektur und Funktionalität von Portalsystemen ................................... 317 25.1.1 Integrations- und Transaktionskomponente .................................... 318 25.1.2 Portalbasisdienste .............................................................................. 319 25.1.3 Portalanwendungen........................................................................... 321 25.1.4 Bereitstellungskomponente............................................................... 323 25.2 Anwendung von Portalsystemen ................................................................. 324

26

Voice Response-Systeme ...................................................................................... 329 26.1 Architektur und Funktionalität von Voice Response-Systemen................. 329 26.1.1 Sprachanwenderschnittstelle............................................................. 330 26.1.2 Spracherkennungskomponente ........................................................ 331 26.1.3 Sprachausgabekomponente .............................................................. 332 26.1.4 Ablaufsteuerung................................................................................. 333 26.1.5 Serviceskomponente.......................................................................... 334 26.1.6 Grafische Anwenderschnittstelle....................................................... 335 26.2 Anwendung von Voice Response-Systemen............................................... 335

27

Service Center-Systeme......................................................................................... 339 27.1 Architektur und Funktionalität von Service Center-Systemen ................... 339 27.1.1 Datenhaltungskomponenten............................................................. 340 27.1.2 Kommunikationskomponente........................................................... 341 27.1.3 Ablaufsteuerungskomponente .......................................................... 344 27.1.4 Analysekomponente .......................................................................... 347 27.2 Anwendung von Service Center-Systemen ................................................. 348

28

Browsersysteme .................................................................................................... 351 28.1 Architektur und Funktionalität von Browsersystemen............................... 351 28.1.1 Ablaufsteuerung und WWW-Komponente ...................................... 352 28.1.2 Autorenkomponente.......................................................................... 356 28.1.3 Kommunikationskomponente........................................................... 356 28.1.4 Multimediakomponente .................................................................... 358 28.1.5 Anwenderschnittstelle ....................................................................... 358 28.2 Anwendung von Browsersystemen............................................................. 359

Literaturverzeichnis ....................................................................................................... 363 Schlagwortverzeichnis................................................................................................... 381

XII

Abkürzungsverzeichnis AGG API ASCII ASP ASR ATS AZM BAV BDE BDP BDSG BetrVG BHE BI BPD BPEL BPM BPMN BPO BSC BZE CBT CPM CRISP-DM CRM CSCW CSCL CTI DEÜV DMS DQL DWS EAI e-HRM EIC EIP EPK ERP

Allgemeines Gleichbehandlungsgesetz Application Programming Interface American Standard Code for Information Interchange Application Service Providing Automatic Speech Recognition Applicant Tracking System Arbeitszeitmanagement Betriebliche Altersvorsorge Betriebsdatenerfassung Bund Deutscher Psychologen Bundesdatenschutzgesetz Betriebsverfassungsgesetz Bundesverband der Hersteller- und Errichterfirmen von Sicherheitssystemen Business Intelligence Business Process Diagramm Business Process Execution Language Business Process Management Business Process Modelling Notation Business Process Outsourcing Balanced Scorecard Basiszeiteinheit Computer Based Training Corporate Performance Management Cross Industry Standard Process for Data Mining Customer Relationship Management Computer Supported Cooperative Work Computer Supported Cooperative Learning Computer Telephony Integration Verordnung über die Erfassung und Übermittlung von Daten für die Träger der Sozialversicherung Dokumentenmanagementsystem Data Query Language Data Warehouse-System Enterprise Application Integration Electronic Human Resource Management Employee Interaction Center Enterprise Information Portal Ereignisgesteuerte Prozesskette Enterprise Resource Planning XIII

Abkürzungsverzeichnis ES ESB EStG ETL EU FA FASMI FiBu FS FTE GDPdU GKV GoBS GUI HCM HOLAP HR HRM HTML ITS ITSG ID IT IVR KDD KPI KiStG KVP KW LMCS LOM LMS MDX MOLAP ODS OLAP OLTP PEP PS RFID ROLAP SCORM XIV

Enterprise System Enterprise Service Bus Einkommenssteuergesetz Extraktion, Transformation und Laden Europäische Union Fachabteilung Fast Analysis of Shared Multidimensional Information Finanzbuchhaltung Fremdschlüssel Full Time Equivalent Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen Gesetzliche Krankenversicherung Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme Graphical User Interface Human Capital Management Hybrid Online Analytical Processing Human Resource Human Resource Management Hypertext Markup Language Intelligente Tutorielle Systeme Informationstechnische Servicestelle der gesetzlichen Krankenversicherungen Identifizierung(snummer) Informationstechnik Interactive Voice Response Knowledge Discovery in Databases Key Performance Indicator Kirchensteuergesetz Kontinuierlicher Verbesserungsprozess Kalenderwoche Learning Content Management-Systeme Learning Objects Metadata Learning Management-Systeme Multidimensional Expressions Multidimensional Online Analytical Processing Operational Data Store Online Analytical Processing Online Transaction Processing Personaleinsatzplanungssysteme Primärschlüssel Radio Frequency Identification Relational Online Analytical Processing Sharable Content Object Reference Model

Abkürzungsverzeichnis SMS SOA SolZG SprAuG SSC SSO SQL TRM TTS VLE VUI WAP WBT WFM(S) WSDL WWW XML

Short Message Service Serviceorientierte Architektur Solidaritätszuschlagsgesetz Sprecherausschussgesetz Shared Service Center Single Sign On Structured Query Language Talent Relationship Management Text to Speech Virtual Learning Environment Voice User Interface Wireless Application Protocol Webbased Training Workforce Management (System) Web Service Description Language World Wide Web Extensible Markup Language

XV

Abbildungsverzeichnis Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb.

1.1: 1.2: 1.3: 1.4: 1.5: 2.1: 2.2: 2.3: 2.4: 2.5: 4.1: 4.2: 4.3: 4.4: 4.5: 4.6: 5.1: 5.2: 5.3: 5.4: 5.5: 6.1: 6.2: 6.3: 7.1: 7.2: 7.3: 7.4: 7.5: 7.6: 7.7: 8.1: 8.2: 8.3: 8.4: 8.5: 9.1: 9.2: 9.3: 9.4:

Logische Schichten und physische Strukturen der Systemarchitektur........ 5 Monolithische Makroarchitektur ................................................................... 8 Modulare Makroarchitektur ........................................................................... 9 Fragmentierte Makroarchitektur.................................................................. 11 Serviceorientierte Makroarchitektur ............................................................ 13 Informationssystembezogene Aktivitäten................................................... 15 Application Service Providing ..................................................................... 22 Self Service ................................................................................................... 32 Mehrstufiges Anwendungsmodell............................................................... 35 Outsourcing.................................................................................................. 36 Idealtypische Architektur von Datenbanksystemen .................................. 55 Datenorganisation ........................................................................................ 57 Tabellen im relationalen Datenbankmodell............................................... 59 Datenwürfel im multidimensionalen Datenmodell.................................... 60 Spezifikation und Ergebnis einer Standardabfrage mit SQL ..................... 63 Standardabfrage vs. Kreuztabellenabfrage ................................................ 64 Idealtypische Architektur von Data Warehouse-Systemen ....................... 69 Data Warehouse Architekturvarianten........................................................ 70 Prozesse der ETL-Komponente................................................................... 72 Schichten der Datenhaltungskomponente ................................................. 75 Multidimensionaler Datenwürfel................................................................. 76 Idealtypische Architektur von Dokumentenmanagementsystemen ......... 81 Prozess der Eingabe..................................................................................... 82 Multihierarchische Dokumentenstruktur einer digitalen Personalakte..... 89 Idealtypische Architektur von Personalbedarfsplanungssystemen ........... 95 Teilschritte der Planungskomponente ........................................................ 97 Vergangenheitsbasiertes Ereignistagesmuster ............................................ 99 Simulationsbasierte Ereignisplanung ........................................................ 100 Organisationsorientierte Ereignisplanung ................................................ 101 Geschäftsprozessbasierte Personalbedarfsplanung.................................. 102 Nivellierung geplanter Personalbedarfe ................................................... 103 Idealtypische Architektur von Personaleinsatzplanungssystemen.......... 107 Schichtplanung........................................................................................... 111 Optimierte Mehrschichtlösung .................................................................. 113 Schichtfolgenplanung ................................................................................ 114 Zuordnung von Mitarbeitern zu Schichtfolgen ........................................ 116 Idealtypische Architektur von Personalentwicklungsplanungssystemen 121 Beispiel einer Laufbahn............................................................................. 124 Nachfolgeplan ............................................................................................ 126 Profilvergleich ............................................................................................ 129 XVII

Abbildungsverzeichnis Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. XVIII

10.1: 10.2: 10.3: 10.4: 10.5: 10.6: 11.1: 11.2: 11.3: 11.4: 11.5: 11.6: 11.7: 12.1: 12.2: 12.3: 12.4: 13.1: 13.2: 14.1: 15.1: 15.2: 16.1: 16.2: 16.3: 17.1: 17.2: 17.3: 18.1: 18.2: 18.3: 19.1: 19.2: 19.3: 20.1: 21.1: 21.2: 21.3: 21.4: 22.1: 23.1: 23.2: 23.3:

Idealtypische Architektur von Personalkostenplanungssystemen .......... 133 Kostenarten der Personalkostenplanung.................................................. 136 Basisdaten modellbasierter Hochrechnung.............................................. 138 Abbildung des Planungszeitraums durch Basiszeiteinheiten .................. 139 Kostenplanung mittels Zeitreihenanalyse................................................. 140 Simulationsmodell zur Personalkostenplanung ....................................... 141 Idealtypische Architektur von OLAP-Systemen........................................ 145 Multidimensionale Datenanalyse .............................................................. 147 Multidimensionale Datenanalyse (»Slicing«) ............................................. 148 Multidimensionale Datenanalyse (»Dicing«) ............................................. 148 Aggregierende Datenanalyse (»Roll Up«).................................................. 149 Disaggregierende Datenanalyse (»Drill Down«) ....................................... 150 Starschema im ROLAP ............................................................................... 152 Idealtypische Architektur von Data Mining-Systemen............................. 157 Zentrale Analysearten des Data Mining.................................................... 160 Klassifikationsbaum und Regeln ............................................................... 161 Analyseprozess im Data Mining................................................................ 164 Idealtypische Architektur von Personalabrechnungssystemen ............... 167 Schema der Bruttoentgeltermittlung ......................................................... 170 Idealtypische Architektur von Arbeitszeitmanagementsystemen............ 179 Idealtypische Architektur von Zutrittsmanagementsystemen.................. 191 Ausgestaltung einer Zutrittsstelle .............................................................. 195 Idealtypische Architektur von Beschaffungsmanagementsystemen ....... 201 Zentrale Funktionen der Bewerberanalyse .............................................. 210 Funktionen und Ausprägungen des TRM ................................................ 213 Idealtypische Architektur von Testsystemen............................................ 215 Mögliche Testkonfigurationen................................................................... 219 Vergleich von Ergebnis- und Anforderungsprofil.................................... 220 Idealtypische Architektur von Szenariosystemen .................................... 225 Formale Szenariostruktur........................................................................... 227 Zeitlicher Szenarioablauf ........................................................................... 228 Idealtypische Architektur von CBT-Systemen.......................................... 235 Modularer Aufbau von Lerninhaltsebenen............................................... 238 Adaptiver Ablauf eines Kurses .................................................................. 242 Idealtypische Architektur von Learning Management-Systemen ............ 247 Idealtypische Architektur von Performance Management-Systemen ..... 263 Zyklischer Ablauf eines Beurteilungsprozesses ....................................... 267 Kaskadierung von Zielen .......................................................................... 268 Gewichtete ordinale Einstufung................................................................ 270 Idealtypische Architektur von Vergütungsmanagementsystemen .......... 275 Idealtypische Architektur von ERP-Systemen .......................................... 289 Ausgewählte Referenzdatensegmente ...................................................... 292 Bereichsübergreifende Datenintegration.................................................. 293

Abbildungsverzeichnis Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb. Abb.

23.4: 23.5: 24.1: 24.2: 24.3: 25.1: 25.2: 25.3: 26.1: 27.1: 28.1: 28.2: 28.3:

Datentemporalisierung .............................................................................. 294 Ausschnitt eines Referenzprozesses in der Personalbeschaffung ........... 297 Idealtypische Architektur von BPM-Systemen ......................................... 305 Fachliche Prozessspezifikation (»EPK«)..................................................... 308 Fachlich-technische Prozessspezifikation (»BPMN«) ................................ 309 Idealtypische Architektur von Portalsystemen ......................................... 317 Portlet-Struktur einer Portalseite im Browsersystem................................ 324 Anwendungsfunktionen und -bereiche eines Mitarbeiterportals............ 327 Idealtypische Architektur von Voice Response-Systemen....................... 329 Idealtypische Architektur von Service Center-Systemen ......................... 339 Idealtypische Architektur von Browsersystemen..................................... 351 Interaktion von Browser- und Anwendungssystem ................................ 355 Aufteilung des Browserfensters in Frames ............................................... 359

XIX

Teil A Grundlagen

1

Architektonische Grundlagen Die Funktionalität sowie die darauf basierenden Anwendungsmöglichkeiten von Informationssystemen im Personalmanagement ergeben sich zentral aus der Architektur einzelner Systeme und der Architektur ganzer Portfolios unterschiedlicher Systeme. Im Folgenden werden daher ein Schichtenmodell zur Strukturierung von Systemarchitekturen sowie idealtypische Varianten der Systemarchitektur vorgestellt.

1.1

Schichtenmodell der Systemarchitektur

Begriff

Der Begriff der Architektur zielt regelmäßig auf die Struktur eines Systems und damit auf seine Komponenten und deren Beziehungen (vgl. etwa Krcmar 1990). Der Architekturbegriff kann dabei auf unterschiedliche Objekte wie Hardware, Software, Prozesse etc. angewendet werden. Entsprechend der hier intendierten Beschäftigung mit der Softwaredimension von Informationssystemen wird unter Systemarchitektur im Folgenden die Struktur von Softwaresystemen bestehend aus einzelnen Softwarekomponenten und deren Beziehungen verstanden. Die Systemarchitektur bezieht sich damit sowohl auf die interne Struktur eines Einzelsystems (Mikroarchitektur) als auch auf die Struktur eines Portfolios unterschiedlicher Einzelsysteme (Makroarchitektur). Diese Unterscheidung in Mikro- und Makroarchitektur hängt allerdings sensibel von der Definition eines »Einzelsystems« ab. Ob eine gegebene Softwareeinheit als Komponente eines Einzelsystems, als Einzelsystem oder als Portfolio mehrerer Einzelsysteme zu gelten hat, kann dabei je nach Perspektive und konkreten Softwareeinheiten durchaus unterschiedlich gesehen werden. In einer pragmatischen Festlegung wird im Folgenden dann von einem Einzelsystem ausgegangen, wenn die entsprechende Softwareeinheit eigenständig ablauffähig ist und im Falle des Fremdbezugs (vgl. Kap. 2) am Markt auch isoliert beschafft werden kann. Andernfalls liegt eine Komponente eines Einzelsystems vor.

Beschreibungen

Systemarchitekturen können aus unterschiedlichen Perspektiven und für unterschiedliche Zwecke beschrieben werden. In der Folge können Beschreibungen derselben Systemarchitektur sehr unterschiedlich ausfallen. Dies bezieht sich nicht lediglich auf unterschiedliche Abstraktionsebenen der Beschreibung, wie etwa 3

1

Architektonische Grundlagen der Beschreibung einer Datenkomponente auf konkreter Datenfeldebene oder auf abstrakterer Dateiebene, sondern auf faktisch unterschiedliche Arten der Architekturbeschreibung. Entsprechend der individuellen Zwecksetzung existieren daher stets mehrere verschiedene zulässige und sinnvolle Beschreibungen derselben Architektur (vgl. Zachman 1987 und Krcmar 1990). Zur Beschreibung von Architekturen existiert inzwischen ein größerer Fundus an Vorgehensmodellen und Methoden (vgl. zu einem Überblick Sinz 1997 und Schönherr 2006). Diese zielen i.d.R. auf den Entwurf konkreter Einzelarchitekturen und erbringen entsprechend feingranulare Beschreibungen von Architekturen. Für den hier angestrebten Zweck einer eher grob-granularen Beschreibung gemeinsamer Eigenschaften von Systemkategorien fallen diese Beschreibungsmethoden i.d.R. deutlich zu detailliert aus.

Schichtenmodell

4

Als Strukturierungshilfe zur Beschreibung realer Systemarchitekturen wird daher ein einfaches Modell aus vier logischen Schichten (Ebene, »Layer«, »Tier«) herangezogen. Konkret werden gemäß einer klassischen dreistufigen Architektur zunächst ƒ die Datenhaltungsschicht, ƒ die Anwendungsschicht und ƒ die Präsentationsschicht unterschieden (vgl. etwa Dunkel & Holitschke 2003, 16ff.). Insbesondere zur adäquaten Beschreibung heterogener Makroarchitekturen wird zusätzlich ƒ die Integrationsschicht als fakultative Schicht zwischen Anwendungs- und Präsentationsschicht mit aufgenommen. Die Schichten korrespondieren dabei mit den von einem einzelnen System bzw. von einem Systemportfolio grundsätzlich bereitzustellenden Diensten. Einzelne Schichten bauen aufeinander auf. Die jeweils übergelagerte Schicht greift dabei auf Dienste bzw. Ergebnisse der jeweils vorgelagerten Schicht zu. Als Basisschicht dient die Datenhaltungsschicht (»Data[base] Layer«, Persistenzschicht, »Persistence Layer«) der Abspeicherung, Verwaltung und (Wieder-)Bereitstellung persistenter Daten des Systems. Diese können sowohl aus codierten (Buchstaben, Zahlen, Sonderzeichen) als auch aus uncodierten (Grafiken, Audio- und Videodokumenten) Daten bestehen. Die Anwendungsschicht (Verarbeitungslogik, Anwendungskern, Geschäftslogik, »Application Layer«) realisiert sämtliche fachliche Funktionalitäten eines Systems. Dazu greift sie auf Dienste der Datenhaltungsschicht zurück. Speziell werden Daten von der Datenhaltungsschicht zur Verarbeitung im Rahmen der Funktionser-

1.1

Schichtenmodell der Systemarchitektur

füllung abgerufen und Ergebnisse der Verarbeitung wieder in der Datenhaltungsschicht abgelegt. Die Integrationsschicht (»Middleware Layer«, »Integration Layer«) erbringt insbesondere im Rahmen heterogener Makroarchitekturen die Dienstleistung der Kommunikation zwischen ansonsten isolierten Einzelsystemen bzw. Komponenten der Anwendungsschicht. Sie sorgt für Funktionsaufrufe in diesen Systemen und steuert den Transport von Daten im Rahmen von system- bzw. komponentenübergreifenden Transaktionen. Eine Integrationsschicht ist insofern eine fakultative Schicht einer Architektur, als sie nur bei einer heterogenen Ausgestaltung der Anwendungsschicht und/oder der Datenhaltungsschicht mit mehreren, per se nicht kompatiblen Einzelsystemen notwendig bzw. sinnvoll ist. Die Präsentationsschicht zielt als Anwenderoberfläche (»[Graphical] User Interface [GUI]«) auf die Interaktion zwischen Anwender und den Anwendungen. Sie bietet daher alle Funktionalitäten, die ein Anwender zum Arbeiten am System speziell bei der Erstellung von Eingaben und dem Empfang von Ausgaben benötigt. Eine schichtorientierte Systemarchitektur kann zunächst durch ein Einzelsystem realisiert werden. Gerade die Aufteilung in Schichten ermöglicht es aber auch, einzelne Dienste auf verschiedene Systeme zu verteilen. Die konkrete Art der Realisierung kommt dabei in der vertikalen und horizontalen Struktur einer Systemarchitektur zum Ausdruck (vgl. Abb. 1.1). horizontale Struktur Präsentationsschicht (Integrationsschicht) Systemarchitektur Anwendungsschicht

vertikale Struktur

Realisierung

Datenhaltungsschicht

Abb. 1.1: Logische Schichten und physische Strukturen der Systemarchitektur Die vertikale Struktur einer Architektur zeigt dabei auf, wie ein oder mehrere Systeme über die architektonischen Schichten hinweg angeordnet sind. In diesem Zusammenhang sind 5

1

Architektonische Grundlagen ƒ schichtübergreifende Systeme und ƒ schichtspezifische Systeme zu unterscheiden. Schichtübergreifende Systeme bieten simultan Dienste mehrerer architektonischer Schichten. Zahlreiche Einzelsysteme im Personalmanagement sind als schichtübergreifende Systeme konzipiert. Entsprechend werden von solchen Systemen regelmäßig die Dienste der Datenhaltung, Anwendung und Präsentation durch korrespondierende Komponenten integriert angeboten. Da solche Einzelsysteme notwendigerweise daten- und funktionsintegriert konzipiert sind, ist keine eigenständige Integrationsschicht notwendig. Im Sinne der vertikalen Systemarchitektur können aber alternativ oder additiv ein oder mehrere schichtspezifische Systeme Anwendung finden. Schichtspezifische Systeme bieten ausschließlich Dienste einer einzigen architektonischen Schicht. Beispielsweise ist die Auslagerung der Datenhaltungsdienste in eigenständige Datenbanksysteme (vgl. Kap. 4) inzwischen weit verbreitet. Das Datenbanksystem fungiert in dieser Architektur dann als schichtspezifisches Datenhaltungssystem, während die Dienste der Anwendung und Präsentation beim entsprechenden Personalsystem bleiben. In analoger Weise werden im Rahmen webbasierter Anwendungen die Dienste der Präsentationsschicht an Browsersysteme (vgl. Kap. 28) ausgelagert. Das Browsersystem fungiert in dieser Architektur dann als schichtspezifisches Präsentationssystem, während die Dienste der Anwendungs- und Datenhaltungsschicht beim entsprechenden Anwendungssystem verbleiben. Neben der damit angedeuteten Kombination von schichtübergreifenden und schichtspezifischen Systemen kann die vertikale Struktur auch ausschließlich aus schichtspezifischen Systemen bestehen. Dabei kann die Zuordnung eines Systems zu einer architektonischen Schicht auch von der Art der Anwendung abhängen. Wird ein Datenbanksystem zur Datenhaltung eines Anwendungssystems verwendet, wäre es als schichtspezifisch einzustufen. Wird dasselbe Datenbanksystem zur Verwaltung von Personaldaten eingesetzt, läge ein schichtübergreifendes System vor. Die inzwischen häufige Anwendung und daraus resultierende Bedeutung schichtspezifischer Systeme im Rahmen personalwirtschaftlicher Systemarchitekturen bedingt im Folgenden, dass neben spezifischen Personalsystemen (Teil C) auch nicht-spezifisch auf das Personalmanagement ausgerichtete Systeme zur Datenhaltung (Teil B) sowie zur Integration und Präsentation (Teil D) dargestellt werden. Korrespondierend mit der vertikalen Struktur zeigt die horizontale Struktur einer Architektur entsprechend die Anordnung eines

6

1.2

Varianten der Makroarchitektur

oder mehrer Systeme bezogen auf die jeweilige architektonische Schicht. Auch in horizontaler Hinsicht kann ein Dienst durch ein oder mehrere Systeme erbracht werden. Beispielsweise ist es möglich, die Dienste der Datenhaltungsschicht ausschließlich durch die Datenhaltungskomponente eines Personalsystems bzw. durch ein einziges Datenbanksystem zu realisieren. Ebenso ist es möglich, mehrere Datenhaltungskomponenten verschiedener Personalsysteme bzw. mehrere Datenbanksysteme zur Realisierung der Datenhaltungsdienste zu verwenden. Analoges gilt für weitere Schichten. Etwa kann die Anwendungsschicht durch ein umfassendes Enterprise Resource Planning-System (vgl. Kap. 23) oder aber mehrere verschiedene Systeme realisiert werden. Werden zur Realisierung von Diensten der Datenhaltungs- und/oder Anwendungsschicht in der horizontalen Struktur mehrere Einzelsysteme parallel eingesetzt, können diese integriert, aber auch nicht integriert sein. Der letztere Fall horizontal nicht integrierter, heterogener Datenhaltungs- und/oder Anwendungsschichten macht die Etablierung einer zusätzlichen Integrationsschicht notwendig bzw. zumindest sinnvoll. Hier werden entsprechend zumeist schichtspezifische Integrationssysteme wie etwa Portalsysteme (vgl. Kap. 25) angeordnet, um dem Anwender einen einheitlichen und integrierten Zugriff auf physisch heterogene nachgelagerte Schichten zu ermöglichen.

1.2

Varianten der Makroarchitektur Diese unterschiedlichen Ausgestaltungsmöglichkeiten vertikaler und horizontaler Strukturen führen zu einer heterogenen Vielfalt faktischer Systemarchitekturen. Mit ƒ der monolithischen Architektur, ƒ der modularen Architektur, ƒ der fragmentierten Architektur und ƒ der serviceorientierten Architektur werden im Folgenden idealtypische Varianten einer Makroarchitektur vorgestellt. Auf die Mikroarchitektur einzelner Systemkategorien wird in den jeweiligen Kapiteln eingegangen.

1.2.1

Monolithische Makroarchitektur

Struktur

Die monolithische Architektur realisiert alle benötigten Dienste mit einem einzigen schichtübergreifenden System und bildet damit die Minimalvariante der Realisierung einer personalwirtschaftlichen Systemarchitektur. Datenhaltungs-, Anwendungsund Präsentationsschicht werden dabei in einem einzelnen Sys7

1

Architektonische Grundlagen tem realisiert. Die Anwendungsschicht stellt dabei alle personalwirtschaftlichen Funktionalitäten zur Verfügung. Da solche Systeme bereits daten- und funktionsintegriert konzipiert sind, ist die Realisierung einer eigenen Integrationsschicht nicht notwendig (vgl. Abb. 1.2). Präsentationsschicht Anwendungsschicht

Monolith

Datenhaltungsschicht

Abb. 1.2: Monolithische Makroarchitektur Besteht eine Architektur eines Unternehmens ausschließlich aus einem einzigen monolithischen System, fallen Makro- und Mikroarchitektur notwendigerweise zusammen. Monolithische Systeme gestalten sich entsprechend häufig umfangreich und komplex, was entsprechende Probleme für die Implementierung und Anwendung solcher Systeme mit sich bringt. Um auch eine partielle Einführung und Anwendung zu ermöglichen, kann teilweise eine virtuelle Modularisierung des monolithischen Systems durchgeführt werden. Eine virtuelle Modularisierung erlaubt die (sukzessive) Implementierung und Anwendung einzelner Teilfunktionalitäten des Systems. Dazu werden die nicht benötigten Funktionalitäten der Anwendungsschicht sowie damit korrespondierende Teile der Datenhaltungs- und Präsentationsschicht gesperrt. Gleichwohl ist stets das ganze System, also auch die jeweils gesperrten Teile, auf den Rechnern installiert. Für das anwendende Unternehmen entspricht dies einer Modularisierung, die allerdings in dem Sinne virtuell ist, als dass i.S.d. physischen Systemstrukturen keine modularisierte Architektur vorliegt. Verbreitung

8

Empirische Studien zur Verbreitung der monolithischen Architektur sind derzeit nicht bekannt. Allerdings waren klassische »Personalinformationssysteme« regelmäßig als monolithische Einzelsysteme realisiert. Typischerweise werden dabei Datenbank, Modell- und Methodenbank sowie Anwenderschnittstelle als Komponenten aufgeführt (vgl. etwa Domsch 1980), was erkennbar den einzelnen Schichten entspricht. Solche Systeme dürften insbesondere als seinerzeit selbst erstellte Alt-Systeme (»Legacy Systems«) eine gewisse Bedeutung besitzen. Ebenso können manche Enterprise Resource Planning-Systeme (vgl. Kap. 23) zur Realisierung einer monolithischen Systemarchitektur herangezogen werden. Beide Systemkategorien existieren zwar nach wie vor, dürf-

1.2

Varianten der Makroarchitektur

ten jedoch meist durch weitere Systeme ergänzt werden, so dass eine wirklich monolithische Architektur inzwischen sehr selten sein dürfte.

1.2.2

Modulare Makroarchitektur

Strukturen

Um die Vorteile einer Modularisierung nutzen zu können, besteht eine zweite vorfindbare Variante in der modularen Makroarchitektur. Modularisierung bedeutet dabei die Strukturierung eines Systems in kleinere, (teil-)autonome Subsysteme, die Module. Ein Modul besteht dabei generell aus einem Modulrumpf, der die entsprechenden Dienste bereitstellt, und einer Modulschnittstelle, über die das Modul mit anderen Modulen kommuniziert. Modulare Architekturen kombinieren entsprechend (physisch separierbare) Module über einheitliche Schnittstellen, wobei auch nur ein Modul eingesetzt werden kann. Zahlreiche der in den Teilen C. und D. dargestellten Einzelsysteme können daher auch als Modul ausgeführt sein. Da modulare Architekturen damit schon definitionsgemäß funktions- und datenintegriert sind, bedarf es keiner expliziten Integrationsschicht. Abb. 1.3 deutet das Beispiel einer modularen Architektur mit vertikal separierter Datenhaltungs- und Präsentationsschicht an.

Präsentationsschicht

Anwendungsschicht

WWW

Modul1

Datenhaltungsschicht

Modul2

Modul..

DBS

Abb. 1.3: Modulare Makroarchitektur Je nach in der Anwendungsschicht implementierten Modulen müssen Datenbanksystem und Browser-Oberfläche entsprechend angepasst werden. Modulare Architekturen bieten damit den Vorteil, dass aus einem Gesamtangebot an Modulen lediglich die faktisch benötigten angewendet werden müssen. Ebenso ist es möglich, einzelne Module sukzessive zu einer bestehenden Architektur hinzuzufügen.

9

1

Architektonische Grundlagen

Verbreitung

Einschlägige empirische Ergebnisse zur Verbreitung modularer Architekturen existieren derzeit nicht. Allerdings greifen aufgrund der genannten Vorteile insbesondere Hersteller personalwirtschaftlicher Standardsoftware für ihre Produkte oft auf eine modulare Architektur zurück. Unter neuer Begrifflichkeit unbekannter Haltbarkeit wie Talent Management-Systeme und teils auch Human Capital Management (HCM)-Systeme werden derzeit insbesondere strategisch relevante personalwirtschaftliche Anwendungen in modularer Architektur angeboten. Basierend auf einem datenhaltenden Modul (Personalinformationssystem i.e.S. vgl. Kap. 4) umfassen solche Angebote häufig Module zur Entwicklungsplanung (vgl. Kap. 9) sowie zum Beschaffungs- (vgl. Kap. 16), Learning- (vgl. Kap. 20), Performance- (vgl. Kap. 21) und Vergütungsmanagement (vgl. Kap. 22). Teilweise werden diese Angebote auch um administrative Funktionalitäten etwa im Bereich Personalabrechnung (vgl. Kap. 13) und Arbeitszeitmanagement (vgl. Kap. 14) ergänzt. Zunehmend findet hierfür der »Suite«-Begriff (»HCM Suite« oder »Talent Management Suite«) Anwendung, um die umfassende und integrierte Abdeckung zentraler personalwirtschaftlicher Funktionalitäten hervorzuheben. Allerdings liegen dabei entgegen der Herstellerdiktion teils auch virtuelle Modularisierungen faktisch monolithischer Systeme vor. Aufgrund enger funktionaler Abhängigkeiten werden als weiteres Beispiel häufig auch Systeme zur Bedarfsplanung (vgl. Kap. 7), zur Einsatzplanung (vgl. Kap. 8) und zum Arbeitszeitmanagement (vgl. Kap. 14) als modularer Verbund angeboten. Auch hierfür wird mit Workforce Management-System häufig ein (zu weit gefasster) Anglizismus verwendet. Entsprechend kommt der modularen Architektur im Personalmanagement durchaus Bedeutung zu.

1.2.3

Fragmentierte Makroarchitektur

Strukturen

Im Rahmen einer fragmentierten Makroarchitektur sind die notwendigen Dienste in vertikaler wie in horizontaler Sicht auf oft zahlreiche Einzelsysteme aufgeteilt, wie in Abb. 1.4 angedeutet. Dabei können schichtspezifische und schichtübergreifende Systeme durchaus gemischt auftreten. Mit Blick auf die Datenhaltungsschicht bedienen i.d.R. mehrere Datenhaltungssysteme verschiedene personalwirtschaftliche Systeme der Anwendungsschicht. Daneben können jedoch auch schichtübergreifende Systeme mit integrierter Datenhaltung existieren. In der Folge sind personalwirtschaftliche Datenbestände oft in (teil-)redundanter Weise auf unterschiedliche datenhaltende Systeme verteilt. Auch

10

1.2

Varianten der Makroarchitektur

mit Blick auf die Anwendungsschicht finden sich häufig horizontal heterogene Strukturen, die aus oft zahlreichen Einzelsystemen bestehen können, darunter partiell auch Module eines personalwirtschaftlichen Systems. Fragmentierte Architekturen führen entsprechend oft zu »Insellösungen« mit zahlreichen Medienbrüchen zwischen den unterstützten Funktionen. Zur Vermeidung von damit einhergehenden Verzögerungen und Redundanzen können in einer fragmentierten Architektur fakultativ auch Dienste einer Integrationsschicht angeboten werden. Präsentationsschicht

WWW

Phone

(Integrationsschicht)

Portal

IVR

...

Legacy1 Anwendungsschicht

OLAP

ERP

... AZM

Datenhaltungsschicht

DWS

DBS1

DMS

...

Abb. 1.4: Fragmentierte Makroarchitektur Beispielsweise versucht man mittels Portalsystemen (vgl. Kap. 25) den Anwendern einen einheitlichen integrierten Zugang zu den vertikal und horizontal heterogenen Anwendungs- und Datenhaltungsschicht einer Makroarchitektur zu ermöglichen. Die faktische Komplexität tiefer liegender Schichten kann so für die Anwender verborgen werden. Dabei können sich die Dienste einer Integrationsschicht nur auf einen Teil der Systeme der Anwendungs- und Datenhaltungsschicht beziehen, während andere Systeme nicht integriert sind. Damit ist die Realisierung einer Integrationsschicht in fragmentierten Architekturen zwar meist sinnvoll, aber keineswegs zwingend. Die konkrete Realisierung der Präsentationsschicht hängt dann u.a. von der Realisierung der Integrationsschicht ab. Existiert in der Integrationsschicht ein System, das die Systeme der vorgelagerten Ebene umfassend integriert, dann kann die Präsentationsschicht ausschließlich mit Browsersystemen realisiert werden (vgl. Teil D). Andernfalls kann auch die Präsentationsschicht mittels verschiedener schichtspezifischer Präsentationssysteme sowie durch entsprechende

11

1

Architektonische Grundlagen Anwenderschnittstellen von schichtübergreifenden Systemen realisiert werden.

Verbreitung

Obwohl auch diesbezüglich keine empirischen Ergebnisse bekannt sind, dürfte die fragmentierte Makroarchitektur – mit oder ohne Integrationsschicht – die derzeit wohl verbreitetste Architekturvariante darstellen. Da Gesamtarchitekturen oft eher emergent entstehen, denn strategisch geplant werden (vgl. auch Kap. 2), sind fragmentierte Makroarchitekturen das nahe liegende Ergebnis. Insbesondere in größeren Unternehmen sind entsprechend komplexe und heterogene Systemportfolios entstanden, um die vielfältigen Unterstützungsbedarfe des Personalmanagements zu befriedigen.

1.2.4

Serviceorientierte Makroarchitektur

Struktur

Als aktuelles Architekturparadigma werden derzeit serviceorientierte Architekturen (SOA) diskutiert. Trotz des hohen Stellenwerts, der einer SOA beigemessen wird, hat sich bislang allerdings noch kein einheitliches Verständnis der Konzeption und der möglichen technischen Umsetzung herausgebildet (vgl. Oey et al. 2005, Reinheimer et al. 2007). Generell zielt eine serviceorientierte Architektur auf die geschäftsprozessorientierte Bereitstellung von Funktionen in Form von »Services«, die heterogener Herkunft und Ausgestaltung sein, jedoch über wohl definierte Schnittstellen über eine Integrationsinfrastruktur miteinander kommunizieren können. Dabei realisieren Services insbesondere die Datenhaltungs- und Anwendungsschicht. Für die Übernahme der Dienste der Integrationsschicht hat sich derzeit noch kein einheitlicher Standard herausgebildet. Neben diversen Enterprise Service Bus-Systemen (ESB) werden hierfür auch integrationsorientierte Business Process Management-Systeme (vgl. Kap. 24) diskutiert (vgl. etwa Vollmer & Gilpin 2006 und Vollmer & Peyret 2006). Die Präsentationsschicht wird dann in der Regel über Browsersysteme (vgl. Kap. 28) realisiert werden. Abb. 1.5 deutet eine serviceorientierte Architektur an. Services sind zunächst Systeme oder Systemkomponenten, die bestimmte personalwirtschaftliche Funktionen zur Verfügung stellen. Services sind voneinander unabhängig, wieder verwendbar und mit wohl definierten Schnittstellen versehen. Neben spezifisch für die Anwendung in einer SOA erstellten Services sollen Services auch auf den Schnittstellen konventioneller Systeme aufsetzen können und diese entsprechend in eine serviceorientierte Architektur integrieren. Services können dabei selbst erstellt oder von heterogenen Anbietern bezogen werden. Sie können intern durch das Unter-

12

1.2

Varianten der Makroarchitektur

nehmen vorgehalten, als auch extern im Sinne einer Dienstleistung bezogen werden. Präsentationsschicht

WWW

Integrationsschicht

BPM - ESB

Anwendungsschicht

Legacy1 Service1

Service..

Datenhaltungsschicht

Service1

Service..

DBS1 intern

extern

Abb. 1.5: Serviceorientierte Makroarchitektur Services sind dabei »gekapselt«, d.h. sie verbergen die konkrete Art der Implementierung von Funktionen und Daten. Die Funktionalität eines Services wird dabei über die Serviceschnittstelle zur Verfügung gestellt, die festlegt, wie der Service aufgerufen werden kann, wie das Ergebnis eines Services aussieht und welche Parameter dabei übergeben werden (vgl. Oey et al. 2005, 205ff., Reinheimer et al. 2007, 7f.). Services werden über spezifische Dienste der Integrationsschicht miteinander verbunden. Zunächst soll ein Service-Repository (»Diensteverzeichnis«) alle internen und externen Services in einem zentralen Verzeichnis erfassen und verwalten. Da sich die Menge verwendeter Services im Zeitablauf auch ändern kann und/oder parallel mehrere alternative Services dieselbe Funktion übernehmen können, dient das Repository als zentrale Informationsgrundlage zur Lokalisierung verfügbarer Services. Für Zwecke der Steuerung von Bearbeitungsprozessen existiert zusätzlich ein Service-Bus, der die Dienste der einzelnen Services so koordiniert, dass dem Anwender eine services-übergreifende Bearbeitung einer Aufgabe möglich wird. Dazu vermittelt der Service-Bus unter Rückgriff auf das Service-Repository zwischen einzelnen Services. Diese Vermittlungsdienstleistung besteht darin, dass der Service-Bus einem nachfragenden Service Informationen dazu übermittelt, wo er einen gewünschten gebenden Service finden kann und wie dieser anzusprechen ist. Faktisch ermöglicht der Service-Bus damit die Interoperabilität verschiedener heterogener Services. Darüber hinaus können weitere Aufgaben wie Verschlüsselung der Daten, Sicherheitsprüfung und Authentifizierung der Services sowie die 13

1

Architektonische Grundlagen Lastverteilung vom Service-Bus übernommen werden. Die Ablauflogik des Service-Bus wird dabei durch Geschäftsprozesse bestimmt. Basierend auf Geschäftsprozessen sollen automatisierte Interaktionsfolgen von Services (»Choreographien«) realisiert werden (vgl. Oey et al. 2005, 209). Von SOA erhofft man sich die Möglichkeit, Makroarchitekturen deutlich flexibler als bisher gestalten zu können. Im Sinne einer »Mix & Match«-Strategie sollen Gesamtarchitekturen aus heterogenen internen und externen Services flexibel zusammengestellt werden können. Ändern sich Geschäftsprozesse, sollen betroffene Services flexibel, einfach und schnell hinzugefügt bzw. entfernt werden können. Allerdings fehlen bislang allgemein akzeptierte Schnittstellen-Standards ebenso wie einheitliche Vorstellungen zur systemseitigen Realisierung der Dienste der Integrationsschicht.

Verbreitung

14

Derzeit sind keine empirischen Studien zur möglichen Verbreitung von SOA im Personalmanagement bekannt. Da die Konzeption und insbesondere deren technische Umsetzung sich derzeit noch in den Anfängen befinden, dürfte sich die Realisierung serviceorientierter Architekturen im Personalmanagement gegenwärtig auf wenige Pionierunternehmen beschränken.

2

Organisatorische Grundlagen Informationssysteme im Personalmanagement müssen geplant, bereitgestellt, implementiert, betrieben und angewendet werden, um erwünschte Ergebnisse herbeizuführen. Diese Funktionen können als Prozess verstanden werden, der auf unterschiedliche Weise realisiert werden kann. Das vorliegende Kapitel diskutiert daher zentrale Alternativen der organisatorischen Ausgestaltung dieser Funktionen.

2.1

Überblick Die Planung, Bereitstellung, Implementierung, Betrieb und Anwendung von Informationssystemen im Personalmanagement lässt sich als Prozess darstellen (vgl. Abb. 2.1).

Planung IS(-Portfolio) geplant Bereitstellung IS(-Portfolio) bereitgestellt Implementierung IS(-Portfolio) anwendbar

š Anwendung

Betrieb

Ergebnisse1-n

Abb. 2.1: Informationssystembezogene Aktivitäten

15

2

Organisatorische Grundlagen Die Systemplanung umfasst die gedankliche Vorwegnahme künftiger Informationssysteme. Die Systembereitstellung zielt auf die notwendigen Aktivitäten der Entwicklung und/oder des Fremdbezugs der geplanten Systeme. Die Systemimplementierung dient der gegenseitigen Anpassung von Organisation und Informationssystem. Der Systembetrieb umfasst Aktivitäten zur Herstellung und Aufrechterhaltung der Anwendbarkeit des Systems. Die Systemanwendung zielt schließlich auf die systemgestützte Übernahme von Funktionen des Personalmanagements durch diverse Anwender.

2.2

Systemplanung Die Systemplanung zielt auf die systematische gedankliche Vorwegnahme künftiger Informationssysteme im Personalmanagement. Nach der Bedeutung und Reichweite der vorgenommenen Planungen kann zwischen ƒ strategischer Systemplanung und ƒ operativer Systemplanung unterschieden werden.

Strategische Planung

16

Die strategische Informationssystemplanung beschäftigt sich mit der grundsätzlichen und längerfristigen Ausgestaltung der informationstechnischen Unterstützung des Personalmanagements. Charakteristisch für eine strategische Informationssystemplanung ist dabei die Ausrichtung an der gewünschten Makroarchitektur und dem Gesamtportfolio personalwirtschaftlicher Informationssysteme (vgl. Scholz 1997). Generelles Ziel ist dabei eine ausgewogene Gesamtkonfiguration an Systemen, durch die richtige Auswahl, Platzierung und Koordination einzelner Informationssysteme (vgl. Krcmar 2004, 200ff.). Grundsätzlich können solche strategische Planungen selten »auf der grünen Wiese« erfolgen. Vielmehr existiert eine gewisse »Pfadabhängigkeit«, und Planungen haben meist auf dem bereits bestehenden Portfolio an Altsystemen (»Legacy-Systeme«) aufzusetzen. Die strategische Informationssystemplanung bewegt sich im Spannungsverhältnis von genereller Informationssystem- und Personalstrategie. Entsprechend ist mit beiden Funktionalstrategien eine Abstimmung anzustreben (vgl. Hildebrand 1994). Die generelle Informationssystemstrategie kann bereits weit reichende Direktiven wie etwa zwingende Bindung an spezielle Hersteller im Rahmen der Bereitstellung oder die Vorgabe einer generellen Portalstrategie (vgl. Kap. 25) im Rahmen der Anwendung der Systeme vorgeben. Ebenso kann die Vorgabe eines Budgets generelle Rahmen-

2.2

Systemplanung

bedingungen setzen. Zentrale inhaltliche Anforderungen an das Systemportfolio resultieren aus der generellen Personalstrategie. Auf ihrer Grundlage sind die grundsätzlichen Anwendungsziele festzulegen. Entsprechend muss ein Systemportofolio i.d.R. zahlreichen technischen wie betriebswirtschaftlichen strategischen Kriterien genügen. Ein strategisches Informationssystem-Portfolio sollte jedoch nicht nur derivativ aus den Vorgaben anderer Funktionalstrategien abgeleitet werden (»Demand-Pull«). Vielmehr sollten etwa auf der Basis eines systematischen Technik-Scannings auch strategische Impulse durch neue Möglichkeiten der Technik (»Technology-Push«) berücksichtigt werden. Entsprechend sind auch technische Trends und Tendenzen kontinuierlich auf ihre Relevanz hin zu überprüfen. Aufgrund der weit reichenden und oft unterschätzten Bedeutung des eingesetzten Systemportfolios für Organisation, Inhalte und Ergebnisse des Personalmanagements ist die strategische Systemplanung ohne Frage eine originäre Aufgabe der obersten Leitungsebene von Personal- und Informationssystemmanagement. Operative Planung

Die operative Ausplanung solcher Gesamtportfolios bezieht sich auf die Festlegung konkreter Einzelsysteme und deren Interaktion. Entsprechend ist für jedes Einzelsystem die Art der Bereitstellung, der Implementierung, des Betriebs und der Anwendung zu bestimmen. Ziel der operativen Planung ist ein Sollkonzept für die spätere Anwendung. Dazu ist i.d.R. zunächst eine Analyse durchzuführen, die den Ist-Zustand im Bereich der geplanten Systemanwendung erhebt, beschreibt und bewertet. Häufig wird dazu eine prozessorientierte Vorgehensweise gewählt, die die entsprechenden Geschäftsprozesse und zugehörige organisatorische Einheiten sowie die dabei anfallende Entstehung, Weiterleitung und Verwendung von Daten analysiert (vgl. Scheer 2002). Der so erhobene Ist-Zustand wird danach einer Schwachstellenanalyse unterzogen, die Mängel in Prozessen (z.B. Stillstandszeiten) und Daten (z.B. fehlende Führungsinformationen) aufzeigen soll. Aufbauend auf der Analyse wird ein Sollkonzept entwickelt, das systematisch die fachlichen und die technischen Anforderungen an das spätere System beschreibt. Fachliche Anforderungen beziehen sich auf die detaillierte Beschreibung der vom System zu unterstützenden personalwirtschaftlichen Prozesse und der darin bereitzustellenden Funktionen. Technische Anforderungen betreffen zahlreiche weitere Sachverhalte. Wichtig ist etwa die Performanz des Systems, die sich beispielsweise in maximal bearbeitbaren Datenvolumina niederschlägt. Ebenso werden die mögliche Hardware- und Systemsoftwarebasis sowie Schnittstel17

2

Organisatorische Grundlagen len spezifiziert (vgl. Stahlknecht & Hasenkamp 2005, 226ff.). Die systematische schriftliche Zusammenstellung aller technischen und fachlichen Anforderungen wird dabei als Pflichtenheft (»Requirements Specification«) bezeichnet. Auch die operative Ausplanung und Einzelentscheidungen zu konkreten Systemen weisen erhebliche Folgen für die künftige Personalarbeit auf. Entsprechend wären die jeweils prozess- oder bereichsverantwortlichen Personalmanager in Zusammenarbeit mit entsprechenden IT-Fachkräften adäquate Aufgabenträger der operativen Planung. Aufgrund der teils technisch anspruchsvollen Inhalte ist hier der Einbezug entsprechender Berater oft sinnvoll.

Verbreitung

Derzeit sind keine empirischen Studien zur Verbreitung der Systemplanung im Personalmanagement bekannt. Der oben angedeutete synoptische Planungsansatz dürfte allerdings nicht unbedingt die Regel sein. Häufig liegen eher inkrementelle Planungen vor, die aus bruchstückhaften, auch informellen, auf einzelne Systeme beschränkten Entwürfen bestehen. Speziell die systematische strategische Ausrichtung und Abstimmung von Informationssystemen dürfte wenig verbreitet sein. Die »Informationssystemstrategie« des Personalmanagements weist daher sehr oft einen ausgeprägt emergenten Charakter auf.

2.3

Systembereitstellung Die Bereitstellung zielt darauf ab, die geplanten Systeme im Unternehmen zur Verfügung zu stellen. Die zentralen Varianten, die Bereitstellung zu organisieren, bestehen in ƒ der Systementwicklung und ƒ dem Systembezug. Die Entwicklung zielt auf die individuelle Erstellung benötigter Informationssysteme und impliziert daher i.d.R. die Bereitstellung von Individualsoftware. (Allerdings finden sich auch Fälle, in denen eigenentwickelte Systeme später als Standardsoftware angeboten werden.) Der Bezug zielt dagegen auf die externe Beschaffung bereits erstellter Systeme. Der Systembezug impliziert daher die Bereitstellung von Standardsoftware.

2.3.1

Systementwicklung Die Entwicklung von Systemen zielt als Variante der Bereitstellung auf die unternehmensindividuelle Erstellung von Informationssystemen. Zur Systementwicklung existieren zahlreiche Vorgehensmodelle, die Funktionen und Abfolge des Entwicklungs-

18

2.3

Systembereitstellung

prozesses spezifizieren (vgl. Stahlknecht & Hasenkamp 2005, 209). Unter dem Begriff ƒ der Systemanalyse werden die bereits dargestellte Ist-Analyse und die Soll-KonzeptEntwicklung nicht wie hier der Systemplanung zugeordnet, sondern als erste Phase der Systementwicklung gesehen. Zentrale nachfolgende Funktionen der Systementwicklung sind dann ƒ der Systementwurf und ƒ die Systemrealisierung. Im Rahmen des Systementwurfs werden die Vorgaben des Sollkonzepts in einen detaillierten informationstechnischen Entwurf überführt. Die hierbei zu wählende Vorgehensweise hängt dabei vom gewählten Entwicklungsparadigma ab. Im Rahmen konventioneller Entwicklung werden zunächst Daten (Datenmodellierung), Funktionen (Funktionsentwurf) und Prozessabläufe (Prozessentwurf) festgelegt. Im Rahmen der neueren objektorientierten Programmierung werden dagegen Objekte bzw. Klassen mit ihren verschiedenen gegenseitigen Beziehungen festgelegt. Eine anschließende Programmspezifikation legt detailliert die Datenorganisation, Eingabe von Daten, Verarbeitung von Daten und Ausgaben fest. Diese Spezifikation wird dann in einen konkreten Programmentwurf überführt. Der Programmentwurf wird dann in der Systemrealisierung umgesetzt. Diese umfasst die eigentliche Programmierung (Programmentwicklung) unter Rückgriff auf eine geeignete Programmiersprache und/oder ein entsprechendes Softwareentwicklungswerkzeug. In einem zweiten Schritt ist dann ein Programmtest zu absolvieren. Blackbox-Tests überprüfen dabei anhand von Testdaten, inwieweit die geforderten Funktionen fehlerfrei ausgeführt werden, während bei WhiteboxTests der Quellcode im Detail auf korrekte Formulierung geprüft wird (vgl. Stahlknecht & Hasenkamp 2005, 204ff.). Varianten

Die beiden zentralen Varianten der Systementwicklung stellen ƒ die Eigenentwicklung und ƒ die Auftragsentwicklung dar. Bei der Eigenentwicklung werden interne Stellen, speziell Systemanalytiker und Programmierer der Fachabteilung »IT« und Prozessspezialisten der Fachabteilung »Personal«, mit der Erstellung entsprechender Systeme betraut. Im Falle der Auftragsentwicklung wird die Erstellung des Systems an externe IT-Spezialisten vergeben. Für welche Variante man sich entscheidet, hängt neben den Kosten vor allem auch von der internen Verfügbarkeit entsprechender qualitativer und quantitativer personeller Res-

19

2

Organisatorische Grundlagen sourcen ab. Fehlen interne Ressourcen, bleibt als Alternative nur die Auslagerung der Entwicklung. Die Eigen- wie die Auftragsentwicklung stellt dem Personalmanagement Individualsoftware zur Verfügung. Diese weist i.d.R. den Vorteil auf, individuell auf die Bedürfnisse von Unternehmen und Anwender zugeschnitten zu sein und bezüglich der Ausgestaltung von Schnittstellen etc. in die vorhandene Systemlandschaft zu passen. Allerdings sind Entwicklungen i.d.R. zeitund kostenaufwändig. Nach der Entwicklung entstehen mit der Wartung und Weiterentwicklung weiter auch Folgeaufgaben. Angesichts des qualitativen und quantitativen Funktionsumfanges »historisch gewachsener« Standardsoftware ist deren Niveau allerdings schwer zu erreichen. So ist es illusorisch, etwa die von einem ERP-System angebotenen umfassenden Personalmanagementfunktionalitäten (vgl. Kap. 23) in Individualsoftware auch nur annähernd nachbilden zu wollen. Gleichwohl bieten Individualentwicklungen die Chance, in wettbewerbsrelevanten Bereichen, in denen man sich von Wettbewerbern differenzieren kann, individuelle Funktionalitäten bereitzustellen.

Verbreitung

Derzeit sind keine empirischen Studien zum Umfang der Systementwicklung im Personalmanagement bekannt. Die Systementwicklung war in der Anfangszeit die ausschließliche Bereitstellungsvariante. Inzwischen dürfte sie aufgrund der genannten Nachteile jedoch gegenüber dem Fremdbezug eine klar untergeordnete Rolle einnehmen. Gleichwohl belegen Erfahrungsberichte der jüngeren Zeit personalwirtschaftliche Eigenentwicklungen (vgl. etwa Hesse 2003).

2.3.2

Systembezug Die Alternative zur Entwicklung ist der Fremdbezug bereits erstellter Systeme. Wesentliche Varianten des Fremdbezugs sind ƒ der Kauf, ƒ das Leasing, ƒ das Application Service Providing und ƒ die Freeware. Das Application Service Providing nimmt hierbei insofern eine Sonderstellung ein, als es zusätzlich zur Bereitstellung des Systems auch den Systembetrieb sowie ggf. die Systemimplementierung abdeckt.

Kauf

20

Der »Kauf« einer Software bezieht sich grundsätzlich auf den Erwerb einer zeitlich unbefristeten Lizenz, bei dem ein Lizenzgeber (Softwarehersteller) dem Lizenznehmer (anwendendes Unter-

2.3

Systembereitstellung

nehmen) die Nutzung der Software gegen eine Lizenzgebühr ermöglicht. Damit erwirbt der Lizenznehmer allerdings lediglich das Recht, das entsprechende Informationssystem anzuwenden, jedoch kein Eigentumsrecht an den Inhalten (Prozesse, Funktionen, Algorithmen etc.) der Software. Dieses Recht an den Inhalten verbleibt urheberrechtlich weiter beim Lizenzgeber. Wo nicht anders vereinbart, kann der Lizenznehmer seine Lizenz auch weiterverkaufen. Er verliert danach allerdings sämtliche Anwendungsrechte und darf keine Kopien der Software mehr besitzen. Konkrete Details werden dabei i.d.R. in einem Lizenzvertrag festgelegt, der Aspekte wie Art und Umfang der zu überlassenden Software, Zahl möglicher Anwender und Höhe der Lizenzgebühr detailliert regelt. Die Gestaltung der Lizenzgebühren orientiert sich dabei an heterogenen Kriterien. Neben seltenen Festpreisen je Lizenz wird etwa die Zahl der Anwender, die Zahl der zu bearbeitenden Transaktionen oder die Zahl der Mitarbeiterdatensätze als Grundlage der Lizenzgebühr genannt. Nicht selten spielt auch die individuelle Verhandlungsposition des Anwenders eine erhebliche Rolle bei der Preisgestaltung. Nach dem Lizenzerwerb ist das entsprechende System vom Lizenznehmer auf eigenen Rechnern zu implementieren, zu betreiben und anzuwenden. Leasing

Eine weitere Variante des Fremdbezuges von Informationssystemen besteht im Software-Leasing. Ein Leasing-Geber überträgt die Anwendungsrechte an der Software an die anwendende Organisation als Leasing-Nehmer. Als Leasing-Geber kommen dabei neben dem Software-Hersteller auch spezielle Leasing-Organisationen in Frage, die Nutzungsrechte an der Software beim Hersteller erworben haben. Das geleaste System wird dabei wie beim Software-Kauf auf der Hardware der anwendenden Organisation installiert. Ebenso übernimmt das anwendende Unternehmen auch die Implementierung und den Betrieb des geleasten Systems. Als Entgelt wird eine Leasing-Gebühr für eine bestimmte Zeiteinheit fällig. Nach Ende der vereinbarten Vertragslaufzeit können je nach Vertragsgestaltung die gesamten Rechte an der Software erworben werden. Damit ist das Leasing in die Bereitstellungsvariante »Kauf« übergegangen.

ASP

Beim Application Service Providing (ASP) handelt es sich um das Bereitstellen und das Betreiben von Informationssystemen über Netzwerke, speziell das Internet und Virtual Private Networks (VPN), durch ein Dienstleistungsunternehmen (»Provider«) gegen Entgelt (vgl. Hentschel 2003). Im Sinne verteilter Systeme läuft die eigentliche Anwendung dabei auf Rechner des Provider-Unternehmens, während das anwendende Unternehmen lediglich 21

2

Organisatorische Grundlagen Präsentationssysteme für die Endanwender, speziell Browsersysteme (vgl. Kap. 28), betreibt. Im Bedarfsfall greifen interne Anwender über diese Systeme auf die Software zu (»Software On Demand«). In Abgrenzung zum so genannten »Application Hosting«, das sich auf die reine Bereitstellung der Systeme beschränkt, werden beim ASP auch alle Aufgaben des Systembetriebs wie Systemadministration, Wartung und Benutzerverwaltung und -betreuung sowie Datensicherung und -archivierung übernommen (vgl. Knolmayer 2000). Der Provider übernimmt damit zusätzlich zur Bereitstellung immer auch den Betrieb des entsprechenden Systems. Unterschiedlich gehandhabt wird die Frage der unternehmensindividuellen Implementierung der angebotenen Systeme. Während häufig keine Anpassungen angeboten werden (und teils auch nicht notwendig sind), existieren Varianten, in denen die anwendende Organisation gewisse Parametrisierungen vornehmen kann ebenso wie »Customizing«-Angebote durch den Provider (vgl. Abb. 2.2). ... Bereitstellung Informationssystem bereitgestellt Implementierung

AS-Provider

Informationssystem anwendbar

š ...

Betrieb ...

Abb. 2.2: Application Service Providing Das Provider-Unternehmen hat die von ihm angebotene Software dabei seinerseits bei einem Softwarehersteller gekauft oder geleast oder ist selbst Kunde bei einem weiteren Application Service Provider. Häufig bieten auch entsprechende Softwarehersteller direkt ein ASP an. Mittels eines Service Level Agreement (SLA, 22

2.3

Systembereitstellung

Dienstgütevereinbarung) werden dann Inhalte, Umfang und Ausprägung der zu erbringenden Dienstleistung detailliert spezifiziert. Hierzu zählen zunächst generelle Angaben wie die genaue funktionale und technische Spezifikation des anzubietenden Informationssystems, die Laufzeit der Vereinbarung, Kündigungsmöglichkeiten sowie Art und Höhe der Bezahlung. Zentral sind weiter quantitative Angaben zur Dienstleistung, wie etwa zur Systemverfügbarkeit (maximale Ausfallzeiten pro Zeiteinheit), zum Datendurchsatz (Menge der pro Zeiteinheit übertragbaren bzw. verarbeitbaren Daten), zu Antwortzeiten (maximale Dauer zwischen Dienstanforderung und Dienstbereitstellung), zur maximalen Anzahl simultan aktiver Anwender, zum Anwendersupport (chronometrische und chronologische Verfügbarkeit) oder zur Wiederherstellungszeit (maximale Dauer der Wiederherstellung des Dienstes nach einem Ausfall). I.d.R. werden auch Verfahren zur Kontrolle der Einhaltung dieser Vereinbarungen mit aufgenommen. Ebenso können Regelungen für den Fall der Nichteinhaltung der Vereinbarung durch den Anbieter, wie etwa Strafgebühren, integriert sein. Freeware

Unter dem Oberbegriff Freeware (»freie Software«) werden verschiedene Varianten einer kostenfreien Bereitstellung von Systemen durch verschiedene kommerzielle wie nicht-kommerzielle Organisationen und Personen gefasst. Freeware bezeichnet gewöhnlich Software, die vom Urheber (meist per Internet-»Download«) kostenlos angeboten wird, ohne dass der Urheber auf Rechte am System verzichtet. Anwender dürfen Freeware verwenden, allerdings nicht verändern oder weiterverkaufen. Als Variante legt Open Source Software zusätzlich auch den Quellcode des Systems offen, so dass Anwender und Programmierer sich an der Weiterentwicklung des Programms beteiligen können. Teilweise besteht dann allerdings ein kommerzielles Geschäftsmodell in der kostenlosen Bereitstellung der Software und der Bepreisung der individuellen Implementierung. Als Shareware bezeichnet man dagegen gewöhnlich kommerzielle Software, die von einem meist kommerziellen Anbieter nur für eine gewisse Zeit kostenlos (probeweise) zur Verfügung gestellt wird. Nach Ablauf einer entsprechenden Erprobungsphase werden allerdings meist Zahlungen fällig. Obwohl eine Beschäftigung mit der Freeware-Thematik im Personalmanagement derzeit aussteht, dürften freie Systeme eine gewisse Bedeutung besitzen. Zumindest lassen sich für zahlreiche Systemkategorien auch freie Varianten nachweisen, darunter bspw. Datenbanksysteme bzw. Systeme zur Haltung von Personaldaten (vgl. Kap. 4), Personalabrech23

2

Organisatorische Grundlagen nungssysteme (vgl. Kap. 13), Arbeitszeitmanagementsysteme (vgl. Kap. 14), Learning Management-Systeme (vgl. Kap. 20), ERP-Systeme (vgl. Kap. 23), Portalsysteme (vgl. Kap. 25) oder Browsersysteme (vgl. Kap. 28). Die Qualität und Funktionalität angebotener Systeme ist bislang nicht systematisch untersucht und mit kommerziellen Angeboten verglichen worden. Ein solcher Vergleich dürfte je nach Systemkategorie sehr unterschiedlich ausfallen. Während etwa bei Browsersystemen kommerzielle und freie Varianten durchaus gleichwertig sein können, dürften etwa bei ERP-Systemen erhebliche funktionale Lücken zwischen kommerziellen und freien Systemen klaffen.

Bewertung

24

Die einzelnen Bereitstellungsvarianten weisen zunächst unterschiedliche finanzielle Implikationen auf. Während der Kauf i.d.R. höhere einmalige Kosten verursacht, entfallen diese bei den übrigen Varianten. Diese Mittel stehen dem Unternehmen dann entsprechend für andere Zwecke zur Verfügung. Leasing und ASP bedingen allerdings laufende Zahlungen an die Vertragspartner, die beim Kauf entfallen. In Abhängigkeit von der Dauer der Anwendung können solche laufenden Kosten die Kosten eines Kaufs übersteigen. Aufgrund der zusätzlichen Dienstleistungen sind die laufenden Zahlungen an den Application Service Provider notwendigerweise höher als an einen Leasing-Geber. Allerdings entstehen bei Kauf und Leasing Kosten für die Implementierung und den Eigenbetrieb, die bei ASP nicht anfallen. Entsprechend kann ASP günstiger als Leasing sein, wenn beim Provider Skaleneffekte entstehen und er diese an die Kunden weitergibt. Finanziell besonders attraktiv ist natürlich Freeware, die weder einmalige noch laufende Zahlungen an einen Vertragspartner impliziert. Im Vergleich zur Entwicklung dürften die kostenpflichtigen Varianten des Fremdbezugs wegen zahlreicher Anwender und spezialisierter Anbieter insgesamt kostengünstiger sein. Aus Aufwandssicht hat ASP mit der Auslagerung des Betriebs und ggf. der Implementierung des Systems deutliche Vorteile gegenüber allen anderen Bezugsvarianten. Das Personalmanagement kann sich so auf seine »Kernaufgaben« und die bloße Anwendung des Systems konzentrieren. Insbesondere deswegen wird ASP auch häufig als Bereitstellungsvariante für kleinere und mittlere Unternehmen angeführt, die entsprechende Mitarbeiter für den Systembetrieb nicht abstellen können und/ oder wollen. Verglichen mit einer Eigenentwicklung entfällt beim Fremdbezug die aufwändige Entwicklungsphase, allerdings sind dann u.U. aufwändige individuelle Implementierungen (»Customizing«) notwendig. Entsprechend kann eine Auftragsentwick-

2.3

Systembereitstellung

lung dabei je nach Ausgestaltung durchaus aufwandsärmer als ein Fremdbezug sein. Aus funktionaler Sicht unterscheiden sich die Bereitstellungsvarianten nicht. Je nach Anbieter kann teilweise dasselbe System per Kauf, Leasing oder ASP bezogen werden. Wie erwähnt, dürften lediglich Freewarevarianten des Öfteren funktional eingeschränkte Leistungsfähigkeit aufweisen. Insgesamt gilt, dass fremdbezogene Standardsoftware individuelle Anforderungen i.d.R. nicht so gut abdecken kann wie individuell entwickelte Software. Allerdings ist Standardsoftware meist in längerfristigen Zyklen unter Einbezug von Anforderungen und Anregungen zahlreicher Anwender und unter stetem Wettbewerbsdruck anderer Anbieter entstanden (vgl. Krcmar 2004, 136ff.). Eine in funktionaler Qualität und Quantität vergleichbare Individualentwicklung »aus dem Stand« ist daher meist kaum mehr möglich. Auswahlprozess

Für alle Varianten des Fremdbezugs gilt, dass entsprechende Systeme und Bezugspartner auszuwählen sind. Grundsätzlich empfiehlt es sich, die Auswahl auf den fachlichen und technischen Vorgaben des Pflichtenhefts durchzuführen (vgl. Mülder et al. 1994). Dabei dürften die Anforderungen an ein für die Auswahl geeignetes Pflichtenheft je nach Bereitstellungsvariante leicht variieren. Das generelle Angebot an Standardsoftware schwankt je nach Systemkategorie zwischen einigen wenigen bis zu mehreren hundert Systemen (vgl. Strohmeier 1999). Entsprechend gestalten sich Auswahlprozesse unterschiedlich aufwändig. Zur Auswahl wird in der Regel ein mehrstufiger Prozess vorgeschlagen. Eine Suchphase dient zunächst der Identifikation grundsätzlich vorhandener Anbieter. Relevante Informationsquellen sind hierbei etwa allgemeine Softwareführer, Internetrecherche, spezifische Marktübersichten der Fachliteratur, sowie Softwaremessen. Inzwischen bieten auch Berater Hilfestellung bei Identifikation und anschließender Auswahl an. Basierend auf Muss-Anforderungen des Pflichtenhefts sowie weiterer zentraler Kriterien wie jeweilige Kosten und Anbieterseriosität dient eine Grobauswahl dann der Identifikation im engeren Sinne geeigneter Systeme und Anbieter (n < 10). Neben Produktbeschreibungen der Anbieter können hierzu auch Softwarepräsentationen der Anbieter besucht werden. Diese Gruppe von Systemen wird dann einer Feinauswahl unterzogen. Generell sollen dabei Informationen zu den im Pflichtenheft geforderten technischen und fachlichen Eigenschaften etc. ausschließlich auf Basis einer konkreten Probeinstallation bzw. im Falle des ASP einer Probeanwendung mit realen Datenumfängen gewonnen werden, um spätere Überra25

2

Organisatorische Grundlagen schungen auszuschließen. Zur Sicherstellung der Einhaltung der gewünschten Anforderungen sollte zusätzlich das Pflichtenheft zum Gegenstand des zu schließenden Lizenz- oder Leasing-Vertrages bzw. der Service Level Agreements gemacht werden.

Verbreitung

Zur faktischen Verbreitung der einzelnen Fremdbezugsvarianten existieren derzeit kaum empirische Untersuchungen. Generell dürften jedoch Kauf und Leasing die mit Abstand häufigsten Konstruktionen darstellen. Das Application Service Providing scheint dagegen einer empirischen Studie nach (noch) keine weite Verbreitung gefunden zu haben (vgl. Hils & Bahner 2005, 32). Allerdings könnte dem ASP im Rahmen von serviceorientierten Architekturen, die Services verschiedener Anbieter integrieren, künftig eine deutlich wichtigere Rolle zukommen. Schließlich dürfte die Verwendung von Freeware klar nachrangiger Natur sein und derzeit lediglich spezifische Nischen bedienen.

2.4

Systemimplementierung

Funktionen

Die Implementierung zielt auf die gegenseitige Anpassung von Organisation und Informationssystem im Vorfeld der Anwendung. Grundsätzlich kann dabei zwischen ƒ der technischen Implementierung und ƒ der organisatorischen Implementierung unterschieden werden. Technische Aspekte der Implementierung zielen auf die Anpassung des Systems speziell durch Customizing, Datenübernahme und Systemtests. Organisatorische Aspekte der Implementierung zielen auf die Anpassung der Organisation und umfassen insbesondere die Anpassung von Prozessen, das Schaffen von Akzeptanz sowie die Schulung von Anwendern.

Technische Implementierung

Das Customizing ist die individuelle Anpassung des Informationssystems an die Bedarfe der Organisation. Ein Customizing ist vor allem für fremdbezogene Standardsoftware von Bedeutung, da individuell erstellte Software notwendigerweise bereits an individuelle Anforderungen ausgerichtet ist. Standardsoftware ist dagegen dadurch gekennzeichnet, dass sie die Möglichkeit (und meist auch die Notwendigkeit) eines Customizing aufweist. Das Customizing bezieht sich dabei auf Anpassungen von Daten sowie Prozessen und darin enthaltenen Funktionen. Die Customizing von Datenstrukturen erfolgt durch entsprechende Datenmodifikationssprachen oder -werkzeuge. Je nach Art der Datenhaltung sind Anpassungen von Datenstrukturen auch direkt in entsprechenden Datenbanksystemen vorzunehmen (vgl. auch

26

2.4

Systemimplementierung

Kap. 4). Zum Customizing von Prozessen existieren in Teilen der Systeme grafisch orientierte Prozessmodellierungswerkzeuge zur Spezifikation und Veränderung vorgefertigter Workflows (vgl. auch Kap. 24). Das Customizing von Funktionen kann dann über Parametrisierung oder Programmierung erfolgen. Im Rahmen der Parametrisierung werden (frei) wählbare Parameter so eingestellt, dass das System den individuellen Bedürfnissen des Unternehmens entspricht: Ein einfaches Beispiel für die Parametrisierung einer Funktion ist die unternehmensindividuelle Festlegung des Zuschlagssatzes für Mehrarbeit, z.B. »110%«, in einem Personalabrechnungssystem (vgl. Kap. 13). Der Zuschlagssatz stellt in diesem Fall den im Rahmen des Customizing frei wählbaren Parameter der Funktion »Berechung der Mehrarbeitsvergütung« dar. Deutliche weitergehende und aufwändigere Anpassung ermöglicht die Veränderungs-Programmierung. Bei intensiver Ausübung dieser Option werden die Grenzen zur Entwicklung von Software allerdings zunehmend fließend. Je nach Softwarekategorie stellt das Customizing eine quantitativ umfangreiche und qualitativ komplexe Aufgabe dar. Entsprechend betragen die Kosten des Customizing oft ein Vielfaches der reinen Softwarekosten. Allerdings existieren ebenso Systemkategorien und Systeme, die wenig oder gar kein Customizing ermöglichen. Die entsprechenden Systeme müssen dann so angewendet werden wie vom Hersteller vorgegeben, was meist entsprechend umfangreiche organisatorische Anpassungen der korrespondierenden Prozesse erfordert. Nach der Anpassung ist das System mit den entsprechenden Daten zu befüllen. Weil personalwirtschaftliche Systeme i.d.R. datenintensiv sind, bedeutet dies einen meist aufwändigen Prozess. Da inzwischen nahezu regelmäßig Altsysteme mit relevanten (Personal-)Daten vorhanden sind, ist die Datenmigration eine erste Möglichkeit. Die Migration erfolgt über ein »Mapping« von Quell- und Zieldatenfeldern. Werden Daten aus mehreren Altsystemen übernommen, ist dabei auch eine Harmonisierung der entsprechenden Datenbestände notwendig. Fehlen Altdatenbestände teilweise oder vollständig, ist eine i.d.R. manuelle Ersteingabe notwendig. Nach der Datenübernahme sind verschiedene Systemtests durchzuführen. Belastungstest versuchen zunächst die Performanz des Systems durch gleichzeitiges Anstoßen ressourcenintensiver Prozesse zu überprüfen. So genannte Crashtests versuchen das System durch sinnlose Eingaben, bewusstes Betätigen zahlreicher Einzeltasten, Provokation von Fehlern etc. auf seine Stabilität hin 27

2

Organisatorische Grundlagen zu überprüfen. Funktionstests prüfen dann die Funktionalität und Fehlerfreiheit i.d.R. durch das Bearbeiten typischer Aufgabenstellungen und die anschließende Überprüfung der erzielten Ergebnisse. Je nach Systemkategorie können solche Funktionstests sehr umfangreich ausfallen. Beispielsweise ist aus dem Personalabrechnungsbereich (vgl. Kap. 13) bei der Implementierung eines Neusystems der oft monatelange Parallelbetrieb von Alt- und Neusystem mit beständigem Abgleichen der Ergebnisse bekannt.

Organisatorische Implementierung

Meist ist im Rahmen der organisatorischen Implementierung eines Systems auch eine Anpassung der korrespondierenden Personalprozesse notwendig. Dies gilt insbesondere dann, wenn starre Systeme keine Anpassung des vorprogrammierten Prozessablaufs ermöglichen. Diese systemimmanente Oktroyierung organisatorischer Veränderungen (»Process follows Software«) wurde in der Vergangenheit vielfach scharf kritisiert und hat erheblich zur Entwicklung organisatorisch »gestaltbarer« Systeme beigetragen. Allerdings können auch bei eigens entwickelter Individualsoftware oder »gecustomizter« Standardsoftware aus Gründen der Prozessoptimierung (Einsparung von Kosten, Erhöhung der Qualität, Beschleunigung der Durchlaufzeiten etc.) teils erhebliche Veränderungen von Abläufen und Strukturen nötig werden. Trotz Anpassungsmöglichkeiten des Systems dürften daher »hybride« Ansätze dominieren, bei denen System und Organisation wechselseitig angepasst werden. Die Implementierung von Informationssystemen impliziert daher meist mehr oder minder umfangreiche Veränderungen organisatorischer Verantwortlichkeiten und Ressourcen. Solche absehbaren Änderungen können Widerstände auslösen. Informationssysteme im Personalmanagement scheitern weniger aus technischen Gründen, denn aus Mangel an Akzeptanz. Nicht zuletzt deswegen werden regelmäßig Maßnahmen zur Förderung der Systemakzeptanz vorgeschlagen (vgl. Drumm 2005, 165ff.). Grundsätzlich wird hier im Rahmen eines umfassenden »Change Managements« ein Bündel unterschiedlicher Maßnahmen wie offensive Informationspolitik, umfassende Partizipation bei der Einführung, Ausrichtung der Anreizsysteme an den neuen Strukturen und nicht zuletzt eine extensive Anwenderschulung vorgeschlagen (vgl. Shrivastava & Shaw 2004, 212). Zielgruppe solcher akzeptanzfördernder Maßnahmen sind dabei nicht nur spätere Anwender, sondern generell alle Mitarbeiter und auch Mitarbeitervertretungen.

28

2.4

Systemimplementierung

Varianten

Nach der Art der Implementierung können ƒ abrupte und ƒ inkrementelle Ansätze unterschieden werden. Eine abrupte Implementierung zielt auf eine direkte umfassende Einführung des gesamten Systems (»Big Bang«). Insbesondere bei umfassenderen Systemen und größeren Organisationen gerät diese Vorgehensweise aus Gründen technischer und sozialer Komplexität in Gefahr fehlzuschlagen. Eine inkrementelle Implementierung zielt dagegen auf die schrittweise Einführung des Systems, in dem etwa einzelne Module nacheinander implementiert werden und/oder das System zunächst in ausgewählten Organisationseinheiten eingeführt wird. Dabei können entstandene Fehler sukzessive erkannt und beseitigt werden (vgl. Shrivastava & Shaw 2004, 211).

Träger

Die rein technische Implementierung kann ƒ vom Softwarehersteller, ƒ von Systemintegratoren und/oder ƒ von der Fachabteilung »IT« durchgeführt werden. Werden Systeme über Application Service Providing angeboten, kann die technische Implementierung auch ƒ vom Application Service Provider ausgeführt werden. Häufig gehört die technische Implementierung einschließlich Anwenderschulung mit zum Angebot des entsprechenden Softwareherstellers. So genannte Systemintegratoren sind spezifische Implementierungsunternehmen, die Systeme fremder Softwarehersteller implementieren (und teilweise auch vertreiben). Teilweise sind Systemintegratoren allerdings auch Tochterunternehmen des jeweiligen Herstellers. Aufgrund der partiell quantitativ umfangreichen und qualitativ komplexen Anforderungen, bildet die Systemintegration ein eigenständiges Beratungssegment. Die technische Implementierung kann auch intern durch die Fachabteilung »IT« erfolgen. Umfassendere Systeme erfordern dabei regelmäßig die projektmäßige Organisation der Implementierung, mit einer entsprechend etablierten Projektplanung, -steuerung und -dokumentation. An der organisatorischen Implementation dürfte zusätzlich ƒ die Fachabteilung »Personal« als von der Implementierung betroffene, wie als für Change Management zuständige Abteilung beteiligt werden.

Verbreitung

Derzeit sind keine empirischen Studien zur Verbreitung unterschiedlicher Vorgehensweisen der Systemimplementierung im Personalmanagement bekannt.

29

2

Organisatorische Grundlagen

2.5

Systembetrieb

Funktionen

Der Systembetrieb dient der Herstellung und Aufrechterhaltung der Anwendbarkeit des Systems. Hierzu zählt die Erstinstallation des Systems auf entsprechenden Rechnern. Im weiteren Verlauf sind auch die Fehlerbeseitigung etwa durch Einspielen von Ausbesserungsprogrammen (»Patches«) und das kontinuierliche Einspielen neuer Systemversionen (»Release-Wechsel«, »Updates«) Aufgaben des Systembetriebs. Weiter sind i.d.R. die Anwender und Anwenderrechte im System im Rahmen einer Anwenderverwaltung zu administrieren. Regelmäßig gehört auch die Beratung von Anwendern bei Problemen zu den Aufgaben des Systembetriebs. Schließlich ist auch eine regelmäßige systematische Sicherung aller Daten (»Back Up«) notwendig.

Varianten

Nach der Zuordnung zu möglichen Aufgabenträgern kann grundsätzlich zwischen ƒ zentralem Systembetrieb und ƒ dezentralem Systembetrieb unterschieden werden. Bei zentralem Betrieb werden alle anfallenden Aufgaben von Systemadministratoren der Fachabteilung »IT« beziehungsweise des entsprechenden Application Service Providers übernommen. Beim dezentralen Betrieb ist die anwendende Fachabteilung »Personal« für den Betrieb zuständig. In letzterem Fall finden sich häufig »hybride« Organisationseinheiten, die das System im Rahmen der Fachabteilung »Personal« betreiben. Mischformen teilen sich den Betrieb, indem etwa Präsentationssysteme dezentral, die eigentlichen Anwendungssysteme aber zentral betrieben werden.

Verbreitung

Derzeit sind bezogen auf personalwirtschaftliche Systeme keine empirischen Studien zur Verbreitung unterschiedlicher Varianten des Systembetriebs bekannt.

2.6

Systemanwendung Die Organisation der Anwendung von Systemen bezieht sich grundsätzlich auf die Frage, welche Aufgabenträger unter Heranziehen welcher einschlägigen Systeme welche Personalmanagementfunktionen übernehmen. Ohne Frage stellt die Anwendung der Informationssysteme neben der Planung den für das Personalmanagement zentralen Prozessschritt dar. Mit Blick auf die generelle Organisation des Personalmanagements (vgl. Schirmer 2004) hat die Anwendung zu teils erheblichen Veränderungen und Innovationen beigetragen. Als idealtypisch haben dabei die Anwendungsvarianten

30

2.6

Systemanwendung

ƒ Fachabteilung, ƒ Self Service und ƒ Servicecenter zu gelten. Zusätzlich kann das ƒ Outsourcing als eine Variante der »mittelbaren Anwendung« von Informationssystemen verstanden werden. Fachabteilung

Eine verbreitete konventionelle Variante stellt die Anwendung der Informationssysteme durch die Fachabteilung »Personal« dar. War in den Anfangszeiten der Informationstechnikunterstützung auch die Anwendung von Systemen häufig noch an die Fachabteilung »IT« bzw. »EDV« ausgelagert, ist die Anwendung entsprechender Personalmanagementsysteme zunehmend Aufgabe der Fachabteilung »Personal« geworden. (Allerdings dürften komplexere Anwendungen – wie etwa die Erstellung von Data MiningAnalysen [vgl. Kap. 12] – nach wie vor auch von IT-Spezialisten durchgeführt werden.) Grundsätzlich gilt, dass gegenwärtige Informationssysteme unterschiedliche aufbauorganisatorische Varianten wie funktionsorientierte oder objektorientierte Organisation der Personalabteilung unterstützen können. Die in der Regel mehrplatzfähigen Informationssysteme (»Multiuser-Systeme«) ermöglichen über regelmäßig verfügbare Anwenderverwaltungen einen auf die Person zugeschnittenen Zugriff auf das System. I.d.R. verfügen Anwender damit nicht über Zugriff auf alle Prozesse und Daten eines Systems, sondern erhalten zielgerichteten Zugang auf die für ihre Aufgabenerfüllung relevanten Bereiche. Viele Informationssysteme verfügen hierzu über vorgefertigte Anwenderrollen. Anwenderrollen definieren die Aufgaben, Eigenschaften und vor allem die Zugriffsrechte eines Einzelanwenders, meist aber einer spezifischen homogenen Subgruppe von Anwendern (z.B. »Personalreferent«, »Personalabrechner«, »Zeitbeauftragter« etc.). Letztere Variante verhindert, dass einzelnen Anwendern in aufwändiger Weise jeweils individuelle Rechte zugesprochen werden müssen. Einzelne Anwender können dabei durchaus mehrere Rollen zugewiesen bekommen. Die Gesamtheit der zu erfüllenden Rollen bestimmt dann die Anwendungsmöglichkeiten eines Anwenders. Auf diese Weise lassen sich diverse aufbauorganisatorische Varianten des Personalmanagement in Informationssystemen abbilden.

Self Service

Bereits seit längerem werden neben Mitgliedern der Fachabteilung »Personal« weitere potenzielle Anwendergruppen von personalwirtschaftlichen Informationssystemen – speziell Manager und Mitarbeiter – erwogen (vgl. etwa Tannenbaum 1990). Im 31

2

Organisatorische Grundlagen Rahmen mehrplatzfähiger Informationssysteme können diesen zusätzlichen Anwendergruppen bereits seit längerem Zugriffsrechte auf personalwirtschaftliche Informationssysteme eingeräumt werden. Allerdings fehlte oft eine feingranulare Anwenderverwaltung, die die erforderliche differenzierte Gestaltung des Zugriffs auf Funktionen und Daten zulässt. Weiter sind Navigation und Oberfläche dieser Systeme oft nicht auf »Gelegenheitsanwender« zugeschnitten und bedürfen umfangreicher Anwenderschulungen. Den Durchbruch beim Erschließen neuer Anwendergruppen erbrachten daher erst webbasierte Systeme, auf die mittels Browsersysteme zugegriffen werden kann (vgl. Kap. 28). Unter der Bezeichnung Self Service wird daher seit über einer Dekade der eigenständige, webbasierte Zugriff durch Manager, Mitarbeiter und/oder Bewerber diskutiert (vgl. Abb. 2.3). ... Manager Mitarbeiter

Anwendung

Bewerber

...

Browsersystem

...

Abb. 2.3: Self Service Die zentrale Idee des Self Service ist, durch eine entsprechende Ausgestaltung der Systeme diesen Anwendergruppen die selbstständige Übernahme gewisser Personalmanagementfunktionen zu ermöglichen. Die weite Verbreitung und die vergleichsweise einfache Bedienbarkeit von Browsersystemen erlauben die Gestaltung weitgehend »selbsterklärender« Anwenderschnittstellen, die Schulungsaufwand und Akzeptanzprobleme minimieren. Im Rahmen eines Manager Self Service können zunächst personalverantwortliche Linienmanager mit Zugriffsmöglichkeiten auf personalwirtschaftliche Informationssysteme versehen werden. In Abhängigkeit von der gewünschten Dezentralisierungsintensität können neben administrativen Prozessen wie etwa der Genehmigung von Dienstreisen durchaus auch Kernprozesse des Personalmanagement in der Variante eines Manager Self Service durchgeführt werden. Als mögliche Aufgabenbereiche werden entsprechend Personalbeschaffung, -vergütung, -beurteilung und -entwicklung diskutiert (vgl. Adamson & Zampetti 2001). Ein webbasierter Manager Self Service bietet insofern eine grundle32

2.6

Systemanwendung

gende technische Infrastruktur zur Realisierung der Dezentralisierung des Personalmanagements. Zusätzlich werden allerdings auch Mitarbeiter als mögliche Aufgabenträger der auf sie selbst gerichteten Personalarbeit entdeckt. Analog zum Manager Self Service werden daher auch Mitarbeiter als Anwender von webbasierten personalwirtschaftlichen Informationssystemen diskutiert (Mitarbeiter bzw. Employee Self Service). Im Fokus der Diskussion stehen zunächst administrative Aktivitäten wie die Pflege der eigenen Personalstammdaten, das Durchführen von Zeitbuchungen oder das Beantragen von Urlaub und Dienstreisen. Darüber hinaus können allerdings auch Entscheidungsbefugnisse an Mitarbeiter delegiert werden wie etwa die selbstständige Wahl von Vergütungsbestandteilen oder die Entscheidung, an einer (Online-)Trainingsmaßnahme teilzunehmen (vgl. Zampetti & Adamson 2001). Beschränkt auf Prozesse der Beschaffung und Auswahl kann analog auch ein Bewerber- bzw. Applicant Self Service etabliert werden. In Interaktion mit webbasierten Beschaffungsmanagementsystemen können Bewerber sich entsprechend über Vakanzen informieren, sich bewerben, an (Vor-)Auswahlprozessen teilnehmen und den Fortgang ihrer Bewerbung überprüfen (vgl. Kap. 16). Self Service hat inzwischen eine weite Verbreitung erfahren, denn 57% der Unternehmen geben an, über eine Variante des Self Service zu verfügen (vgl. Kabst & Giradinni 2005, 41). Self Service dürfte als Anwendungsvariante eine der wesentlichen organisatorischen Innovationen des Personalmanagement der letzten Dekade darstellen. Sie bilden die technisch-organisatorische Basis der Konzeption des »electronic (e-)Human Resource Management« (vgl. Strohmeier 2002 und 2007, Jäger & Jäger 2002, Mülder 2003b, Ruël et al. 2004). Solche Systeme bilden weiter die Grundlage für die Diskussion um die Virtualisierung der Personalarbeit (vgl. Lepak & Snell 1998, Strohmeier 1998 und Scholz 2004). Eine »virtuelle Personalabteilung« existiert nur mehr der Funktion nach, aber nicht mehr physisch. Räumlich und zeitlich entkoppelte, aber durch Informationssysteme koordinierte und unterstützte Netzwerke aus Managern, Mitarbeitern, Bewerbern und externen Dienstleistern fungieren als faktische Aufgabenträger der Personalarbeit (vgl. Scholz 2004). Als eine eher radikale organisatorische Variante verweist die Virtualisierung des Personalmanagements auf die erheblichen Veränderungspotenziale, die mit der Informationstechnik einhergehen. Service Center

Seit mehreren Jahren werden auch personalwirtschaftliche Service Center (Shared Service Center [SSC], HR Service Center, Em33

2

Organisatorische Grundlagen ployee Interaction Center) als organisatorische Alternative diskutiert und praktiziert (vgl. Ackermann 2005). Service Center sind interne Organisationseinheiten (oder aber externe Dienstleistungsunternehmen), die personalwirtschaftliche Funktionen übernehmen, welche bisher in ähnlicher Form an anderer Stelle, etwa durch eine oder mehrere Personalabteilungen, übernommen wurden (vgl. Bender 2001, 213). Hierbei handelt es sich typischerweise um »kollaborative« Aufgaben, die in direkter Interaktion mit Mitarbeitern und Managern zu bearbeiten sind. Werden aus Gründen der Größendegression in einem Service Center Tätigkeiten mehrerer, bisher getrennt bearbeiteter Unternehmensbereiche zusammengeführt, oder bietet ein externes Service Center Dienstleistungen für mehre Kundenunternehmen an, spricht man von »Shared Service Centern«. Zentrale Ziele von Service Center-Konzepten sind die Erhöhung von Produktivität, Qualität und Schnelligkeit der Bearbeitung von Anfragen (vgl. Ulrich 1995). Ursprünglich auf Call Center-Konzepten aufsetzend, werden in Service Centern zunächst telefonbasierte Anfragen von Mitarbeitern und Managern beantwortet. Inzwischen werden aber Anfragen über mehrere weitere Kanäle, darunter e-Mail, Fax und konventioneller Schriftverkehr, integriert abgearbeitet. Erneut haben erst Entwicklungen der Informationstechnik (und der damit konvergierenden Kommunikationstechnik) die Etablierung dieser organisatorischen Variante ermöglicht: Zunächst wird der Betrieb eines Service Centers durch spezifische Service CenterSysteme ermöglicht, die die über unterschiedliche Kanäle erfolgende Kommunikation mit Managern und Mitarbeitern sowie die Administration und Steuerung des Service Center-Geschehens unterstützen (vgl. Kap. 27). Über entsprechende Schnittstellen von Service Center-Systemen greifen die Mitarbeiter eines Service Centers bei der Bearbeitung von Anfragen auch auf verschiedene Personalsysteme zu. In der Regel sind Service Center dabei in zwei Stufen organisiert: Eine erste Stufe (»First Level Agent«, Generalist) dient der Abarbeitung allgemeiner Anfragen und der Weitergabe von Informationen. Kompliziertere und anspruchsvollere Anfragen und Aufgaben können dann an eine zweite Stufe (»Second Level Agent«, Spezialist) weitergereicht werden. Service Center stellen damit eine weitere Variante dar, die Anwendung von Informationssystemen zu organisieren. Service Center scheinen inzwischen eine erhebliche Verbreitung erfahren zu haben (vgl. Ackermann 2005).

Kombinationen

34

Da Self Service und Service Center Personalmanagementprozesse i.d.R. nicht vollständig abarbeiten können, werden verschiedent-

2.6

Systemanwendung

lich gestufte Kombinationen der Anwendungsvarianten Self Service, Servicecenter und konventioneller Personalarbeit vorgeschlagen, um ein umfassendes Organisationsmodell vorzulegen (vgl. Abb. 2.4).

Manager

Anfrage entstanden

Mitarbeiter

Anwendung

Browsersystem

Bewerber

XOR

Anfrage bearbeitet

...

Anfrage nicht bearbeitet Service Center

Anwendung

Service CenterSystem

XOR

Anfrage bearbeitet

...

Anfrage nicht bearbeitet FA Personal

Anwendung

Personalsysteme

Anfrage bearbeitet

Abb. 2.4: Mehrstufiges Anwendungsmodell Als erste Ebene ist ein Self Service-Konzept für die Bearbeitung standardisierter Anfragen und Transaktionen vorgesehen. Aufgaben, die hier nicht selbstständig bearbeitet werden können, werden zum Servicecenter weitergeleitet, wo sie gemäß der zweistufigen Organisationsform abgearbeitet werden. Die große Masse der Aufgaben (> 80%) sollen dabei durch Self Service und Service Center übernommen werden. Nur Aufgaben, die auch in der zweiten Stufe nicht bearbeitet werden können, werden anschließend durch die Fachabteilung »Personal« individuell bearbeitet (vgl. Bender 2001). Die Anteile der kostenintensiven Bearbeitungen durch Spezialisten in der Personalabteilung können so erheblich reduziert werden. Outsourcing

Eine spezifische Variante der allerdings nur mehr »mittelbaren« Anwendung besteht im Outsourcing von Personalmanagementprozessen. Outsourcing zielt grundsätzlich zunächst auf die Aus35

2

Organisatorische Grundlagen gliederung von Unternehmensaufgaben an externe Dienstleister. Im weiteren Sinne bilden daher grundsätzlich auch die Bereitstellungsvariante »Application Service Providing« und die Anwendungsvariante »externes Service Center« Varianten eines personalwirtschaftlichen Outsourcings (vgl. Keebler 2001). Im engeren Sinne zielt ein personalwirtschaftliches (Business Process) Outsourcing (BPO) allerdings speziell auf die Ausgliederung von Personalmanagementprozessen. Diese seit langem praktizierte organisatorische Variante ist zunächst keineswegs zwingend an die Anwendung von Informationssystemen gebunden. Allerdings existieren zahlreiche Outsourcing-Angebote, die unmittelbar mit der Anwendung von Informationssystemen zusammenhängen: Einen klassischen Outsourcing-Prozess bildet etwa die Personalabrechnung, die seit Langem als externe Rechenzentrumsdienstleistung angeboten wird. Das entsprechende Dienstleistungsunternehmen betreibt dann nicht nur die notwendigen Informationssysteme, sondern führt die anfallenden Aufgaben unter Anwendung der Informationssysteme auch komplett durch. Dies impliziert, dass der Outsourcer auch die Bereitstellung und den Betrieb sowie eventuell die technische Implementierung des anzuwendenden Systems durchführt (vgl. Abb. 2.5). ... Bereitstellung Informationssystem bereitgestellt Implementierung Informationssystem anwendbar

š Anwendung

Betrieb

...

Abb. 2.5: Outsourcing

36

Outsourcer

2.6

Systemanwendung

Der Personalbereich ist dann nur noch »mittelbarer« Anwender des Informationssystems. Allerdings bieten aber gerade webbasierte Anwendungssysteme (vgl. Kap. 28) die Möglichkeit einer beliebigen Arbeitsteilung zwischen internen Stellen und externen Dienstleistern. So kann etwa im Rahmen einer grundsätzlich »outgesourcten« Personalabrechnung die Dateneingabe von internen Personalsachbearbeitern vorgenommen werden, während die übrigen Aufgaben beim Outsourcer abgearbeitet werden. Grundsätzlich können auch mehrere externe Dienstleister mit der Bearbeitung eines oder mehrerer Personalmanagementprozesse betraut werden (»Multisourcing«). Ebenso ist es möglich, dass gewisse Teile von Aufgaben durch Self Service bearbeitet werden. Letztlich können so beliebige Aufgabenträger in die Abarbeitung eines Personalprozesses einbezogen werden. Die Grenzen zwischen »Application Service Providing« und »Business Process Outsourcing« verlaufen damit inzwischen oft fließend. Verbreitung

Derzeit sind keine vergleichenden empirischen Studien zur Verbreitung der einzelnen Anwendungsvarianten bekannt.

37

3

Rechtliche Grundlagen Die Anwendung von Informationssystemen im Personalmanagement wird von zahlreichen rechtlichen Regelungen flankiert. Im folgenden Kapitel werden daher zentrale Regelungen ƒ zum Datenschutz, ƒ zur Mitbestimmung, ƒ zur Gleichbehandlung, ƒ zur Datenübermittlung und ƒ zur Lohnbuchhaltung dargestellt.

3.1

Datenschutz Informationssysteme im Personalmanagement zielen auf die Erhebung, Speicherung und Verarbeitung von Daten, die besonders schutzwürdige Bereiche betreffen und Missbrauchspotenziale aufweisen. Verschiedene Regelungen zum Datenschutz sollen daher die Persönlichkeitsrechte Betroffener schützen und möglichen Missbrauch unterbinden. Als zentrale Datenschutzvorschrift hat das Bundesdatenschutzgesetz (BDSG) den Zweck, »den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinen Persönlichkeitsrechten beeinträchtigt wird« (§ 1 Abs. 1 BDSG). Das BDSG ist dabei subsidiär gegenüber anderen, hier nicht dargestellten Spezialvorschriften wie etwa des Telemediengesetzes oder der Landesdatenschutzgesetze.

Grundlagen

Grundlage des BDSG bildet zunächst das »Recht auf informationelle Selbstbestimmung«, das vom Bundesverfassungsgericht 1983 im Rahmen des so genannten »Volkszählungsurteils« ausgearbeitet wurde. Als Ausprägung des allgemeinen Persönlichkeitsrechts (Art. 2 Abs. 1 i.V.m. Art. 1 Abs. 1 Grundgesetz) wird hierin das Recht des Einzelnen normiert, über die Preis- und Weitergabe seiner persönlichen Daten grundsätzlich selbst zu bestimmen. Die informationelle Selbstbestimmung ist dabei weit gefasst und bezieht sich nicht nur auf besonders »sensible«, sondern auf alle persönlichen Daten. Dem liegt die Überlegung zugrunde, dass es »harmlose« persönliche Daten grundsätzlich nicht gibt, weil Daten durch technische Verknüpfungs- und Auswertungsmöglichkeiten 39

3

Rechtliche Grundlagen eine neue Qualität bekommen können. Das Recht auf informationelle Selbstbestimmung motiviert sich aus der Überzeugung, dass die Selbstbestimmung und freie Entfaltung der Person durch die Möglichkeiten der Informationstechnik gefährdet oder zumindest eingeschränkt werden können. Bereits die Unkenntnis darüber, welche Daten zu seiner Person wo gespeichert sind und an wen weitergeleitet werden, können den Einzelnen verunsichern und seine Handlungsfreiheit einschränken. Das Recht auf informationelle Selbstbestimmung ist damit eine Ausprägung des allgemeinen Persönlichkeitsrechts und bildet die Grundlage des Datenschutzrechts. Zusätzlich bildet auch die Europäische Datenschutzrichtlinie (Richtlinie 95/46/EG) eine Grundlage des BDSG, die Mindeststandards an EU-Mitgliedsstaaten zur Schaffung einheitlicher Datenschutzstandards in nationalen Gesetzen formuliert.

Geltungsbereich

Das BDSG gilt für die Erhebung, Verarbeitung und Nutzung personenbezogener Daten (§ 1 Abs. 2 BDSG), d.h. »Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren Person« (§ 3 Abs. 1 BDSG). In aller Regel basieren Informationssysteme im Personalmanagement auf solchen personenbezogenen Daten. Allerdings existieren Ausnahmen: Systeme, die vollständig (nicht re-identifizierbar) anonymisierte oder vollständig (nicht re-identifizierbar) pseudonymisierte Daten verarbeiten, verwenden keine personenbezogenen Daten. Beispielsweise kann im Rahmen des Data Mining (vgl. Kap. 12) mit solchen anonymisierten oder pseudonymisierten Daten gearbeitet werden. Gleiches gilt, wenn ausschließlich aggregierte Daten, etwa auf Ebene einer größeren Organisationseinheit, verwendet werden, und die Struktur der Daten keinerlei Rückschlüsse auf einzelne Personen zulässt. Schließlich existieren drittens einige Anwendungen, deren zentralen Objekte nicht aus natürlichen Personen bestehen. Eine Datenbankanwendung, die exklusive Stellendaten vorhält, verwendet ebenfalls keine personenbezogenen Daten. Weiter müssen die Daten in Dateiform vorliegen, also systematisch erheb-, speicher- und auswertbar sein (§ 3 Abs. 2 BDSG). Dieses Kriterium trifft auf alle datenhaltenden Systeme (vgl. Teil B) bzw. Datenhaltungskomponenten von Anwendungssystemen zu (vgl. Teil C). Entsprechend fällt der Großteil der Informationssysteme im Personalmanagement in den Geltungsbereich des BDSG.

Regelungen

Grundsätzlich normiert das BDSG ein »Verbot mit Erlaubnisvorbehalt«, d.h. die Erhebung, Speicherung, Verarbeitung und Weiterleitung personenbezogener Daten ist in Konkretisierung des

40

3.1

Datenschutz

Rechts auf informationelle Selbstbestimmung generell verboten. Allerdings existieren so genannte »Erlaubnisvorbehalte«, deren Vorliegen das Verbot aufheben. Für das Personalmanagement zentrale Erlaubnistatbestände sind ƒ die Zustimmung durch den Betroffenen, ƒ die Erlaubnis oder Anordnung durch Gesetz oder Rechtsvorschrift und ƒ die Zweckbestimmung durch Vertrag oder vertragsähnliches Verhältnis. Eine erste Möglichkeit besteht in der ausdrücklichen Einwilligung des Betroffenen. Die Einwilligung muss in schriftlicher Form erfolgen (§ 4a Abs. 1 BDSG). Ebenso muss die Einwilligung freiwillig erfolgen und darf nicht etwa an die Zusage eines Arbeitsplatzes gekoppelt werden. Weiter müssen Zweck und Umfang der Datenverarbeitung näher spezifiziert werden. Unspezifizierte »Blankovollmachten« sind nicht möglich. Weitere Möglichkeiten bzw. Notwendigkeiten bestehen in der Erlaubnis oder der Anordnung durch Gesetz oder Rechtsvorschrift (§ 4 Abs. 1 BDSG). Beispielsweise erfordert die »Verordnung über die Erfassung und Übermittlung von Daten für die Träger der Sozialversicherung (DEÜV)« vom Arbeitgeber zwingend die elektronische Erfassung und Übermittlung zahlreicher personenbezogener Daten an diverse Sozialversicherungsträger. Drittens ermöglicht die Zweckbestimmung eines Vertrages oder vertragsähnlichen Verhältnisses die Erhebung und Verarbeitung personenbezogener Daten (§ 28 Abs. 1 BDSG). In erster Linie erlaubt daher der Arbeitsvertrag mit einem Mitarbeiter die Verarbeitung solcher personenbezogener Daten, die sich unmittelbar aus dessen Zweckbestimmung ergeben. Da beispielsweise die Zahlung von Entgelt die Hauptpflicht des Arbeitgebers aus Arbeitsvertrag darstellt, dürfen alle mit der Entgeltzahlung unmittelbar korrespondierende personenbezogene Daten wie Kontonummer und Kreditinstitut eines Mitarbeiters gespeichert werden. Allerdings darf in die Privatsphäre des Mitarbeiters nicht tiefer eingedrungen werden, als es die Zweckbestimmung des Arbeitsverhältnisses unbedingt erfordert. Daher sind stets Abwägungen zwischen der Notwendigkeit der Datenerhebung und schutzwürdigen Belangen der Mitarbeiter erforderlich. Jenseits eines Arbeitsvertrages greift die Zweckbestimmung auch für Bewerber, deren Daten im Anbahnungsschuldverhältnis der Bewerbungsphase gespeichert werden dürfen, soweit sie im unmittelbaren Zusammenhang mit der Bewerbung stehen (vgl. Däubler 2005, 770).

41

3

Rechtliche Grundlagen

Datenvermeidung Wo vor dem Hintergrund dieser Erlaubnistatbestände mit persound -sparsamkeit nenbezogenen Daten gearbeitet wird, greift mit § 3a BDSG darüber hinaus der Grundsatz der »Datenvermeidung und -sparsamkeit«. Gemäß diesem Grundsatz sind so wenige personenbezogene Daten wie möglich zu erheben und zu verwenden. Weiterhin sind die Daten, wenn möglich und falls der Aufwand zum angestrebten Schutzzweck in angemessenem Verhältnis steht, zu anonymisieren oder zu pseudonymisieren. Anonymisierung bedeutet dabei die Veränderung der personenbezogenen Daten derart, dass Informationen über »persönliche oder sachliche Verhältnisse nicht mehr oder nur mit unverhältnismäßig großem Aufwand« einer Person zugeordnet werden können (§ 3 Abs. 6 BDSG). Pseudonymisierung beinhaltet das Ersetzen der Identifikationsmerkmale, um eine Bestimmung der Person zu unterbinden oder erheblich zu erschweren (§ 3 Abs. 6a BDSG). Betroffenenrechte

Werden personenbezogene Daten erfasst, sind diese nicht bei Sekundärquellen sondern in der Regel beim Betroffenen selbst einzuholen (§ 4 Abs. 2 BDSG). Damit einhergehend ist dieser von der Identität der einholenden Stelle, dem Zweck der Erfassung und ggf. über weitere Empfänger zu informieren (§ 4 Abs. 3 Nr. 1-3 BDSG). Weiterhin verfügt der Betroffene über ein Auskunftsrecht bzgl. der über ihn gespeicherten Daten, deren Herkunft, die Empfänger sowie den Zweck der Speicherung (§ 34 Abs. 1 Nr. 1-3 BDSG), sofern dem nicht das Interesse an der Wahrung des Geschäftsgeheimnisses entgegensteht. Sind die Daten unrichtig, so müssen sie berichtigt werden (§ 35 Abs. 1 BDSG). Unter besonderen Umständen besteht auch das Recht auf Löschung oder Sperrung der Daten (§ 35 Abs. 2-4 BDSG). Dies betrifft z.B. Daten zur ethnischen Herkunft oder religiösen Überzeugung des Betroffenen.

Datensicherheit

Weiterhin sind technische und organisatorische Regelungen zu ergreifen, um die Datensicherheit zu gewährleisten (§ 9 BDSG). In der Anlage zu § 9 Satz 1 BDSG werden Maßnahmen genannt, die zur Erreichung der Datensicherheit zu treffen sind: Über eine Zutrittskontrolle ist Unbefugten der Zutritt zu Anlagen, die personenbezogene Daten verarbeiten, zu verwehren. Dies bezieht sich insbesondere auf die Server, die sich in zentralen Rechenzentren, aber auch dezentral in einzelnen Organisationseinheiten befinden. Die Zutrittskontrolle kann hierbei über ein Zutrittsmanagementsystem (vgl. Kap. 15) realisiert werden. Die Zugangskontrolle beinhaltet die Authentifizierung des Datenzugriffs von berechtigten Anwendern (z.B. durch Kennwörter). Die Verhinderung der Nutzung der Daten durch Unbefugte steht hierbei im

42

3.1

Datenschutz

Mittelpunkt. Über die Zugriffskontrolle erfolgt die Regulierung des Datenzugriffs der Anwender auf einen jeweils festgelegten (Teil-)Bereich. Die Beschränkung des Zugriffs kann hierbei auf bestimmte Daten, Programme oder Programmfunktionen, bestimmte Verarbeitungsaktivitäten (z.B. Lesen, Ändern, Löschen) oder Zeiträume erfolgen. Beispielsweise ist einem Mitarbeiter der Personalentwicklung entsprechend (partieller) Zugriff auf ein Personalentwicklungsplanungssystem (vgl. Kap. 9), aber bspw. nicht auf das Personalabrechnungssystem (vgl. Kap. 13) zu gewähren. Dies wird durch ein Berechtigungskonzept im jeweiligen System geregelt, in welchem die Zugriffsmöglichkeiten des jeweiligen Anwenders auf einzelne Objekte im System festgelegt sind. Über die Weitergabekontrolle soll sichergestellt werden, dass personenbezogene Daten nur durch überprüfbare und nachvollziehbare Datenübertragung übermittelt werden. Die Daten dürfen während der Übermittlung von Unbefugten weder gelesen, kopiert, verändert noch entfernt werden können. Der Empfänger der Daten muss überprüfbar berechtigt sein. Die Eingabekontrolle stellt sicher, dass nachträglich überprüft werden kann, welcher Anwender personenbezogene Daten eingegeben, geändert oder gelöscht hat. Werden personenbezogene Daten im Auftrag verarbeitet (ASP oder Outsourcing), so fordert die Auftragskontrolle, dass diese Verarbeitung nur nach Weisung des Auftraggebers durchgeführt wird. Im Rahmen der Verfügbarkeitskontrolle sind Daten gegen zufällige Zerstörung oder Verlust z.B. durch Stromausfälle, Brand oder Wasserschäden zu schützen. An dieser Stelle sind insbesondere technische Maßnahmen zur Datensicherung z.B. Notstromversorgung, Feuerschutz, fortlaufende Sicherungskonzepte etc. zu ergreifen. Nach dem Trennungsgebot ist weiterhin zu gewährleisten, dass zu unterschiedlichem Zweck erhobene Daten getrennt verarbeitet werden können. Diese Trennung kann physikalisch über verschiedene Systeme oder logisch durch die Festlegung von unterschiedlichen Zugriffsrechten erreicht werden (vgl. Bergmeier & Hoppe 2006, 61). Datenschutzaudit Gemäß § 9a BDSG »Datenschutzaudit« wird den Anbietern von Informationssystemen sowie datenverarbeitenden Stellen die Möglichkeit gegeben, ihr Datenschutzkonzept durch unabhängige und zugelassene Gutachter prüfen und bewerten zu lassen. Ziel ist die Verbesserung des Datenschutzes und der Datensicherheit. Das auditierte Datenschutzniveau kann dann veröffentlicht (§ 9a Satz 1 BDSG) und zu Werbezwecken eingesetzt werden. Dies soll zu einem kontinuierlichen Prozess der Verbesserung von Datenschutz und Datensicherheit führen. Die Umset43

3

Rechtliche Grundlagen zung des Datenschutzaudits basiert auf Freiwilligkeit, d.h. auf Eigenverantwortung des Anbieters bzw. der datenverarbeitenden Stellen (vgl. Bizer 2006b, 693ff.). Gegenstand der Bewertung und Prüfung sind Datenschutzkonzepte und ihre technischen Einrichtungen. Da sich sowohl Anbieter von Informationssystemen als auch datenverarbeitende Stellen auditieren lassen können, ist hierbei eine Unterscheidung in Produktaudit und Verfahrensaudit dienlich, wobei ersteres für die Anbieter und letzteres für die datenverarbeitenden Stellen relevant ist (vgl. Bizer 2006b, 708). Zwar wurde § 9a bereits 2001 in das BDSG integriert, jedoch steht die in § 9a Satz 2 genannte Spezifizierung der »Anforderungen an die Prüfung und Bewertung, das Verfahren sowie die Auswahl und Zulassung der Gutachter« durch ein besonderes Gesetz, dem so genannten Ausführungsgesetz, derzeit noch aus (vgl. Bizer 2006b, 701).

Datenschutzbeauftragter

44

Zur Sicherstellung des Datenschutzes ist u.U. weiter ein Datenschutzbeauftragter zu bestellen. Dies gilt für Unternehmen, in denen in der Regel mindestens 10 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten beschäftigt sind (§ 4f Abs. 1 BDSG). Der Datenschutzbeauftragte muss dabei über die erforderliche Fachkunde und Zuverlässigkeit verfügen (§ 4f Abs. 2 BDSG). Er ist direkt der Geschäftsleitung zu unterstellen und ist bei der Ausübung seiner Tätigkeit als Datenschutzbeauftragter weisungsfrei (§ 4f Abs. 3 BDSG). Zu den zentralen Aufgaben des Datenschutzbeauftragten gehören ƒ das Hinwirken auf die Einhaltung der Datenschutzbestimmungen (§ 4g Abs. 1 BDSG), ƒ die Schulung und Information der Mitarbeiter hinsichtlich des Datenschutzes, ƒ das Fungieren als Ansprechpartner für alle Betroffenen (§ 4f Abs. 5 Satz 2 BDSG) sowie ƒ die Überwachung der Datenverarbeitung. Der Datenschutzbeauftragte hat darüber hinaus eine Vorabkontrolle von Verfahren durchzuführen, die »besondere Risiken für die Rechte und Freiheiten der Betroffenen aufweisen« (§ 4d Abs. 5 BDSG). Dies betrifft personenbezogene Daten gemäß § 3 Abs. 9 BDSG, d.h. Angaben über rassische und ethnische Herkunft, politische Meinungen, religiöse oder philosophische Überzeugungen, Gewerkschaftszugehörigkeiten, Gesundheit oder sexuelle Identität. Aber auch die Verarbeitung von personenbezogenen Daten, die die Persönlichkeit des Betroffenen, seine Fähigkeiten, Leistung oder Verhalten bewerten, unterliegt der Vorabkontrolle durch den Datenschutzbeauftragten.

3.1

Datenschutz

Meldepflichten

Grundsätzlich besteht eine generelle Meldepflicht von Verfahren automatisierter Verarbeitung personenbezogener Daten an die zuständige Aufsichtsbehörde (§ 4d Abs. 1 BDSG). Die Meldepflicht entfällt allerdings, wenn das Unternehmen einen Datenschutzbeauftragten bestellt hat (§ 4d Abs. 2 BDSG), wenn maximal neun Personen mit der Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten betraut sind, eine Einwilligung der Betroffenen vorliegt oder die Erlaubnis aus dem Tatbestand der Zweckbestimmung des Vertrags bzw. des vertragsähnlichen Verhältnisses hervorgeht (§ 4d Abs. 3 BDSG).

Automatisierte Einzelentscheidungen

Einzelentscheidungen, die für den Betroffenen rechtliche Folgen haben oder ihn erheblich beeinträchtigen, »dürfen nicht ausschließlich auf eine automatisierte Verarbeitung oder Nutzung personenbezogener Daten gestützt werden, die der Bewertung einzelner Persönlichkeitsmerkmale dienen« (§ 6a Abs. 1 BDSG). Damit soll sichergestellt werden, dass eine Entscheidung nicht ausschließlich auf automatisiert erstellten Persönlichkeitsprofilen getroffen wird, sondern letztlich von einer natürlichen Person gegenüber dem Betroffenen verantwortet werden muss (vgl. Bizer 2006a, 572). Wird das automatisiert erzeugte Ergebnis vom zuständigen Entscheidungsträger zur Kenntnis genommen, geprüft und bestätigt, so ist dies durchaus zulässig (vgl. Bizer 2006a, 572). Weiterhin ist dem Betroffenen auch die Möglichkeit gegeben, Auskunft über die zugrunde liegenden Angaben und Bewertungsmaßstäbe inklusive der integrierten Logik des automatisierten Verfahrens zu erhalten (§ 6a Abs. 3 BDSG). Das Verbot der automatisierten Einzelentscheidungen gilt nicht ƒ bei den Betroffenen begünstigenden Entscheidungen (§ 6a Abs. 2 Satz 1 Nr. 1 BDSG) sowie ƒ bei Wahrung berechtigter Interessen der Betroffenen durch geeignete Maßnahmen (§ 6a Abs. 2 Satz 1 Nr. 2 BDSG) und Mitteilen der Tatsache der Entscheidung. Für den ersten Fall sind zwei Voraussetzungen notwendig. Die erste Voraussetzung ist, dass eine Entscheidung »im Rahmen des Abschlusses oder der Erfüllung eines Vertragsverhältnisses oder eines sonstigen Rechtsverhältnisses« ergeht. Weiterhin muss dem Begehren des Betroffenen stattgegeben worden sein. Damit fallen bspw. bei einer automatisierten Vorauswahl von Bewerbern für eine Stelle lediglich die Entscheidungen unter das Verbot der automatisierten Einzelentscheidung, die zu einer Aussonderung (Ablehnung) der Bewerber führen. Diese sind dann entsprechend von einem menschlichen Entscheidungsträger zu prüfen.

45

3

Rechtliche Grundlagen

Auftragsdatenverarbeitung

Wird die Verarbeitung personenbezogener Daten im Rahmen eines Application Service Providing oder Outsourcing ausgelagert (vgl. Kap. 2), dann entsteht die Frage, wer für die Einhaltung der Datenschutzbestimmungen zuständig ist. Grundsätzlich ist der Auftraggeber für die Einhaltung der Datenschutzvorschriften verantwortlich, d.h. Betroffene können weiterhin ihre Rechte gegenüber dem Arbeitgeber und nicht gegenüber dem entsprechenden Dienstleister geltend machen (§ 11 Abs. 1 BDSG). Hierzu hat der Auftraggeber den Dienstleister unter Berücksichtigung der Eignung technischer und organisatorischer Maßnahmen zur Sicherstellung des Datenschutzes sorgfältig auszuwählen. Weiterhin muss der Auftrag schriftlich erteilt werden, wobei »die Datenerhebung, -verarbeitung und -nutzung, die technischen und organisatorischen Maßnahmen und etwaige Untervertragsverhältnisse festzulegen sind« (§ 11 Abs. 2 BDSG). Darüber hinaus darf der Auftragnehmer die Daten nur »im Rahmen der Weisung des Auftraggebers erheben, verarbeiten oder nutzen«. Verstößt eine Weisung des Auftraggebers nach Meinung des Auftragnehmers gegen datenschutzrechtliche Vorschriften, so hat er die Pflicht, den Auftraggeber darauf unverzüglich hinzuweisen (§ 11 Abs. 3 BDSG).

3.2

Mitbestimmung Auch im Rahmen der betrieblichen Mitbestimmung finden sich Regelungen, die für die Implementierung und Anwendung von Informationssystemen im Personalmanagement relevant sind. Speziell das Betriebsverfassungsgesetz (BetrVG) enthält eine einschlägige Regelung zur Beteiligung von Betriebsräten, während korrespondierende Bestimmungen zur Beteilung von Sprecherausschüssen im Sprecherausschussgesetz (SprAuG) fehlen. In Unternehmen, in denen ein Betriebsrat existiert, leitet sich ein Mitbestimmungsrecht aus § 87 Abs. 1 Nr. 6 BetrVG ab, einer ursprünglich nicht auf Informationssysteme ausgerichteten, jedoch darauf anwendbaren Bestimmung. Demnach hat der Betriebsrat bei der »Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen«, mitzubestimmen. Diese Vorschrift dient dem Schutz des einzelnen Arbeitnehmers gegen Eingriffe von »anonymen Kontrolleinrichtungen« in den persönlichen Bereich (vgl. Fitting et al. 2006, 1234).

Prüfung

46

Damit unterliegen nicht sämtliche Informationssysteme im Personalmanagement der Mitbestimmung, sondern lediglich solche,

3.2

Mitbestimmung

die Leistung und Verhalten kontrollieren. Zur Feststellung eines Mitbestimmungsrechtes sind daher ƒ die Existenz leistungs- und/oder verhaltensrelevanter Daten und ƒ die Existenz einer automatisierten Überwachung zu prüfen (vgl. Oechsler & Schönfeld 1986). Entsprechend ist zunächst zu prüfen, ob überhaupt leistungs- und verhaltensrelevante Daten aufgenommen werden. Dabei reicht es aus, dass Daten erhoben werden, die zwar nicht einzeln jedoch in Verknüpfung Aussagen über Leistung und Verhalten der Arbeitnehmer zulassen (vgl. Fitting et al. 2006, 1237). Dagegen ist etwa ein bloßes »elektronisches Telefon- und Adressverzeichnis« keineswegs mitbestimmungspflichtig, da darin zwar personenbezogene aber keinerlei leistungs- oder verhaltensrelevanten Daten gespeichert sind. Das Mitbestimmungsrecht besteht weiterhin auch nicht, wenn enthaltene leistungs- und/oder verhaltensrelevante Daten durch Gesetze oder Tarifverträge vorgeschrieben werden, wie z.B. Fahrtenschreiberdaten beim LKW-Betrieb oder die im Tarifvertrag vorgeschriebene Verwendung technischer Einrichtungen bei leistungsbezogenen Entgelten (vgl. Fitting et al. 2006, 1246). Weiter muss die Überwachung in automatisierter Form durch das System selbst und nicht lediglich durch einen nachgelagerten menschlichen Anwender erfolgen. Dabei genügt die bloße Möglichkeit einer automatisierten Überwachung durch das Informationssystem, eine faktische Überwachung oder Überwachungsabsicht muss nicht nachgewiesen werden. Gemäß der Konstruktionslogik des Betriebverfassungsgesetzes gelten diese Regelungen auch lediglich für Informationssysteme, die sich (auch) auf Arbeitnehmer i.S.d. §§ 5 Abs. 1 und 6 BetrVG beziehen. Bezüglich möglicher exklusiver Informationssysteme für leitende Angestellte hat der Betriebsrat keine Rechte. Rechte des BR

Ist ein Mitbestimmungsrecht des Betriebsrates zu bejahen, dann bedingt die Wahrnehmung dieses Rechtes zunächst eine »rechtzeitige« Beteiligung, die dem Betriebsrat eine Einflussnahme auf die Ausgestaltung des Systems ermöglicht. Mit Blick auf den dargestellten Prozessablauf (vgl. Kap. 2) scheint daher ein Einbezug in die operative Ausplanung einzelner mitbestimmungspflichtiger Systeme sinnvoll. Um seine Rechte versiert wahrnehmen zu können, hat der Betriebsrat zunächst Anspruch auf Schulungsmaßnahmen bezüglich aller relevanten technischen und informationssystembezogenen Fragestellungen. Verbleiben danach noch offene Frage- und Problemstellungen, die zur ordnungsgemäßen Wahrnehmung des Mitbestimmungsrechts zu klären sind, kann 47

3

Rechtliche Grundlagen der Betriebsrat nach Vereinbarung mit dem Arbeitgeber auch das Hinzuziehen eines technischen Sachverständigen erwägen (§ 80 Abs. 3 BetrVG). Das eigentliche Mitbestimmungsrecht bezieht sich dann auf die grundsätzliche Ausgestaltung der fraglichen Informationssysteme. Ein generelles Vetorecht im Sinne einer Verhinderung des Informationssystems existiert nicht. Mitbestimmung bei der grundsätzlichen Ausgestaltung meint vielmehr Mitentscheidung über Daten- und Funktionsstrukturen des einzuführenden Systems. Häufig bezieht sich die Mitbestimmung daher auf konkrete leistungs- oder verhaltensbezogene Datenfelder sowie auf Auswertungsfunktionen. Will ein Arbeitgeber ein System einführen, kann der Betriebsrat also insbesondere solche Modifikationen einbringen, ohne die gravierende Nachteile für den Persönlichkeitsschutz der betroffenen Arbeitnehmer entstünden. Dies bedeutet aber keineswegs eine Generalabwehr informationssystemgestützter Leistungskontrollen und entsprechenden Folgen etwa im Bereich der Vergütung, die durch das Direktionsrecht des Arbeitgebers gestützt sind. Zu den Mitbestimmungsrechten zählt im Anschluss auch das Recht der (Zwangs-)Protokollierung der Systemanwendung. Die dadurch mögliche Einsichtnahme dient dem Ausschluss einer missbräuchlichen Verwendung des Systems durch den Arbeitgeber, wie etwa unerlaubter Datenspeicherungen oder Auswertungen. Entsprechende Rechte gelten nicht nur bei der Ersteinführung eines Informationssystems, sondern auch bei maßgeblichen Modifikationen oder Erweiterungen (vgl. Oechsler 2006, 201ff.). Die zahllosen »Kuppelgeschäfte«, die die Mitbestimmungspraxis prägen, eröffnen den Arbeitnehmervertretungen i.d.R. über die normierten Rechte hinaus zahlreiche weitere Einflussmöglichkeiten.

Betriebsvereinbarung

48

Die Ausgestaltung mitbestimmungspflichtiger Informationssysteme kann in Betriebsvereinbarungen geregelt werden. I.d.R. werden hier zunächst grundlegende Regelungsinhalte wie Ziele der Systemanwendung und Ziele sowie Geltungsbereich der Betriebsvereinbarung festgelegt. Weiter wird das fragliche System i.d.R. bezüglich der Rechnerbasis, der Systemarchitektur sowie der Funktionalität dokumentiert. Ein Schwerpunkt von Betriebsvereinbarungen bildet dann häufig die Datenkomponente. Hier wird etwa auf die zulässigen Erfassungsarten, Inhalte sowie Auswertungen von Daten eingegangen. Bei der Positivregelung wird dabei dezidiert geregelt, welche Erfassungsarten, Inhalte und Auswertungen zulässig sind. Bei der Negativregelung wird »lediglich« ausgeschlossen, was nicht zulässig ist. Auch Datenexporte in andere Anwendungen, wie beispielsweise Tabellenkal-

3.3

Gleichbehandlung

kulationssysteme, werden meist explizit geregelt. Teilweise zielen Betriebsvereinbarungen auch auf den gänzlichen Ausschluss automatisierter Leistungs- und Verhaltenskontrollen. Wird Personaldatenverarbeitung ausgelagert, finden sich meist spezielle Regelungen zum ASP und/oder Outsourcing (vgl. Kap. 2). In einer gewissen Redundanz zu den allgemeinen Datenschutzbestimmungen werden häufig auch Datenschutzaspekte in Betriebsvereinbarungen aufgenommen. Dies betrifft etwa Aspekte wie das Datenschutzaudit oder den Datenschutzbeauftragten, aber auch Anwenderrechte und Datenarchivierung. Häufig werden auch die Rechte zur Protokollierung der Systemanwendung wie etwa die konkreten Inhalte, Häufigkeiten von Protokolldateien festgeschrieben. Zumindest teilweise werden auch die Arbeitsorganisation und Arbeitsbedingungen sowie Schulungsansprüche der Anwender reguliert (vgl. Bergmann & Hoppe 2006).

3.3

Gleichbehandlung Um Diskriminierungen bestimmter Personengruppen zu verhindern, wurde in Umsetzung diverser EU Richtlinien 2006 das Allgemeine Gleichbehandlungsgesetz (AGG) verabschiedet. Es benennt mit Rasse, ethnischer Herkunft, Behinderung, sexueller Identität, Religion, Weltanschauung und Geschlecht acht explizite Benachteiligungsmerkmale (§ 1 AGG). Das AGG schützt generell vor unmittelbaren und mittelbaren Benachteiligungen und Belästigungen aufgrund eines oder mehrer dieser Merkmale und zwar in allen Phasen des Arbeitsverhältnisses (vgl. Wisskirchen 2007, 10ff.). Entsprechend entfaltet das Gesetz eine breite Relevanz in allen personalwirtschaftlichen Funktionsbereichen und damit mittelbar auch für alle darin angewendeten Informationssysteme. Beispielsweise ist die Ausschreibung von vakanten Stellen generell diskriminierungsfrei zu gestalten. Selbstverständlich sind hiervon sowohl konventionelle als auch elektronische Stellenausschreibungen (vgl. Kap. 16) betroffen. Analoges gilt für alle weiteren personalwirtschaftlichen Funktionen. In der Folge sind sämtliche personalwirtschaftliche Informationssysteme auf ihre Konformität mit dem AGG zu überprüfen. Unmittelbare Relevanz für die Anwendung von Informationssystemen erlangt das AGG bei der Erhebung von Daten im Rahmen von Bewerbung und Einstellung (vgl. Müthlein & Jaspers 2007, 23ff.). So dürfen im Rahmen der Bewerberdatenerfassung Daten, die im Zusammenhang mit den angeführten Benachteiligungsmerkmalen stehen, nicht mehr erfasst werden, um Diskriminierungsmöglichkeiten bei der Einstellung zu minimieren. Dies be49

3

Rechtliche Grundlagen trifft etwa die bisherige Konvention, das Geschlecht, Zahl der Kinder oder das Lebensalter eines Bewerbers zu erheben. Auch die konventionell zur Bewerbung gehörenden Lichtbilder werden als problematisch erachtet, weil daraus diskriminierungsrelevante Aspekte wie ethnische Herkunft, Geschlecht oder Alter abgeleitet werden können. Soweit solche Daten in einem späteren Arbeitsverhältnis zwingend notwendig sind – etwa um eine ordnungsgemäße Abrechnung durchführen zu können – wird ein strikt von der Bewerberdatenerfassung getrennter, zweiter Erhebungsvorgang empfohlen (vgl. Müthlein & Jaspers 2007, 22). Das AGG verlangt zunächst von den entsprechenden Betroffenen eine Benachteiligung oder Belästigung zu beweisen. Können jedoch »Indizien« bewiesen werden, die »eine Benachteiligung vermuten lassen« ist der Arbeitgeber beweispflichtig, dass keine ungerechtfertigte Diskriminierung stattgefunden hat (§ 22 AGG). Diese Beweislastumkehr stellt entsprechend erhöhte Anforderungen an die Dokumentation der jeweiligen Entscheidungen. Die Diskriminierungsfreiheit der Erhebung und Verarbeitung von Daten sollte daher lückenlos dokumentiert werden (vgl. Wisskirchen 2007, 19f.). Aufgrund der bisherigen Rechtsprechung ist bei Outsourcing der Systemanwendung damit zu rechnen, dass eine Verletzung des Benachteiligungsverbots durch den Dienstleister dem Arbeitgeber zugerechnet wird (vgl. Müthlein & Jaspers 2007, 37).

3.4

Datenübermittlung Weiter existieren Rechtsvorschriften, die den Arbeitgeber zur elektronischen Erfassung und Übermittlung von Personaldaten verpflichten und ihn (oder einen von ihm beauftragten Dienstleister) so in die Anwendung entsprechender Informationssysteme zwingen. Eine zentrale Vorschrift ist hierbei die »Verordnung über die Erfassung und Übermittlung von Daten für die Träger der Sozialversicherung (DEÜV)«. Diese Verordnung verpflichtet den Arbeitgeber zu konkret definierten Meldungen an die Sozialversicherungsträger. Meldungen können dabei einmalig anfallen, wie etwa die An- oder Abmeldung von Mitarbeitern und die Meldung von einmalig gezahltem Arbeitsentgelt, oder aber regelmäßig wie etwa umfassende Jahresmeldungen oder Meldungen von Arbeitsentgelt. Die Verordnung normiert, dass Meldungen auf dem Wege elektronischer Datenübertragung stattzufinden haben und entsprechende Maßnahmen zu Datensicherheit und Datenschutz zu treffen sind. Historisch bedingt werden solche Meldungen regelmäßig von Personalabrechnungssys-

50

3.5

Lohnbuchhaltung

temen übernommen (vgl. Kap. 13). Zur Sicherstellung der korrekten Durchführung der Abrechnung, der Erstellung der geforderten Meldungen und der technischen Sicherheit haben sich die Spitzenverbände der gesetzlichen Krankenversicherungen auf ein Prüfverfahren entsprechender Personalabrechnungssysteme geeinigt, das nach erfolgreicher Absolvierung zu einer Zertifizierung des Systems (»GKV Zertifikat« bzw. »ITSG-Zertifikat«) führt (www.gkv-ag.de).

3.5

Lohnbuchhaltung Weiterhin ergeben sich aus verschiedenen Gesetzen und Richtlinien zur Buchführung auch für die regelmäßig im Personalmanagement verortete Lohnbuchhaltung verschiedene Durchführungs- und Dokumentationspflichten. Relevant sind in diesem Zusammenhang insbesondere ƒ die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) und ƒ die Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU). Betroffene Systemkategorien sind damit Personalabrechnungssysteme (vgl. Kap. 13) sowie Dokumentenmanagementsysteme (vgl. Kap. 6), soweit sie Lohnbuchhaltungsbelege archivieren.

GoBS

Die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) regeln die Behandlung aufbewahrungspflichtiger Daten und Belege im Rahmen der Buchführung. Dabei sind ausdrücklich auch solche buchhaltungsrelevante Daten und Belege zu berücksichtigen, die außerhalb des eigentlichen Buchhaltungsbereichs anfallen. Entsprechend fallen auch Daten und Belege der Lohnbuchhaltung unter die GoBS. Die Ordnungsvorschriften betreffen zunächst die richtige, vollständige und zeitgerechte Erfassung der Daten und Belege. Dabei wird auch auf entsprechende Techniken der Datenübernahme und des Scannens eingegangen. Ebenso werden Vorschriften zur geordneten, nachvollziehbaren Speicherung und Abfrage von Daten und Belegen gemacht. Weiter muss ein internes Kontrollsystem etabliert werden, das systematische organisatorische und technische Maßnahmen zur Einhaltung dieser Vorschriften vorsieht. Ebenso wird auch eine Verfahrensdokumentation gefordert, die den gesamten technisch-organisatorischen Prozess der Erfassung, Speicherung und Abfrage der Daten und Belege sowie die Maßnahmen des internen Kontrollsystems beschreibt (vgl. Arbeitsgemeinschaft wirtschaftliche Verwaltung 2001). 51

3

Rechtliche Grundlagen

GDPdU

52

Gemäß der »Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU)« hat die Finanzverwaltung das Recht, die mit einem Informationssystem erstellte Buchführung eines Unternehmens durch Datenzugriff zu prüfen. Nach § 147 Abs. 6 Abgabenordnung sind die Daten der Finanz-, Anlagenund Lohnbuchhaltung für den Zugriff bereitzustellen. Entsprechend sind aus Sicht des Personalmanagement erneut Daten in Personalabrechnungssystemen und korrespondierende Belege in Dokumentenmanagementsystemen betroffen. Der Datenzugriff kann dabei auf unterschiedliche Weise erfolgen: Bei einem unmittelbaren Datenzugriff erhält die Finanzbehörde direkten lesenden Zugriff auf die Personalabrechnungsdaten, einschließlich der Stammdaten und Verknüpfungen. Sie verwendet dabei ausschließlich die Soft- und Hardware des Unternehmens, wobei der Zugriff Lesen, Filtern und Sortieren ggf. unter Rückgriff auf vorhandene Standardauswertungen erfolgt. Ein Online-Zugriff ist explizit ausgeschlossen. Bei einem mittelbaren Zugriff werden die geforderten Auswertungen durch das Unternehmen selbst oder einen mit der Abrechnung beauftragten Dienstleister (»Outsourcer«) durchgeführt. Bei der Datenträgerüberlassung werden die relevanten Daten mit Metadaten (Dateistruktur, Datenfelder, Verknüpfungen etc.) den Finanzbehörden zur Auswertung überlassen. Die Finanzverwaltung hat in Zusammenarbeit mit den Herstellern von Personalabrechnungs-, Finanzbuchhaltungs- und Archivierungssystemen einen Bereitstellungsstandard entwickelt, der eine automatisierte Übernahme der steuerlich relevanten Daten sowie der Strukturinformationen unterstützt. Ebenso wurde eine einheitliche Prüfsoftware (»I-DEA«) entwickelt (www.gdpduportal.com). Die Daten sind nach der Prüfung an das Unternehmen zurückzugeben oder zu löschen.

Teil B Datenhaltungssysteme

4

Datenbanksysteme Datenbanksysteme (Datenbankmanagement-Systeme, Datenbanken, »Data Base [Management]-Systems [DBMS]«) sind Anwendungen zur Abspeicherung, Verwaltung und (Wieder-)Bereitstellung großer Datenmengen.

4.1

Architektur und Funktionalität von Datenbanksystemen Üblicherweise werden bezüglich des Aufbaus von Datenbanksystemen neben der obligatorischen Anwenderschnittstelle die Komponenten der Datenbank, das Datenverwaltungssystem und mögliche Entwicklungssprachen bzw. -werkzeuge unterschieden (vgl. Abb. 4.1). Datenbanksystem Anwenderschnittstelle Datenbankverwaltungssystem Datenbeschreibungssprache (DDL)

Datenbank

Datei1

Datei2

Datenmanipulationssprache (DML) Datei3

Datenabfragesprache (DQL) Entwicklerwerkzeug

Datei...

Abb. 4.1: Idealtypische Architektur von Datenbanksystemen Die Datenbank übernimmt dabei die eigentliche Datenspeicherung. Das Datenbankverwaltungssystem ist für die Definition, Manipulation und Abfrage der Datenbank zuständig. Teilweise vorhandene Entwicklerwerkzeuge ermöglichen darüber hinaus die Entwicklung individueller datenbankbasierter Anwendungssysteme.

55

4

Datenbanksysteme

4.1.1

Datenbank Die Datenbank dient der eigentlichen Speicherung und Haltung von Daten. Daten sind eine Darstellungsform von Informationen, die für die maschinelle Speicherung, Verarbeitung und Übertragung geeignet sind.

Datenarten

Nach ihrer Codierung können zunächst codierte Daten und nicht-codierte Daten unterschieden werden. Codierte Daten sind zeichenorientiert und umfassen Buchstaben, Zahlen und Sonderzeichen, die entweder in strukturierter Form systematisch nach einer fest vorgegebenen Datenstruktur vorliegen können oder in unstrukturierter Form im Sinne so genannter Volltexte. Nichtcodierte Daten sind bitorientiert und umfassen etwa Grafiken, Audio- und Videodokumente. Während frühere Datenbanken regelmäßig lediglich codierte Daten in Form kurzer, strukturierter Zahlen- und Textinformationen speichern konnten, ist inzwischen die Ablage nahezu beliebiger Dokumententypen möglich (vgl. auch Kap. 6). Entsprechend können in Datenbanken nicht mehr nur codierte, strukturierte Personaldaten abgelegt werden, sondern beispielsweise auch Bilddateien mit Mitarbeiterfotos. Gleichwohl kommt im Rahmen personalwirtschaftlicher Datenverarbeitung den codierten, strukturierten Daten nach wie vor die zentrale Bedeutung zu. Nach der Art der Daten lassen sich Stammdaten und Bewegungsdaten unterscheiden. (Personal-) Stammdaten beziehen sich auf feststehende, identifizierende oder klassifizierende Mitarbeiterattribute wie etwa »Name« oder »Geschlecht«. Bewegungsdaten sind abwicklungsorientierte, im Zeitablauf immer wieder neu entstehende Daten wie beispielsweise »Kommt-Zeit« oder »Monatliche Mehrarbeit«. Nach der Art der Entstehung können schließlich Eingabedaten und Ergebnisdaten unterschieden werden. Eingabedaten sind von diversen Anwendern einzupflegen, während Ergebnisdaten wie etwa »Nettogehalt« automatisch als Resultat von Verarbeitungsvorgängen eines Anwendungssystems in die Datenbank eingestellt werden.

Datenorganisation

Die Daten der Datenbank werden grundsätzlich in einer hierarchischen Struktur geordnet, die zwischen Datenfeldern, Datensegmenten, Datensätzen und Dateien unterscheidet. Die kleinste logische Einheit bildet das Datenfeld (Datenelement). Ein Datenfeld beschreibt verschiedene Attribute eines Objektes, z.B. Vorund Nachname eines Mitarbeiters. Logisch zusammengehörige Datenfelder können zu Datensegmenten (Datengruppen) zusammengefasst werden, wie z.B. Vor- und Nachname zum Datensegment Name (vgl. Abb. 4.2).

56

4.1

Architektur und Funktionalität von Datenbanksystemen Personal

Datei

Datensätze

Mitarbeiter1

Datensegmente Datenfelder

Mitarbeiter2

Mitarbeiter3

Name

Pers.Nr.

Vorname

Nachname

Mitarbeiter...

Anschrift

PLZ

Ort

Straße

Gehalt

Abb. 4.2: Datenorganisation (Stahlknecht & Hasenkamp 2005, 136) Die Gesamtheit der Datenfelder eines Objektes bildet dann einen Datensatz, z.B. einen Mitarbeiterdatensatz. Gleichartig strukturierte Datensätze werden zu einer Datei zusammengefasst. Z.B. bildet die Gesamtheit der Mitarbeiterdatensätze die Datei »Personal«. Datenbanken können dabei aus mehreren Dateien bestehen, zwischen denen auch logische Beziehungen existieren können (vgl. Stahlknecht & Hasenkamp 2005, 135ff.). Etwa könnte zusätzlich zur Personaldatei auch eine Stellendatei existieren, wobei Mitarbeiterdatensätze der Personaldatei logisch mit Stellendatensätzen der Stellendatei verknüpft werden. Die konkrete Art logischer und physischer Datenstrukturierung hängt allerdings vom gewählten Datenbankmodell ab. Im Rahmen personalwirtschaftlicher Systeme gebräuchliche Datenbankmodelle sind ƒ das lineare Datenbankmodell, ƒ das relationale Datenbankmodell, ƒ das objektorientierte Datenbankmodell und ƒ das multidimensionale Datenbankmodell. Lineares Datenbankmodel

Datenbanken nach dem linearen Datenbankmodell (»Flatfile«) enthalten ausschließlich Datensätze eines einzigen Typs. Solche lineare Dateien entsprechen daher einer einzelnen Tabelle, in der die Datensätze in den Zeilen und die Datenfelder in den Spalten dargestellt werden. Aufgrund der Einfachheit und Übersichtlichkeit findet das lineare Datenbankmodell etwa in einfachen Mikrorechnerdatenbanken durchaus verbreitete Anwendung.

57

4

Datenbanksysteme

Relationales Datenbankmodell

58

Für gegenwärtige personalwirtschaftliche (wie sonstige) Anwendungen von besonderer Bedeutung ist das relationale Datenbankmodell (vgl. Codd 1970). Ausgehend von dem Gedanken einer effizienten Datenhaltung und der Vermeidung möglicher Datenanomalien werden Datensätze (im relationalen Datenbankmodell auch »Tupel« genannt) in verschiedenen Tabellen (im relationalen Datenbankmodell auch »Relationen« genannt) gehalten, die miteinander in Beziehungen stehen. Zur eindeutigen Identifikation von Datensätzen sowie zur Verknüpfung von Datensätzen unterschiedlicher Tabellen werden Schlüssel verwendet. Schlüssel sind einzelne Datenfelder (einfacher Schlüssel) oder Kombinationen mehrerer Datenfelder (zusammengesetzter Schlüssel), mittels derer jeder Datensatz einer Tabelle eindeutig identifiziert werden kann. Als so genannte »Schlüsselkandidaten« kommen alle Datenfelder in Frage, die geeignet sind, die Datensätze einer Tabelle eindeutig zu identifizieren. Beispielsweise wäre das Datenfeld »Nachname« kein geeigneter Schlüsselkandidat zur Identifikation der Datensätze einer Tabelle »Personal«, weil gleiche Nachnamen mehrfach vorkommen können. Dagegen bildet etwa eine jeweils nur einmal vergebene »Personalnummer« einen geeigneten Schlüsselkandidaten. Derjenige Schlüsselkandidat, der tatsächlich zur Identifikation der Datensätze herangezogen wird, wird Primärschlüssel der Tabelle genannt. Alle anderen geeigneten Schlüsselkandidaten werden damit notwendig zu »Sekundärschlüsseln« (vgl. Stahlknecht & Hasenkamp 2005, 174). Die Verbindung zwischen Datensätzen verschiedener Tabellen wird über die Schlüssel realisiert. Das Primärschlüsselfeld (PS1) einer Tabelle1 findet sich auch als Feld einer verbundenen Tabelle2, wo es Fremdschlüssel (FS1) genannt wird, da diese Tabelle wiederum über einen eigenen Primärschlüssel (PS2) verfügt (vgl. Abb. 4.3). Identische Ausprägungen dieses Schlüsselfeldes {a, b, c, ...} in beiden Tabellen zeigen dann auf, welche Datensätze der beiden Tabellen jeweils korrespondieren. Auf diese Weise können beispielsweise Datensätze einer Tabelle »Personal« mit Datensätzen einer Tabelle »Stelle« so verknüpft werden, dass jeder Mitarbeiterdatensatz exakt einem jeweils korrespondierenden Stellendatensatz zugeordnet ist. Allerdings muss ein Datensatz einer Tabelle nicht zwangsweise mit genau einem Datensatz einer anderen Tabelle verknüpft werden. Mögliche Beziehungstypen sind vielmehr ƒ die 1:1 Beziehung, ƒ die 1:n Beziehung und ƒ die m:n Beziehung.

4.1

Architektur und Funktionalität von Datenbanksystemen

Tabelle1

Tabelle2

PS1

...

...

...

a

...

...

...

b

...

...

...

c

...

...

...

PS2

FS2

...

...

Į

a

...

...

ȕ

b

...

...

Ȗ

c

...

...

Abb. 4.3: Tabellen im relationalen Datenbankmodell Bei der 1:1 Beziehung korrespondiert ein Datensatz aus Tabelle1 mit maximal einem Datensatz aus Tabelle2. Die angesprochene Verwendung dieser Beziehungsart zur Verknüpfung von Personal- und Stellendatensätzen ist also nur dann sinnvoll, wenn ein Mitarbeiter tatsächlich nur eine Stelle einnehmen kann. Existieren beispielsweise Teilzeitstellen, von denen ein Mitarbeiter mehrere gleichzeitig bekleiden kann, dann empfiehlt sich die Verwendung einer 1:n Beziehung. Einem Datensatz in der Tabelle »Personal« können dann mehrere Datensätze der Tabelle »Stelle« entsprechen. Ist es zusätzlich so, dass Vollzeitstellen auch von zwei oder mehr Teilzeitmitarbeitern besetzt werden können, dann ist eine m:n Beziehung zu verwenden. In diesem Fall kann nicht nur ein Datensatz der Tabelle »Personal« mit mehreren Datensätzen der Tabelle »Stelle« verknüpft werden, sondern umgekehrt auch ein Datensatz der Tabelle »Stelle« mit mehreren Datensätzen der Tabelle »Personal«. Der adäquate Beziehungstyp hängt entsprechend von den realen Beziehungen der in den Tabellen abzubildenden Sachverhalte ab und ist daher im Rahmen der Implementierung, speziell der so genannten semantischen Datenmodellierung, zu bestimmen. Um zu einer effizienten Tabellenstruktur zu gelangen, werden entsprechende Daten schrittweise in mehrere verbundene Tabellen zerlegt. Dieser Prozess wird mit Normalisierung bezeichnet. Objektorientiertes Das objektorientierte Datenbankmodell repräsentiert reale ObjekDatenbankmodell te direkt in einem Datenbankobjekt. Während etwa im relationalen Modell die Attribute eines Objektes in verschiedenen Tabellen abgelegt sind, werden diese im objektorientierten Modell direkt dem Datenbankobjekt zugeordnet. Dabei existiert ebenfalls 59

4

Datenbanksysteme im Unterschied zum relationalen Datenbankmodell keine feste Datenfeldstruktur. Die Zahl der Datenfelder kann frei bestimmt werden und entsprechend auch bei vergleichbaren Objekten unterschiedlich sein. Entsprechend könnten Mitarbeiter als Datenbankobjekt mit jeweils unterschiedlichen Attributen beschrieben werden. Dies führt zu hoher Abbildungsflexibilität, die es erlaubt bei jedem Datensatz genau diejenigen individuellen Datenfelder anzulegen, die jeweils relevant sind. Ohne relationale Datenbankmodelle verdrängen zu können, erlangen objektorientierte Datenbanken daher zunehmende Relevanz.

77

234 123 322 111

89

Kennzahl (z.B. Personalbestand)

98

345 134 114 Dimension2 (z.B. Projekt)

( z Di m .B e . S ns ta ion nd 3 or t)

Dimension1 (z.B. Zeit)

Multidimensiona- Den zentralen Einsatzweck des multidimensionalen Datenbankmodells bilden Analysen des Managements, speziell das so geles Datenbanknannte »Online Analytical Processing (OLAP)«. Aus diesem Grund modell kommen multidimensionale Datenbanken insbesondere als Datenbasis von Data Warehouse- (vgl. Kap. 5) und OLAP-Systemen (vgl. Kap. 11) zum Einsatz. Die wesentliche Anforderung von Analysen des Managements ist, dass relevante Kennzahlen (z.B. Personalbestand) nach mehreren Dimensionen gleichzeitig analysiert werden können (z.B. nach Projekt, nach Zeiteinheit und nach Standort). Zu diesem Zweck werden Daten im multidimensionalen Datenbankmodell in mehrdimensionalen Datenwürfeln organisiert, deren Kanten die jeweiligen Dimensionen darstellen, während die interessierenden Kennzahlen in den Zellen des Würfels gehalten werden (vgl. Abb. 4.4).

Abb. 4.4: Datenwürfel im multidimensionalen Datenmodell So wird es möglich, eine Kennzahl nach mehreren Dimensionen gleichzeitig auszuwerten. Dabei sind auch mehr als drei Analysedimensionen denkbar. Der Datenwürfel wird dann zum so genannten Hyperwürfel (»Hypercube«) (Pedersen & Jensen 2001, 44f.). 60

4.1

Architektur und Funktionalität von Datenbanksystemen

HR-XML

Vor dem Hintergrund einer zunehmenden Verbreitung webbasierter Systeme (vgl. auch Kap. 28) existieren unter der Bezeichnung »HR-XML« inzwischen Bestrebungen, auf der Basis von XML Industriestandards für personalwirtschaftliche Datenstrukturen und einen darauf basierenden Datenaustausch über Internet zu schaffen (vgl. Scholz 2003). Ein Konsortium aus Software- und Beratungsunternehmen bemüht sich um die Entwicklung und Veröffentlichung solcher Datenaustauschstandards (www.hr-xml. org). Zentrales Ziel ist es, personalbezogene Datenstrukturen und -austauschvorgänge zu standardisieren, um die Probleme und Kosten von Ad-hoc-Absprachen zu Datenaustauschmechanismen zwischen verschiedenen Unternehmen zu vermeiden. Entsprechend können Hersteller webbasierter Systeme und webbasierte Service Provider die Datenhaltungsschichten ihrer Systeme im Hinblick auf die Einhaltung dieser Standards zertifizieren lassen (www.hrcertify.org). Zwischen den Datenhaltungsschichten solcher Systeme können Daten dann in den vorgegebenen Standards einfach und unkompliziert ausgetauscht werden. So können beispielsweise im Rahmen der Personalbeschaffung intern generierte Stellenausschreibungsdaten direkt an eine Internet-Jobbörse weitergeleitet werden. Dort eingehende Bewerbungsdaten können dann direkt in die entsprechenden internen Systeme überspielt werden (vgl. Mülder 2003a, 99f.).

4.1.2

Datenbankverwaltungssystem Datenbankverwaltungssysteme dienen der Definition, Manipulation und Abfrage von Daten. Diese Aufgaben werden entweder durch eine Datenbankverwaltungssprache und/oder durch entsprechende Datenbankverwaltungswerkzeuge realisiert. Datenbankverwaltungssprachen präsentieren sich dem Anwender als befehlsorientierte Systeme, während Datenbankverwaltungswerkzeuge menügesteuerte und damit gemeinhin als leichter zu bedienend geltende Oberflächen verwenden. Datenbanksprachen wie -werkzeuge unterscheiden sich dabei je nach Datenbankmodell und -anbieter. Für den wichtigen Bereich relationaler Datenbanksysteme hat sich allerdings SQL (»Structured Query Language«) als Datenbankverwaltungssprache durchgesetzt. SQL wurde in den 1970er Jahren von IBM entwickelt und wird von den einzelnen Anbietern inzwischen in verschiedenen Versionen und Erweiterungen angeboten. Entsprechend sind zentrale Datenbanksysteme »SQL-fähig«.

Datenbankdefinition

Die Datenbankdefinition stellt den letzten und zentralen Schritt der Datenbankimplementierung dar. Generell müssen hierbei die 61

4

Datenbanksysteme semantisch und logisch vormodellierten Daten in physische Datenstrukturen eines Datenbanksystems umgesetzt werden. Dieser Prozess wird von einer Datendefinitionssprache (»Data Definition Language«) bzw. einem korrespondierenden Datendefinitionswerkzeug unterstützt. Die Datenbankdefinition umfasst damit das grundsätzliche Erstellen der Datenbank und – je nach verwendetem Datenbankmodell – entsprechender Datenstrukturen. Im relationalen Datenbankmodell müssen entsprechend Tabellen mit Datenfeldern und Schlüsseln definiert werden. So können etwa mittels des SQL-Befehls »CREATE TABLE Tabelle (Datenfeld1 Datentyp, Datenfeld2 Datentyp, ...)« eine Tabelle sowie Art und Anzahl der enthaltenen Datenfelder definiert werden. Üblicherweise gehört auch die Festlegung verschiedener Validierungsmechanismen zur Datendefinition. Üblich sind beispielsweise die Definition von »Muss«-Datenfeldern zur Verhinderung unvollständiger Eingaben, die Definition von zulässigen Datenformaten zur Verhinderung der Eingabe falscher Datenformate oder die Definition von Plausibilitäten zur Verhinderung logisch unmöglicher Eingaben wie z.B. die Eingabe von Mutterschutzzeiten bei männlichen Mitarbeitern. Die extensive Anwendung solcher Mechanismen bedeutet allerdings einen entsprechenden Aufwand bei der Datendefinition und kann zu Performanzverlusten führen.

Datenbankmanipulation

Die Datenbankmanipulation bezieht sich auf nachträgliche Änderungen, Löschungen und Ergänzungen sowohl der Datenbankstruktur als auch des Datenbestandes. Zentrale Aufgaben bestehen hier beispielsweise im Hinzufügen oder Löschen von Datenfeldern oder Datensätzen. Auch dieser Prozess wird regelmäßig von einer Datenmanipulationssprache (»Data Manipulation Language«) und/oder einem korrespondierenden Datenmanipulationswerkzeug unterstützt. Beispielsweise kann in relationalen Datenbanken mit dem SQL-Befehl »ALTER TABLE Tabelle ADD Datenfeld Datentyp« einer bereits definierten Tabelle ein neues Datenfeld hinzugefügt werden oder mit dem SQL-Befehl »DELETE FROM Tabelle WHERE Datenfeld = ‚Wert’« über die Ausprägung eines Datenfeldes spezifizierte Datensätze einer Tabelle gelöscht werden.

Datenbankabfrage

Die Datenbankabfrage (»Query«) wird durch eine Datenabfragesprache (»Data Query Language [DQL]«) und/oder ein Datenabfragewerkzeug unterstützt und zielt grundsätzlich auf ƒ Information von Anwendern (Informationsabfrage) oder ƒ Veränderung der Daten (Veränderungsabfrage).

62

4.1

Architektur und Funktionalität von Datenbanksystemen

Zentrale Varianten der Informationsabfrage bilden die Standardabfrage und die Kreuztabellenabfrage. Bei einer Standardabfrage werden i.d.R. näher spezifizierte Teilmengen des Datenbestandes unter Verwendung von Selektionskriterien ausgewählt. Zur Formulierung von Selektionskriterien sind entsprechende Datenfelder, erwünschte Vergleichsoperatoren wie »größer«, »kleiner«, »gleich«, »größergleich«, »kleinergleich« und erwünschte Vergleichswerte bzw. Vergleichstexte anzugeben. Unter zusätzlicher Verwendung von logischen Operatoren wie »und« oder »oder« können auch mehrere Selektionskriterien gleichzeitig verwendet werden. Beispielsweise selektiert der SQL-Befehl »SELECT Nachname, Wohnort, Nettogehalt FROM Personal WHERE Wohnort = ‘Saarbrücken‘ AND Nettogehalt > 3.000« die Nachnamen, Wohnorte und Nettogehälter genau derjenigen Mitarbeiter aus der Tabelle »Personal«, die in Saarbrücken wohnen und deren Nettogehalt mehr als 3.000 Geldeinheiten beträgt. In aller Regel werden die Abfrageergebnisse dann in Tabellenform ausgegeben (vgl. Abb. 4.5). »SELECT Nachname, Wohnort, Nettogehalt FROM Personal WHERE Wohnort = ‘Saarbrücken‘ AND Nettogehalt > 3.000« Nachname

Wohnort

Nettogehalt

Meier

Saarbrücken

3.444€

Müller

Saarbrücken

4.666€

Schmidt

Saarbrücken

3.451€

Korz

Saarbrücken

7.908€

...

...

...

Abb. 4.5: Spezifikation und Ergebnis einer Standardabfrage mit SQL Abfragen können sich dabei auch auf Datenfelder mehrerer Tabellen beziehen. Für komplexere Analysezwecke können Abfragen darüber hinaus nicht nur auf Tabellen, sondern oft auch auf anderen, zuvor spezifizierten Abfragen basieren. Obwohl die Standardabfrage damit zweifellos ein leistungsfähiges Informationsinstrumentarium zur Verfügung stellt, zeigen sich insbesondere bei der Abfrage personalwirtschaftlicher Kennzahlen (Wertoder Mengengrößen) Beschränkungen im erzeugbaren Informa63

4

Datenbanksysteme tionsgehalt, der durch Kreuztabellenabfragen (Pivot-Abfrage, »Pivottable«) erweitert wird. Eine Kreuztabellenabfrage zeigt zusammengefasste Werte (Summen, Anzahlen, arithmetische Mittel) eines wert- oder mengenbezogenen Datenfeldes und gruppiert diese nach zwei Auswertungsdimensionen, die in Zeilen und Spalten angezeigt werden. Sollen beispielsweise summierte Gehälter nach Personaltyp (Manager oder Mitarbeiter) sowie nach Abteilung (Beschaffung, Produktion oder Vertrieb) gleichzeitig ausgewertet werden, so weist eine Kreuztabellenabfrage Auswertungs- und Darstellungsvorteile gegenüber einer Standardabfrage auf (vgl. Abb. 4.6). Personaltyp

Abteilung

Gehalt

Manager

Beschaffung

30.444€

Manager

Produktion

45.666€

Mitarbeiter

Vertrieb

45.678€

Mitarbeiter

Beschaffung

87.908€

Manager

Vertrieb

23.451€

Mitarbeiter

Produktion

120.567€

Personaltyp

Abteilung

Manager

Mitarbeiter

Ȉ

Beschaffung

30.444€

87.908€

118.352€

Produktion

45.666€

120.567€

166.233€

Vertrieb

23.451€

45.678€

69.129€

Ȉ

99.561€

254.153€

353.714€

Abb. 4.6: Standardabfrage vs. Kreuztabellenabfrage Die einfache Kreuztabelle bietet damit eine erste Form multidimensionaler Datenanalyse. Durch die Verwendung von mehr als einer Analysedimension in den Zeilen und/oder den Spalten einer Kreuztabelle eignet sich eine Kreuztabellenabfrage auch zur Abfrage multidimensionaler Datenbanken. Insbesondere unter der Bezeichnung »Pivot-Abfrage« findet die Kreuztabellenabfrage daher zunehmend Verwendung in diesem Bereich. Die Ergebnisse von Informationsabfragen können zunehmend auch in entsprechende Geschäftsgrafiken wie Balken-, Kreis-, Punkt- oder Liniendiagramme umgesetzt werden. Eine Variante der Informa64

4.1

Architektur und Funktionalität von Datenbanksystemen

tionsabfrage bilden Berichte (»Reports«). Während das Ergebnis von Informationsabfragen üblicherweise in Tabellenform auf Bildschirm ausgegeben wird, zielen Berichte auf eine Ausgabe durch Druck auf Papier zur Unterstützung der Präsentation und Analyse der Daten. In aller Regel werden Daten dabei systematisch in Listenform präsentiert. Berichte können zusätzlich auch Berechnungen und korrespondierende Geschäftsgrafiken enthalten. Aus diesem Grund bilden so genannte Berichtsgeneratoren oft eine Komponente der Abfragewerkzeuge eines Datenbanksystems. Berichtsgeneratoren unterstützen dabei sowohl die Spezifikation der entsprechenden Abfrage, auf der der spätere Bericht basieren soll, als auch die Formatierung und Layoutgestaltung für die Druckausgabe. Zentrale Varianten der Veränderungsabfrage bilden die Aktualisierungsabfrage und die Anfügeabfrage. Eine Aktualisierungsabfrage führt zu generellen Änderungen an einer definierten Gruppe von Datensätzen. Um aufwändige Einzelaktualisierungen zahlreicher Datensätze zu verhindern, kann so beispielsweise das Datenfeld »Gehalt« für eine ganze Gruppe von einer Tariferhöhung betroffener Mitarbeiter effizient aktualisiert werden. Eine Anfügeabfrage fügt eine Gruppe von Datensätzen aus einer oder mehreren Tabellen am Ende einer anderen Tabelle oder mehrerer anderer Tabellen an. Verfügt man beispielsweise aus einer Tabelle »Bewerber« bereits über entsprechende Daten von aktuell eingestellten Mitarbeitern, können diese Daten per Anfügeabfrage an der Tabelle »Mitarbeiter« angefügt und so eine redundante Neueingabe der Daten vermieden werden. Da mit solchen Abfragen erkennbar Daten manipuliert werden, werden Abfragen auch oft dem Bereich der Datenmanipulation zugerechnet und die Datenbankabfrage nicht als eigenständiger Aufgabenbereich einer Datenbankverwaltung gesehen. Neuere Datenbanksysteme weisen im Rahmen ihrer Abfragesprachen/-werkzeuge neben konventionellen Abfragen zunehmend auch Möglichkeiten der so genannten Wissensentdeckung in Datenbanken (»Knowledge Discovery in Databases [KDD]«, »Data Mining«) auf. Dabei können neue, bisher unbekannte, gültige und potenziell nützliche Muster in den Daten erkannt werden (vgl. dazu Kap. 12).

4.1.3

Entwicklungswerkzeuge Zunehmend verfügen Datenbanksysteme auch über Entwicklungssprachen bzw. -werkzeuge, die die individuelle Entwick65

4

Datenbanksysteme lung von datenbankbasierten Anwendungssystemen zulassen. Mit Gestaltungsoptionen wie etwa der Erstellung verschiedener miteinander in Beziehung stehender Formulare zur Eingabe und Anzeige von Daten verfügen Datenbanksysteme bereits ohne explizite Entwicklerwerkzeuge über Möglichkeiten der Erstellung individueller Datenbanksysteme. Die Grenzen solcher Gestaltungsoptionen zu expliziten datenbankinternen Entwicklungswerkzeugen sind dabei oft fließend. Datenbankinterne Entwicklungswerkzeuge ermöglichen es dem Anwender neben klassischen Datenbankfunktionen auch komplexere Funktionen, wie anspruchsvollere mathematische Verarbeitungen der Daten, im Rahmen eines individuellen datenbankbasierten Anwendungssystems anzubieten. Neben entsprechenden formalen Programmiersprachen werden Entwicklungsmöglichkeiten zunehmend auch durch grafische Entwicklungsumgebungen angeboten. Solche visuellen Systeme, stellen vorgefertigte Systemkomponenten wie etwa Dropdown-Listen, Druckbefehle, Diagramme etc. zur Verfügung. Diese Systemkomponenten werden über Auswahlmenüs selektiert, an der gewünschten Stelle positioniert, um dann die gewünschten Eigenschaften zu konkretisieren. Entsprechend können mittels dieser Komponenten komplette individuelle Anwendungen zusammengestellt werden. Der nötige Quellcode wird dabei automatisiert vom Entwicklerwerkzeug generiert.

4.2

Anwendung von Datenbanksystemen Bezogen auf ihre Anwendung im Personalmanagement weisen Datenbanksysteme einen hybriden Charakter auf, denn sie können als schichtspezifische Datenhaltungssysteme und/oder als schichtübergreifende Anwendungssysteme Verwendung finden.

Anwendungsvarianten

66

Datenbanksysteme dienen zunächst zur Realisierung der Datenhaltungsschicht personalwirtschaftlicher Systemarchitekturen und erbringen daher Datenhaltungsdienstleistungen für Systeme höherer Schichten. Entsprechend wird insbesondere die effiziente Abspeicherung und Bereitstellung von sehr großen Datenmengen durch diese Systemkategorie gewährleistet. Gerade in dieser Anwendungsvariante kommt Datenbanksystemen auch für das Personalmanagement große Bedeutung zu (vgl. Mülder 2004, 1538). Für den reinen Endanwender ist die Verwendung von Datenbanksystemen als Datenhaltungssystem allerdings von nachrangigem Interesse, da sie im »Backend«-Bereich verortet ist und i.d.R. von entsprechenden Datenbankadministratoren betreut

4.2

Anwendung von Datenbanksystemen

wird. Die umfangreichen Potenziale gegenwärtiger Datenbanksysteme ermöglichen aber auch ihren Einsatz als Anwendungssystem. Gerade die in umfangreicheren Office-Pakten verfügbaren Datenbanksysteme eröffnen vielfältige Anwendungsszenarien im Personalmanagement. Speziell die Realisierung der generellen Personaldatenhaltung und eines darauf basierenden Analyseund Berichtssystems (Personalinformationssystem i.e.S.) ist ohne weiteres möglich. Tatsächlich stellen viele kommerziell angebotene Personalinformationssysteme i.e.S. faktisch einfache datenbankbasierte Anwendungen dar. Diese nehmen dem Anwender zwar die Datenmodellierung und den Entwurf entsprechender Formulare bzw. Oberflächen ab, bieten aber mit der Möglichkeit der Erstellung von Ad-hoc-Abfragen und Berichten im Kern »lediglich« Funktionalitäten des Datenbankverwaltungssystems an. Aus diesem Grund wird im Folgenden auf eine separate Darstellung dieser Systemkategorie verzichtet. Ähnliches gilt für einfachere Systeme etwa im Bereich der Bewerber- oder Seminarverwaltung. Darüber hinaus lassen sich – unter Verwendung von Entwicklerwerkzeugen – letztlich beliebige personalwirtschaftliche Anwendungssysteme entwickeln. Verbreitung

Empirische Studien zur Verbreitung von Datenbanksystemen im Personalmanagement sind derzeit nicht bekannt. Insbesondere zur Datenhaltung von personalwirtschaftlichen Anwendungssystemen dürften Datenbanksysteme inzwischen allerdings wohl flächendeckenden Einsatz finden.

67

5

Data Warehouse-Systeme Data Warehouse-Systeme sind Anwendungen zur Zusammenführung und Haltung von personalwirtschaftlichen (und weiteren) Daten aus verschiedenen anderen Quellsystemen für Zwecke der Informationsversorgung und Entscheidungsunterstützung des Personalmanagements (sowie weiterer Bereiche). Data Warehouse-Systeme halten dabei speziell Daten für Business IntelligenceSysteme (BI), d.h. Online Analytical Processing-Systeme (vgl. Kap. 11) und Data Mining-Systeme (vgl. Kap. 12).

5.1

Architektur und Funktionalität von Data Warehouse-Systemen Data Warehouse-Systeme bestehen neben der obligatorischen Anwenderschnittstelle üblicherweise aus einer Administrationskomponente, einer Extraktions-, Transformations- und LadeKomponente (ETL), einer Staging Area, einer Datenhaltungskomponente sowie einer Metadatenbank (vgl. Abb. 5.1). Data Warehouse-System Anwenderschnittstelle

Quellsysteme

Quelldokumente

Administration

Datenhaltung Business Intelligence

ETL

Staging Area

Metadaten

ODS

Abb. 5.1: Idealtypische Architektur von Data Warehouse-Systemen Als Teil der Datenaufbereitung dient eine Extraktions-, Transformations- und Ladekomponente der Anbindung von Quellsystemen und der Bereitstellung der Quellsystemdaten für das Data Warehouse. Um die die Quellsysteme möglichst wenig zu belasten, werden die Daten temporär in einer so genannten »Staging 69

5

Data Warehouse-Systeme Area« zwischengespeichert und dort zunächst bereinigt und transformiert, bevor sie in die Datenhaltungskomponente geladen werden. Die Datenhaltungskomponente dient der analyseorientierten Abspeicherung der entscheidungsrelevanten Daten. Die Administrationskomponente dient der Verwaltung von Datenaufbereitung, Datenhaltung und Datenverwendung. Die Metadatenbank stellt umfassende Informationen über das entsprechende Data Warehouse-System zur Verfügung, wozu neben »Daten über Daten« weiter auch Daten zu Quellsystemen, durchgeführten ETL-Vorgängen, Zielsysteme, Auswertungen sowie Anwendern gehören.

Architekturvarianten

Der Aufbau von Data Warehouse-Systemen hängt allerdings auch von der grundsätzlich gewählten Architekturvariante ab. Dabei können grundsätzlich die zentrale Data Warehouse-Architektur, die Data Mart-Architektur und so genannte virtuelle Data Warehouses unterschieden werden (vgl. Abb. 5.2). Business Intelligence

Business Intelligence

Business Intelligence

Data Warehouse

Data Mart1

Data Mart2

Zentrales DW

Data Mart

Business Intelligence

Virtuelles DW

Abb. 5.2: Data Warehouse Architekturvarianten (vgl. Schinzer & Bange 1999, 50) Der dargestellte idealtypische Aufbau gilt dabei nur für die beiden ersten Varianten. Das zentrale Data Warehouse besitzt eine Datenhaltungskomponente, in der die zuvor durch die Datenaufbereitungskomponente gewonnenen entscheidungsrelevanten Daten gespeichert sind. Vorteile liegen in der Performanz, da lediglich »Netto«-Daten an die Analysesysteme weitergeleitet werden, ein Nachteil besteht in den Bereitstellungskosten des Data Warehouse-Systems. Bei einem virtuellen Data Warehouse existiert keine Datenaufbereitungs- und Datenhaltungskomponente 70

5.1

Architektur und Funktionalität von Data Warehouse-Systemen

im physischen Sinne. Die Analysesysteme greifen stattdessen direkt auf die operativen Systeme zu. Dieser Zugriff erfolgt dabei rein lesend, wodurch die Daten in den Quellsystemen vor Änderungen geschützt sind. Auch eine Administrationskomponente und die Metadatenbank fehlen. Die Vorteile liegen in der schnellen, kostengünstigen Realisierbarkeit und der nicht erforderlichen redundanten Speicherung abgefragter Daten. Nachteile werden in der geringen Performanz und der starken Belastung der operativen Systeme gesehen. Einen dritten Architekturtyp bilden Data Marts, die subjektspezifische oder abteilungsspezifische Data Warehouses darstellen. So können beispielsweise in einem HR Data Mart nur die entscheidungsrelevanten personalwirtschaftlichen Daten abgelegt werden. Die Speicherung der Daten erfolgt nicht in einer zentralen Datenbank wie beim zentralen Data Warehouse, sondern die Daten werden im Falle mehrerer Data Marts dezentral auf mehreren Data Warehouse-Servern gespeichert. Die Anwendung der Data Mart-Architektur empfiehlt sich u.a. bei einer räumlich verteilten Nutzung, bei spezifischen heterogenen Informationsbedürfnissen und bei kleineren Projektgrößen. Allerdings ist bei mehreren Data Marts ein zusätzlicher Verwaltungs- und ggf. Abstimmungsaufwand gegeben. In der Praxis werden häufig Mischformen der beschriebenen Architekturen angewendet. Obwohl sich derzeit keine vorherrschende Architektur findet, genießt die so genannte »Hub-and-Spoke«-Architektur, die die zentrale Data Warehouse-Architektur und die Data Mart-Architektur verbindet, relative Verbreitung. Sie besteht aus einem zentralen Data Warehouse mit einem oder mehreren abhängigen Data Marts.

5.1.1

ETL-Komponente Data Warehouse-Systeme dienen der Zusammenführung personalwirtschaftlicher Daten aus verschiedenen Datenhaltungssystemen und Datenhaltungskomponenten personalwirtschaftlicher Anwendungssysteme für Zwecke der Entscheidungsunterstützung. Das zentrale Ziel von Data Warehouse-Systemen ist damit, eine fragmentierte Ausgestaltung der Datenhaltungsschicht mit einer Aufteilung von Personaldaten auf verschiedene heterogene Systeme zu überwinden und Daten für übergreifende integrierte Auswertungen zur Verfügung zu stellen. Entsprechend können in Data Warehouse-Systemen beispielsweise Daten aus Learning Management-Systemen (vgl. Kap. 20), Beschaffungsmanagementsystemen (vgl. Kap. 16) und Personalabrechnungssystemen (vgl. Kap. 13) systematisch zusammengeführt werden. Solche Daten 71

5

Data Warehouse-Systeme liefernden Systeme eines Data Warehouse-Systems werden Quellsysteme und deren Daten »Quelldaten« genannt. Da die Datenstrukturen solcher Quellsysteme meist heterogen sind, müssen die Quelldaten vor ihrer Speicherung in der Datenhaltungskomponente aufbereitet werden. Diese Aufgabe übernimmt die ETLKomponente mit den Prozessschritten Extraktion, Transformation und Laden (vgl. Abb. 5.3).

Transformation

Laden

f(x) f(x)

Harmonisierung

Bereinigung

Extraktion

Ȉ Ȉ

f(x) f(x)

Anreicherung & Verdichtung

Ȉ Ȉ

ȈȈ

harmonisierte harmonisierte Daten Daten

ber. ber. Ex. Ex.

ber. ber. Ex. Ex.

ber. ber. Ex. Ex.

ber. ber. Ex. Ex.

Extrakt Extrakt

Extrakt Extrakt

Extrakt Extrakt

Extrakt Extrakt

Seminar

Abrechnung

Bewerber

...

Abb. 5.3: Prozesse der ETL-Komponente (in Anlehnung an Kemper et al. 2004, 43) Extraktion

72

Der erste Teilprozess, der innerhalb der ETL-Komponente ausgeführt wird, ist die Extraktion. In diesem Teilschritt wird ein Ausschnitt der Daten aus den verschiedenen heterogenen Datenquellen in das Data Warehouse-System übertragen. Dabei müssen unterschiedliche Datenformate und -strukturen berücksichtigt werden. Das Auslesen der Daten kann dabei grundsätzlich synchron oder asynchron erfolgen. Eine synchrone Extraktion, bei der Daten simultan mit ihrer Änderung im Quellsystem auch in das Data Warehouse-System ausgelesen werden, ist wegen der Vielzahl der dann nötigen Extraktionsvorgänge sowie der permanenten Belastung der Quelldatensysteme i.d.R. nicht praktikabel. Daher wird – aus Performancegründen besonders in den »Ruhezeiten« der Quellsysteme – die asynchrone Extraktion bevorzugt. Diese kann periodisch, ereignis- oder anfragegesteuert sein. Bei

5.1

Architektur und Funktionalität von Data Warehouse-Systemen

der periodischen Extraktion werden die Daten in feststehenden regelmäßigen Abständen ausgelesen. Bei der ereignisgesteuerten Extraktion lösen bestimmte Ereignisse, wie beispielsweise eine bestimmte Zahl von Änderungen, das Datenupdate aus. Bei der anfragegesteuerten Extraktion werden Daten auf Anfrage der Administrationskomponente extrahiert. Vor der Durchführung der Extraktion muss ebenfalls die Zugriffsmöglichkeit auf die Quelldatenbestände geregelt werden. Dabei kann direkt auf die operativen Quellsysteme zugegriffen werden, es können – falls bereits verfügbar – Datenexportverfahren angewendet werden, oder es müssen Schnittstellen geschaffen werden. Um eine Verwendbarkeit im Data Warehouse zu gewährleisten, sollten Daten der Quellsysteme vollständig, gültig und aktuell sein. Oft ist dies allerdings nur eingeschränkt der Fall. Entsprechend sind die angebundenen Quellsysteme systematisch auf ihre Datenqualität hin zu prüfen. Häufig sind die Datenbestände der Quellsysteme unvollständig und/oder überaltert (»Dirty Data«). Entsprechend sind zu extrahierende Datenfelder detailliert zu prüfen. Beispielsweise kann der Charakter eines zu extrahierenden Datenfeldes als »Muss-Datenfeld« wertvolle Hinweise auf die Datenqualität der Quellsysteme geben (vgl. Kemper & Finger 2006, 117). Um die Daten im Data Warehouse aktuell zu halten, sind Extraktionsvorgänge im Zeitablauf regelmäßig zu wiederholen. Transformation

Den nächsten Teilschritt der Datenaufbereitung stellt die Transformation dar. Sie beschreibt die Anpassung der extrahierten heterogenen Daten der Quellsysteme an das vorgegebene Datenschema des Data Warehouse-Systems. Dieser Anpassungsprozess gliedert sich in die einzelnen Teilprozesse ƒ Bereinigung, ƒ Harmonisierung, ƒ Verdichtung und ƒ Anreicherung von Quelldaten. Im Rahmen der Bereinigung werden die extrahierten Daten sowohl von syntaktischen als auch von semantischen Mängeln befreit. Ein einfaches Beispiel eines Harmonisierungsvorgangs stellt etwa die Vereinheitlichung der Kodierung des Mitarbeitergeschlechts dar. Werden Mitarbeiterdaten aus zwei unterschiedlichen Quellsystemen extrahiert, die das Geschlecht von Mitarbeitern unterschiedlich kodieren – bspw. in Quellsystem A mit {m, w} und in Quellsystem B mit {0, 1} – dann wird eine Vereinheitlichung der Kodierung notwendig, um heterogene Einträge im Data Warehouse zu verhindern. Je nach Art des Harmonisierungsbedarfs kann man zwischen automatisierten und nicht-automati73

5

Data Warehouse-Systeme sierten (»manuellen«) Bereinigungsvorgängen unterscheiden. Bei antizipierbaren Problemen wie etwa der angesprochenen Vereinheitlichung der Geschlechterbezeichnungen kann die Bereinigung durch automatisierte Prozesse stattfinden. Bei komplexeren Problemen wird allerdings eine oft sehr aufwändige manuelle Bereinigung erforderlich. Haben die Daten eine bereinigte und konsistente Form, erfolgen i.d.R. Verdichtungen (»Prä-Aggregationen«). Da Datenabfragen oft simultan auf unterschiedlichen Aggregationsstufen durchgeführt werden (z.B. Personalkosten je Einzelstandort, je Land und je Kontinent), ist es aus Gründen der Performanz sinnvoll, häufig benötigte Aggregationen bereits im Voraus zu erstellen und redundant abzuspeichern. Ziel einer solchen Verdichtung ist es demnach, aggregierte Datenstrukturen zu erzeugen, auf die in performanz-optimierender Weise direkt zugegriffen werden kann. Im letzten Teilschritt, der Anreicherung, können zu den aufbereiteten Daten zusätzliche Kennzahlen hinzugefügt werden, die sich aus den Daten berechnen lassen (vgl. Muksch & Behme 2000, 41). Beispielsweise ist es möglich, aus den verfügbaren Kennzahlen »Personalkosten Januar«, »Personalkosten Februar« und »Personalkosten März« durch einfache Addition eine neue Kennzahl »Personalkosten 1. Quartal« zu berechnen. Entsprechend können so zusätzlich benötigte personalwirtschaftliche Kennzahlen erzeugt werden.

Laden

Im Anschluss an den Transformationsprozess müssen die Daten in die Datenhaltungskomponente geladen werden. Die Effizienz des Ladens hat dabei eine große Auswirkung auf die Quellsysteme, weil während dieser Phase diese Systeme für die Verwendung entweder vollständig gesperrt oder wegen der hohen Auslastung zumindest nur eingeschränkt nutzbar sind.

5.1.2

Staging Area Zur Entlastung der operativen Quellsysteme finden die Transformationsvorgänge in einem eigenen Arbeitsbereich der »Staging Area« (abgeleitet aus »militärischer Sammelplatz«) statt. Entsprechend werden Datenextrakte aus den Quellsystemen direkt in die Staging Area geladen und hier weiterbearbeitet. Nach Abschluss dieser Vorgänge werden die Daten physisch aus der Staging Area in die einzelnen Bestandteile der Datenhaltungskomponente umgeschichtet.

74

5.1

5.1.3

Architektur und Funktionalität von Data Warehouse-Systemen

Datenhaltungskomponente Die Datenhaltungskomponente stellt den zentralen Kern eines Data Warehouse-Systems dar und enthält aktuelle und historische Daten in unterschiedlichen Verdichtungsstufen und Aufbereitungsvarianten.

Historisierung

Der Zeitbezug von Daten spielt in Data Warehouse-Systemen eine große Rolle. Während die Daten der Quellsysteme oft nur für kürzere Zeiträume »historisiert« werden, zielen Data WarehouseSysteme auf eine längerfristige Historisierung von Daten. Entsprechend werden »alte« Daten im Rahmen zyklischer Aktualisierungen des Data Warehouse durch erneute ETL-Prozesse nicht einfach überschrieben, sondern für vergangenheitsorientierte Analysen weiter vorgehalten. Dabei können Daten bis zu zehn und mehr Jahre historisiert werden. Data Warehouse-Systeme ermöglichen daher Analysen zu aktuellen und historischen Situationen. Allerdings bildet dieses Halten umfangreicher historischer Datenbestände einen ersten Grund für die oft sehr großen Datenbestände von Data Warehouse-Systemen.

Verdichtungsstufen

Wie im Rahmen der Transformation schon angedeutet, werden Daten parallel (und damit redundant) auf unterschiedlichen Verdichtungs- oder Aggregationsstufen vorgehalten. Damit liegen in Data Warehouse-Systemen Daten unterschiedlicher Granularität vor, wobei sehr detaillierte Daten (z.B. auf Belegebene) eine niedrige Granularität besitzen und mit steigender Verdichtung bzw. Aggregation der Daten eine höhere Granularität erreicht wird. In einer so genannten Basisschicht werden detaillierte und disaggregierte Daten auf »Belegebene« gespeichert. n 2

2

Aggregationsschicht 1

1

»Belegebene«

1

Basisschicht

Abb. 5.4: Schichten der Datenhaltungskomponente

75

5

Data Warehouse-Systeme Beispielsweise können hier Arbeitszeitdaten je Tag und Mitarbeiter detailliert abgelegt werden. Die Basisschicht wird meist in Form eines Operational Data Store (»ODS«) realisiert. Dieser verwaltet harmonisierte Detaildaten in der Regel in normalisierter Form. Die Basisschicht fungiert damit als Datenlieferant für das operative Berichtswesen (vgl. Gluchowski & Kemper 2006, 17). In verschiedenen Aggregationsschichten werden die Daten »voraggregiert« und mit einer höheren Granularität abgespeichert. Etwa werden Arbeitszeitdaten dann je Monat, Quartal oder Jahr abgespeichert. Solche aggregierten Daten könnten grundsätzlich auch mittels einer Abfrage auf Grundlage der Basisschicht generiert werden. Allerdings führt dies i.d.R. zu (zu) langen Laufzeiten. Entsprechend werden aus Performanzgründen insbesondere solche Daten aggregiert abgelegt, auf die häufig zugegriffen wird. Abb. 5.4 stellt den Schichtenaufbau einer Datenhaltungskomponente schematisch dar. Das Vorhalten unterschiedlicher Aggregationsschichten bildet zusätzlich auch die Grundlage für (dis-)aggregierende Analysen von Kennzahlen (»Drill down & Roll up«) im Rahmen von OLAP-Systemen (vgl. Kap. 11). Das parallele (und damit redundante) Halten disaggregierter und aggregierter Daten bildet einen zweiten Grund für die oft umfangreichen Datenbestände von Data Warehouse-Systemen. Zusätzlich werden Daten in der Datenhaltungskomponente auch multidimensional aufbereitet. Eine wesentliche Anforderung von Analysen des Managements ist, dass relevante Kennzahlen (z.B. Personalbestand) nach mehreren Dimensionen gleichzeitig analysiert werden können (z.B. nach Projekt, nach Zeiteinheit und nach Standort).

77

234 123 322 111

89

98

345 134 114 Dimension2 (z.B. Projekt)

(z Dim .B e . S ns ta ion nd 3 or t)

Dimension1 (z.B. Zeit)

Multidimensionalität

Abb. 5.5: Multidimensionaler Datenwürfel

76

Kennzahl (z.B. Personalbestand)

5.1

Architektur und Funktionalität von Data Warehouse-Systemen

Zu diesem Zweck werden die Daten aus den Quellsystemen im Sinne des multidimensionalen Datenbankmodells (vgl. Kap. 4) auch in mehrdimensionalen Datenwürfeln organisiert, deren Kanten die jeweiligen Dimensionen darstellen, während die interessierenden Kennzahlen in den einzelnen Zellen des Würfels gehalten werden (vgl. Abb. 5.5). So wird es möglich, eine Kennzahl nach mehreren Dimensionen gleichzeitig auszuwerten. Dabei sind auch erheblich mehr als drei Analysedimensionen denkbar. Der Datenwürfel wird dann zum so genannten Hyperwürfel (»Hypercube«) (vgl. Pedersen & Jensen 2001, 44f.). Multidimensional aufbereitete Daten sind entsprechend eine wesentliche Voraussetzung für multidimensionale Analysen (»Slicing & Dicing«) im Rahmen von OLAP-Systemen (vgl. Kap. 11). Datenbankmodelle

Die Datenbasis eines Data Warehouse-Systems kann mittels unterschiedlicher Datenbankmodelle realisiert werden. Üblich sind relationale und/oder multidimensionale Datenbankkomponenten sowie Mischformen. Werden Data Warehouse-Systeme ausschließlich mit relationalen Datenbankkomponenten realisiert, sind zur multidimensionalen Aufbereitung der Daten spezifische Modellierungsschemata, wie z.B. das »Star-Schema«, anzuwenden. Neben in das Data Warehouse integrierten Datenhaltungskomponenten kann die Datenhaltung teilweise auch auf externe Datenbanksysteme ausgelagert werden (vgl. Kap. 4).

5.1.4

Metadatenbank

Arten

Meta-Daten werden häufig als »Daten über Daten« veranschaulicht (vgl. Holthuis 1999, 95). Grundsätzlich bilden solche »Daten über Daten« auch den Kern einer Metadatenbank, der generell in betriebswirtschaftlich-semantische und technisch-syntaktische Metadaten aufgeteilt werden kann. Semantische Metadaten dienen der inhaltlichen Beschreibung von Daten. Syntaktische Metadaten gehen darüber hinaus auch auf konzeptuelle und logische Datenbankschemata, physische Speicherinformationen ein. Im weiteren Sinne zählen auch Herkunft der Daten (speziell Quellsysteme), durchlaufene Prozesse (Extraktions-, Transformations- und Ladevorgänge), Zugriffsrechte auf Daten, Zugriffshäufigkeit und Ziele der Daten (z.B. in Analysesystemen abgespeicherte Queries) zu den Metadaten. Neben der Semantik und Syntaktik der Daten bilden Metadatenbanken daher auch sämtliche Datenflüsse und -transformationen von den Quellsystemdaten bis zu den Analysesystemen ab (vgl. Vaduva & Vavouras 2004, 68f.).

77

5

Data Warehouse-Systeme

Verwendung

Die Daten der Metadatenbank dienen dabei grundsätzlich der Administration von Data Warehouse-Systemen und der Anwendung nachgelagerter Analysesysteme der Business Intelligence. Anwender erhalten so über einen Überblick über die Inhalte des Data Warehouse-Systems wie Datenwürfel, ODS-Objekte etc. sowie deren Eigenschaften. Oft gewinnen Daten für den Anwender erst in Verbindung mit ihren Metadaten Bedeutung. Beispielsweise ist es personalwirtschaftlich durchaus relevant zu wissen, wann die Daten eines Mitarbeiters in der Datenbasis das letzte Mal aktualisiert wurden, damit vorgenommene Auswertungen nicht auf veralteten Daten basieren. Ebenso werden Administratoren über die Metadatenbankkomponente alle notwendigen Informationen bereitgestellt, die sie zur Verwaltung des Data Warehouse-Systems benötigen.

Austausch

Derzeit mangelt es an einem generell akzeptierten standardisierten Metadatenformat. Als ein produktübergreifendes Modell, das den Metadatenaustausch zwischen den einzelnen Komponenten eines Data Warehouse-Systems vereinfacht, hat sich das so genannte Common Warehouse Metamodel etabliert (www.omg. org/cwm). Dieser Standard erlaubt die einfache Integration verschiedener Softwareprodukte und wird mittlerweile von den bedeutenden Herstellern von Data Warehouse-Systemen unterstützt.

5.1.5

Administrationskomponente Die Administrationskomponente dient der generellen Verwaltung des Data Warehouse-Systems. Generell ermöglicht die Administrationskomponente die technische Administration, das »ETL-Scheduling«, die Anwenderverwaltung sowie ein Monitoring. Die technische Administration zielt auf die Gewährleistung der Datenintegrität (Widerspruchsfreiheit, Vollständigkeit, Aktualität), der Datensicherheit (Zugriffsteuerung), die Verfügbarkeit des Systems (beispielsweise die Maximierung der Betriebszeit), die Performanz des Systems (z.B. die Sicherstellung möglichst maximaler Leistung des Systems) sowie die Wiederherstellbarkeit der Daten bei Verlust durch Sicherungskopien (»Backups«). Das ETLScheduling zielt auf die Steuerung der zyklischen Aktualisierungsvorgänge des Data Warehouse-Systems. Dabei werden beispielsweise verschiedene Aktualisierungszyklen aus den Quelldatensystemen festgelegt und korrespondierende ETL-Vorgänge angestoßen und überwacht. Die Anwenderverwaltung umfasst zentral die Festlegung und Verwaltung von Zugriffsrechten einzelner Anwender und Anwendergruppen. Monitoring beinhaltet die

78

5.2

Anwendung von Data Warehouse-Systemen

systemgestützte Überwachung der Verwendung des Data Warehouse-Systems. Dadurch sollen Erkenntnisse zu Daten und Anwendern gewonnen werden. Erkenntnisse zu Daten sind beispielsweise Informationen zu Bereichen und Umfang des Datenwachstums sowie eine Identifikation der faktisch benutzten Daten. Anwenderbezogene Erkenntnisse betreffen beispielsweise die Identifikation der faktischen Anwender sowie die Feststellung von Anwendungsdauern und -zeiträumen (vgl. Kemper et al. 2004, 51f.).

5.2

Anwendung von Data Warehouse-Systemen Im Personalmanagement werden Data Warehouse-Systeme (HR Data Warehouses, HR Data Marts) eingesetzt, um Entscheidungsträger mit entscheidungsrelevanten Daten bei der Planung, Steuerung und Kontrolle des personalwirtschaftlichen Geschehens zu unterstützen. Die Daten des Data Warehouses werden damit erkennbar redundant zu den weiteren datenhaltenden Komponenten und Systemen der Datenhaltungsschicht einer Makroarchitektur gehalten. Eine erste Begründung für die Notwendigkeit dieser Redundanz liegt in der Möglichkeit der integrierten Auswertung von Daten aus unterschiedlichen Systemen. Werden beispielsweise Arbeitszeitmanagement und Personalabrechnung von getrennten Systemen unterstützt, ermöglicht erst ein Data Warehouse-System die integrierte Auswertung von Abrechnungs- und Zeitdaten der Mitarbeiter. Weiter sind die einzelnen operativen personalwirtschaftlichen Anwendungen auf die zeitnahe Verarbeitung mengen- und wertorientierter Daten ausgerichtet und daher nicht auf spezielle und rechenintensive Abfragen von Analysesystemen vorbereitet. Deshalb würde ein unmittelbares Aufsetzen von Analysesystemen auf die operativen Systeme zu einer hohen Ressourcenbelastung und Performance-Problemen führen. Weiter wären solche Analysen letztlich an die Leistungsfähigkeit von Abfragewerkzeugen relationaler Datenbankkomponenten gebunden (vgl. Kap. 4). Die angesprochenen Möglichkeiten multidimensionaler und (dis-)aggregierender Analysen (vgl. auch Kap. 11) ergeben sich erst mit der entsprechenden Aufbereitung der Daten im Data Warehouse. Schließlich bildet die (i.d.R.) mangelnde Historisierung von Daten in den Administrations- und Dispositionssystemen einen weiteren Grund für die Anwendung von Data Warehouse-Systemen im Personalmanagement (vgl. Inmon 2005, 1ff.).

Datenhaltungssystem

Data Warehouse-Systeme können dann im Rahmen einer Makroarchitektur zunächst als schichtspezifische Datenhaltungssysteme 79

5

Data Warehouse-Systeme eingesetzt werden. Sie dienen dann als zentrale Informationsquelle für alle Entscheidungsträger und sollen heterogene Informationsstände verhindern (»Single Point of Truth«). Zur Nutzung von Data Warehouse-Daten werden neben einfachen ReportingSystemen unter dem Oberbegriff der Business Intelligence-Systeme insbesondere ƒ Online Analytical Processing-Systeme (vgl. Kap. 11) und ƒ Data Mining-Systeme (vgl. Kap. 12) vorgeschlagen, die neuere entscheidungsunterstützende Analysemethoden zur Analyse der Data Warehouse-Daten anbieten. Schließlich wird neuerdings auch die Kombination mit ƒ Personalplanungssystemen (vgl. Kap. 7, 8, 9 und 10). diskutiert. Planende Systeme sollen dabei direkt auf den Datenstrukturen des Data Warehouse-Systems aufsetzen und erzeugte Plandaten dann direkt wieder im Data Warehouse ablegen. Der Vorteil ist die Möglichkeit, die Plan-Daten nach sukzessiven Uploads im Zeitablauf direkt mit den Ist-Daten abgleichen zu können. Im Unterschied zu rein analytischen Systemen generieren solche Planungsanwendungen neue Daten, die im Data Warehouse abzulegen sind. Entsprechend existiert neben einem lesenden auch ein schreibender Zugriff.

Anwendungssystem

Häufig bieten Data Warehouse-Systeme aber auch integrierte Auswertungs-Werkzeuge an, erneut insbesondere im Bereich Online Analytical Processing und Data Mining. In diesem Fall sind Business Intelligence-Analysen bereits in das Data Warehouse integriert, das dann als schichtübergreifendes Anwendungssystem eingesetzt werden kann. Nicht zuletzt die Möglichkeit, die Haltung und die Analyse entscheidungsrelevanter Daten auf ein oder mehrere Systemen aufzuteilen, hat zu unterschiedlichen Begriffsauffassungen von »Data Warehouse« und »Business Intelligence« geführt. Zum einen werden die Analysesysteme der Business Intelligence dem Data Warehouse zugerechnet oder aber umgekehrt Business Intelligence als Überbegriff für datenhaltende und -auswertende Systeme verwendet (vgl. z.B. Kemper et al. 2004, 4).

Verbreitung

Aktuelle Studien zur Verbreitung von Data Warehouse-Systemen im Personalmanagement fehlen. Eine ältere Studie zeigt, dass Ende der 1990er Jahre bereits 22% der befragten Unternehmen ein Data Warehouse im Personalmanagement verwenden (vgl. Data Mart 1999, 24). Die Verwendung dürfte inzwischen jedoch weiter fortgeschritten sein, und die Data Warehouse-Technologie ist auf dem Weg zur »Standardanwendung« der personalwirtschaftlichen Informationsversorgung.

80

6

Dokumentenmanagementsysteme Dokumentenmanagementsysteme (DMS, elektronisches Dokumentenmanagementsystem [EDMS]) sind Anwendungen zur Erstellung (Digitalisierung), Indizierung, Archivierung, Auffindung, Weiterleitung und Vernichten jeglicher Art von personalwirtschaftlichen (und sonstigen) Dokumenten (vgl. Berndt & Leger 1994, 1).

6.1

Architektur und Funktionalität von Dokumentenmanagementsystemen Dokumentenmanagementsysteme bestehen neben der obligatorischen Anwenderschnittstelle üblicherweise aus einer Administrationskomponente, einer Eingabe- und Ausgabekomponente, einer Ablagedatenbank und einer Metadatenbank (vgl. Abb. 6.1). Dokumentenmanagementsystem Digitaldokumente (CI)

Anwenderschnittstelle Administrationskomponente

Digitaldokumente (NCI)

Eingabekomponente

Ablage

Ausgabekomponente

Viewer / Anwendungssysteme

Metadaten Analogdokumente

Abb. 6.1: Idealtypische Architektur von Dokumentenmanagementsystemen Papierbasierte oder bereits in digitalisierter Form vorliegende Dokumente aus anderen personalwirtschaftlichen Anwendungssystemen werden über die Eingabekomponente erfasst und indexiert. Anschließend werden die Dokumente in der Ablagedatenbank gespeichert. Basierend auf der Dokumentenablage ermög81

6

Dokumentenmanagementsysteme licht die Ausgabekomponente die detaillierte Recherche nach Dokumenten sowie die Präsentation der als relevant identifizierten Dokumente. Mit der Benutzung dieser drei Komponenten werden Daten über die Dokumente erstellt, modifiziert oder abgefragt und als Metadaten in einer eigenen Metadatenbank gespeichert. Die Administrationskomponente dient der Verwaltung von Daten, Metadaten und Anwendern sowie dem systematischen Ablauf von Eingabe, Ablage und Zugriffen.

ODMA

Für den Import und Export von Dokumenten hat sich dabei die standardisierte »Open Document Management Alliance«-Schnittstelle (ODMA) etabliert (http://odma.info). Die Verwendung dieses Standards ermöglicht sowohl den Import bereits digitalisierter Dokumente wie deren Export an externe Viewer und personalwirtschaftliche Anwendungssysteme.

6.1.1

Eingabekomponente In der Eingabekomponente werden die verschiedenen relevanten Dokumentenarten erfasst ggf. digitalisiert und transformiert, indexiert und einheitlich für die weitere Verarbeitung im Dokumentenmanagementsystem zur Verfügung gestellt (vgl. Abb. 6.2). Digitaldokument (CI)

Indexierung

Digitaldokument (NCI)

XOR

OCR

Digitaldokument (CI)

Analogdokument

Scanning/ Digitizing

Digitaldokument (NCI)

XOR

Abb. 6.2: Prozess der Eingabe Dokumentenarten Mögliche in ein Dokumentenmanagementsystem aufnehmbare, externe Dokumente können zunächst in analoger (nicht-digitalisierter) oder bereits digitalisierter Form vorliegen. Als nicht-digitalisierte Dokumente gelten dabei zunächst alle Formen von Papierdokumenten, die von einem Arbeitszeugnis eines Bewerbers bis zu einem in Papierform vorliegenden Lichtbild eines Mitarbeiters reichen können. Des Weiteren zählen auch ana82

6.1

Architektur und Funktionalität von Dokumentenmanagementsystemen loge Audio- und Videodokumente zu den nicht-digitalen externen Dokumenten. Solche Dokumente, etwa analoge Bewerbervideos, dürften im Personalmanagement im Vergleich zu Papierdokumenten allerdings deutlich seltener anfallen. Digitalisierte Dokumente werden weiter in die Kategorien CI (»Coded Information«) und NCI (»Non-Coded Information«) aufgespalten. NCI-Dokumente können erneut visueller, auditiver oder audiovisueller Art sein. Inhalte solcher Dokumente können von einem menschlichen Anwender bei der Wiedergabe erkannt werden. Eine Erkennung und Weiterverarbeitung durch den Rechner ist dagegen nicht möglich. Beispielsweise bestehen visuelle NCI-Dokumente wie bspw. eingescannte Abschlusszeugnisse von Bewerbern aus einzelnen Bildpunkten. Hier ist einem Anwender möglich, diesen Dokumenten die jeweilige Abschlussnote zu entnehmen, während dies für einen Rechner (zunächst und ohne weitere Vorverarbeitung) nicht möglich ist. Analoges gilt für auditive (Klangdateien) und audio-visuelle Dokumente (Videodateien, Animationen). CI-Dokumente bestehen dagegen aus maschinenlesbaren Daten. Solche in Zeichen (Buchstaben, Zahlen und Sonderzeichen) codierte Information können elektronisch weiterverarbeitet werden. Beispielsweise können vorliegende Daten über Personaleinzelkosten maschinell zu Gesamtkosten aufaddiert werden. Die Differenzierung zwischen CIund NCI-Dokumenten ist insofern bedeutsam, als NCI-Dokumente wesentlich höhere Anforderungen an die Leistungsfähigkeit und Kapazität des Dokumentenmanagementsystems stellen und nicht alle Auswertungsfunktionalitäten anwendbar sind.

Erfassungsarten

Je nach Dokumentenart erfolgt die Erfassung durch ƒ Digitalisierung analoger Dokumente, ƒ Import von bereits digitalisierten Dokumenten aus externen Anwendungssystemen und/oder ƒ manuellen Eingaben von Anwendern. Liegen zu archivierende Dokumente in analoger Form vor, müssen diese vor einer Archivierung zwingend einer Digitalisierung unterzogen werden. Die Vorgehensweise zur Digitalisierung hängt dabei von der Art des zu digitalisierenden Dokuments ab. Der personalwirtschaftlich weitaus häufigste Fall besteht in der Digitalisierung von Papierdokumenten, wie etwa einem handschriftlichen Lebenslauf eines Bewerbers über einen Scanner (»Abtaster«). Scanner sind Eingabegeräte, die über lichtempfindliche Sensoren vom Papierdokument reflektierte Lichtstrahlen in entsprechende elektronische (digitale) Strukturen überführen. Als 83

6

Dokumentenmanagementsysteme Ergebnis eines Scanns entsteht ein Raster aus einzelnen Bildpunkten (»Pixel«). Je nach Auflösung eines Scanners entstehen so unterschiedlich scharfe, digitale Abbilder des entsprechenden Originals (vgl. Limper 2001, 72). Neben Textdokumenten wie etwa ein handschriftlicher Lebenslauf, können auch Bilddokumente, etwa das Lichtbild eines Mitarbeiters, eingescannt werden. Vergleichbar müssen auch analoge Audio- und Videodokumente vor einer Archivierung im Dokumentenmanagementsystem mittels entsprechender Geräte digitalisiert werden. Bei der Video-Digitalisierung (»Video Digitizing«) werden analoge Videosignale über Videokarten von Rechnern in digitale Dokumente umgesetzt. Wegen der dabei entstehenden Datenmengen werden solche Dateien vor der Archivierung oft vorkomprimiert. Videokarten sind oft auch in der Lage, reine Audiodokumente zu digitalisieren (»Audio Digitizing«). Ansonsten sind entsprechende Hardwarekomponenten zur Umwandlung analoger in digitaler Audiodateien notwendig. In vielen Fällen existieren die Dokumente allerdings bereits in digitaler Form in einer externen Applikation. Diese stehen dann für einen unmittelbaren Import bereit. Ein Beispiel hierfür bildet etwa ein bereits in digitaler Form erstelltes Mitarbeiterlichtbild, das direkt in das Dokumentenmanagementsystem eingelesen werden kann. Wie erwähnt können im Rahmen verteilter Systeme neben dem DMS selbst teils auch externe Anwendungen wie Office-Systeme oder Browsersysteme (vgl. Kap. 28) als Erfassungssysteme verwendet werden, insbesondere wenn mit dem ODMA-Standard gearbeitet wird. Schließlich sind auch manuelle Eingaben in ein DMS möglich. Dazu werden dem Anwender vom DMS elektronische Formulare mit verschiedenen Gestaltungselementen zur Verfügung gestellt, die vom Anwender auszuwählen und auszufüllen sind (vgl. Götzer 2001, 17).

OCR

84

Entsprechend digitalisierte Dokumente liegen dann in Form von NCI-Dokumenten vor. Audio- und Videodateien stehen dann direkt zur Indexierung bereit. Reicht die CI-Variante von Textdokumenten für eine konkrete Anwendungssituation aus, können auch diese Dokumente direkt indexiert und abgelegt werden. Ist dagegen eine maschinelle Weiterverarbeitung der Dokumenteninhalte erwünscht, etwa der automatisierte Abgleich der Schulnoten von Bewerbern, sind die eingescannten Dokumente einer optischen Zeichenerkennung (»Optical Character Recognition [OCR]«) zu unterziehen. Die Aufgabe des OCR besteht in der Er-

6.1

Architektur und Funktionalität von Dokumentenmanagementsystemen kennung von entsprechenden Schriftzeichen. Dabei werden HellDunkel-Kontraste verwendet, um einzelne Zeichen zunächst zu identifizieren. Über den Vergleich mit einer Vorlage eines kompletten Zeichensatzes bestimmt das OCR-System das Zeichen mit der geringsten Abweichung und legt es in einer Ausgabedatei ab. Nach Abschluss des OCR-Prozesses steht eine maschinenlesbare CI-Variante des Dokumentes zur Verfügung (vgl. Berndt & Leger 1994, 137). Allerdings weist die Zeichenerkennung über OCR je nach Qualität der Vorlage nach wie vor eine gewisse Fehlerrate auf.

Indexierung

Zur eindeutigen Kennzeichnung von Dokumenten sowie deren Inhalten werden alle Dokumente einer Indexierung unterzogen. Dazu wird ein Dokument zunächst mit einem eindeutigen Identifizierungskriterium versehen, das oft auf der Basis der Personaloder Sozialversicherungsnummer des betreffenden Mitarbeiters erstellt wird. Der Inhalt eines Dokumentes wird dann anhand von Schlagwortkatalogen festgehalten. Die bei der Indexierung vergebenen Schlagworte werden als Verknüpfung zum jeweiligen Dokument in einer Metadatenbank gespeichert. In der Folge können Dokumente eines spezifischen Typs (z.B. alle Schulabschlusszeugnisse von Bewerbern oder alle Dokumente eines spezifischen Mitarbeiters) unproblematisch identifiziert werden. Speziell bei Vorliegen von CI-Dokumenten kann dann zur Suche nach Dokumenten auf die deutlich kleinere Indexdatei zugegriffen werden, was eine deutlich effizientere Suche ermöglicht. Neben manuellen Indexierungen können Dokumente teilweise auch automatisiert, etwa als Prozessschritt im Rahmen des Scanoder OCR-Vorgangs, indexiert werden. Entsprechende Daten wie Dokumententyp oder -zugehörigkeit werden dann automatisiert vergeben und in die Metadatenbank ausgelesen.

Digitale Signatur

Teilweise erhalten Dokumente hier auch eine digitale Signatur (»Digital Signature«). Digitale Signaturen stellen verschlüsselte, fälschungssichere Kennzeichen digitaler Dokumente dar, mittels derer die Herkunft und die Authentizität des Dokumentes belegt werden kann.

6.1.2

Ablagekomponente Die Ablage stellt die Kernkomponente eines Dokumentenmanagementsystems dar, die mittels der Ablagekomponente realisiert wird. Das zentrale Ziel der Ablagekomponente besteht in der Sicherung der Verfügbarkeit, der Performance und des Daten-

85

6

Dokumentenmanagementsysteme schutzes, der Verhinderung von fahrlässiger und vorsätzlicher Manipulation sowie des Verlusts der Dokumente.

Speicherung

Die Speicherung von Dokumenten erfolgt überwiegend mit optischen Speichermedien der so genannten WORM (»Write Once Read Many«)-Kategorie. Dazu zählen beispielsweise die CD-ROM (»Compact Disc Read Only Memory«) oder DVD (»Digital Versatile Disc«). Zur Realisierung werden so genannte »Jukeboxen« verwendet. Jukeboxen sind Laufwerke für wechselbare Speichermedien. Einzelne Speichermedien wie etwa CD-ROMs oder Datenbänder können dabei über Robotermechanismen automatisiert in das Laufwerk eingelegt bzw. daraus entfernt werden. So können große, physisch auf zahlreichen CD-ROMs und/oder anderen Speichermedien gespeicherte Datenmengen zugänglich gemacht werden. Auch Mikrofilme kommen (immer noch) zum Einsatz, wenn es um die kostengünstige Langzeitarchivierung mit einer Garantie von 100 Jahren geht. Im Gegensatz hierzu wird die Speicherungsgarantie einer CD-ROM mit »lediglich« 30 Jahren angegeben (vgl. Götzer 2001, 204f.).

Ablagestruktur

Für den navigierenden Zugriff auf Dokumente wird eine multihierarchische Struktur angeboten, in der Dokumente unterschiedlichen Typs und Herkunft metaphorisch in »Schränken«, »Schubladen«, »Ordnern« oder »Mappen« abgelegt und wieder aufgerufen werden können. Die einzelnen Kategorien stehen dabei in einem logischen Zusammenhang. Ein Dokument kann auch mehreren übergeordneten Kategorien zugeordnet werden. Softwaretechnisch wird dabei trotz einer möglichen mehrfachen Zuordnung eines Dokuments keine redundante Speicherung vorgenommen.

6.1.3

Ausgabekomponente Die Ausgabekomponente ist für die Auffindung relevanter Dokumente und deren Anzeige verantwortlich. Dabei können nicht nur Anwender des Dokumentenmanagementsystems, sondern auch Anwender angebundener externer Anwendungssysteme auf die abgelegten Dokumente zugreifen.

Suchfunktionen

86

Den Zugriff auf abgelegte Dokumente ermöglichen Suchfunktionen mit integrierten Suchoptionen: Dies beinhaltet Eingabemöglichkeiten von Begriffen zur Suchtreffereinschränkung. Konkretisierungen von Suchanfragen können über die Verwendung von Operatoren vorgenommen werden. Ergänzend gibt es Suchoptionen hinsichtlich bestimmter Dokumententypen (z.B. Bewerbungen oder Arbeitsverträge) oder Werte in bestimmten inhaltsbeschreibenden Metadaten-Elementen (z.B. »Autoren«, eindeutige

6.1

Architektur und Funktionalität von Dokumentenmanagementsystemen Referenznummer für den Direktzugriff auf bestimmte Dokumente). Die Suchtrefferanzeige erfolgt nach dem Abschicken der Suchanfrage i.d.R. durch die Auflistung der gefundenen einschlägigen Dokumente. Viele Systeme ermöglichen dabei auch die Speicherung der Suchanfrage und der Suchtreffer für einen erneuten komfortablen Zugriff (vgl. Götzer 2001, 24f.).

Viewer

Für die Anzeige stellen Dokumentenmanagementsysteme eigene Dokumentenviewer zur Verfügung oder rufen hinsichtlich bestimmter Dokumentenformate externe Viewer auf. Viewer sind dabei Programme, die Dateien fremder Anwendungen auf dem Bildschirm anzeigen (teils auch eingeschränkt bearbeiten) können. Immer häufiger werden aufgrund der Plattformabhängigkeit und der standardisierten Übertragungsmöglichkeit auch Browsersysteme mit entsprechenden Plug Ins (vgl. Kap. 28) als Viewer für Dokumentenmanagementsysteme genutzt.

6.1.4

Administrationskomponente Die Administrationskomponente dient der Implementierung und speziell der Verwaltung von DMS.

Implementierung

Zunächst bietet die Administrationskomponente grundsätzliche Werkzeuge zur Anpassung von DMS an organisationsspezifische Anforderungen (»Customizing«). Beispielsweise können elektronische Eingabeformulare für eine manuelle Eingabe von Daten gestaltet werden oder unter Verwendung verschiedener API’s (»Application Programming Interface«) externe Anwendungssysteme angebunden werden. Hierzu zählt auch die Parametrisierung möglicher DMS-Clients, was beispielsweise die Aktivierung des Scannerzugangs oder des OCR-Programms (vgl. Gulbins et al. 2002, 124f.).

Anwenderverwaltung

Weiter wird als Kernaufgabe die Verwaltung von Anwendern des DMS übernommen. Die Anwenderverwaltung zielt auf die Sicherstellung der korrekten Authentifizierung von Anwendern sowie die Festlegung der Zugriffsberechtigungen hinsichtlich der differenzierten Steuerung von lesenden und schreibenden Zugriffen auf Dokumente und Metadaten.

Vorgangssteuerung

Weitere Funktionen eines DMS ergeben sich aus den Anforderungen, die durch die arbeitsteilige Bearbeitung (d.h. der Eingabe, Ablage und des Zugriffs auf Dokumente) durch Gruppen von Anwendern entstehen (vgl. Schütz 2004, 345). Im Rahmen der Eingabe und Ablage von Dokumenten übernimmt diese Komponente die Vergabe eines Bearbeitungsstatus jedes Dokuments wie bspw. »In Bearbeitung«, »Warten Auf« oder »Bearbeitet«. Eben87

6

Dokumentenmanagementsysteme so wird zur Aufrechterhaltung der Dokumentenintegrität verhindert, dass zwei Anwender gleichzeitig schreibenden Zugriff auf ein Dokument erhalten können. Im Rahmen des Zugriffs auf Dokumente wird sichergestellt, dass Bearbeitern stets diejenigen Dokumente zur Verfügung stehen, die sie im Rahmen der Bearbeitung eines personalwirtschaftlichen Prozesses aktuell benötigen. Im Unterschied zum schreibenden Zugriff können hier beliebig viele Bearbeiter simultanen lesenden Zugriff auf dasselbe Dokument erhalten. Dies stellt einen Vorteil gegenüber Papierdokumenten dar, die nur nacheinander einsehbar sind oder aufwändig fotokopiert werden müssen. Müssen im Zeitablauf mehrere Versionen eines Dokuments abgelegt werden (z.B. Jahresverdienstbescheinigungen) existiert in Teilen der Systeme ein Versionsmanagement, das einen Zugriff auch auf ältere Versionen des Dokuments zulässt.

6.1.5

Metadatenbank Metadaten werden allgemein als »Daten über Daten« beschrieben. Als Hauptarten lassen sich generell semantische, administrative und technische Metadaten unterscheiden. Für den Anwender sind insbesondere die semantischen Metadaten bedeutsam, da diese als inhaltserschließende Attribute den suchenden und navigierenden Zugriff auf abgelegte Dokumente sicherstellen. Zu den semantischen Metadaten zählen klassischerweise die im Rahmen des Indexierungsvorgangs vergebenen Schlagworte. Die Notwendigkeit solcher Metadaten lässt sich beispielsweise anhand von digitalen Bilddokumenten, die nach der Erfassung als NCI-Variante vorliegen, erläutern: Ein eingescanntes Mitarbeiterfoto kann bspw. ohne Metadatenvergabe vom Anwender nicht oder nur mit hohem Aufwand einem konkreten Mitarbeiter zugeordnet werden. Entsprechend stellen semantische Metadaten die sinnvolle Verwendbarkeit und Interpretierbarkeit von Dokumenten sicher. Über inhaltserschließende Attribute hinaus gelten auch strukturelle Metadaten als semantische Metadaten. Diese beschreiben den inneren Aufbau eines Dokumentes, die so genannte Mikrostruktur, durch Attribute wie Titel, Betreff, Kapitel oder Abschnitt. Administrative Metadaten dienen der Verwaltung des Dokuments. Als Beispiele können Zugriffsrechte, Bearbeitungsstatus, Copyrights oder Archivierungsfristen einzelner Dokumente genannt werden. Technische Metadaten dienen der technischen Administration des Dokumentenmanagementsystems. Solche Daten beinhalten etwa Informationen zur

88

6.2

Anwendung von Dokumentenmanagementsystemen

Formatierung, zum Dateiformat oder zum eingesetzten Kompressionsverfahren.

6.2

Anwendung von Dokumentenmanagementsystemen Generell werden Dokumentenmanagementsysteme zur Optimierung von dokumentenbasierten Geschäftsprozessen aller betrieblichen Funktionsbereiche eingesetzt. Dies impliziert eine Beschleunigung der Prozessbearbeitung durch kürzere Ablage-, Transport-, Such- und Zugriffszeiten von Dokumenten. Ebenso sollen Kosten gespart werden, speziell Druck- und Kopierkosten der Papierdokumente, von Raum- und Bürokosten, die eine konventionelle Ablage verursacht, sowie von Personalkosten. Weiter soll durch einen dezentralen, simultanen Zugriff auf Dokumente eine integrierte und ganzheitliche Dokumentenbearbeitung, eine höhere Dokumentenkonsistenz sowie eine höhere Datensicherheit erreicht werden (vgl. Schütz 2004, 342).

Digitale Personal- Diese Ziele werden grundsätzlich auch mit einer personalwirtschaftlichen Anwendung von Dokumentenmanagementsystemen akte verbunden.

Personaldokumente

Bewerbungsdokumente

Arbeitsvertragsdokumente

…

Bewerbungsschreiben

Arbeitsvertrag

...

Arbeitszeugnisse

Aushänd.Bestät.

Lebenslauf

...

Dokumentenkategorie

Dokumententyp

Sprachzeugnisse Bewerbungsbogen ...

Abb. 6.3: Multihierarchische Dokumentenstruktur einer digitalen Personalakte Das zentrale Anwendungsszenario im Personalmanagement stellt die digitale Personalakte (elektronische Personalakte, e-Personalakte, elektronisches Personalarchiv) dar (vgl. Mülder 2000, 104f.). 89

6

Dokumentenmanagementsysteme Digitale Personalakten sind elektronische Varianten der konventionellen Papierpersonalakte. Alle konventionell in Papierform gehaltenen Dokumente vom Arbeitsvertrag über zahlreiche Bescheinigungen bis hin zu Schulzeugnissen können Eingang in eine digitale Personalakte finden und dort in einer unternehmensindividuellen multihierarchischen Struktur abgelegt werden (vgl. Abb. 6.3). Digitale Personalakten können dabei einen erheblichen Umfang annehmen. Als empirischer Mittelwert werden 300 Dokumente genannt. Die Eingangsakte bestehend aus Bewerbungs- und Arbeitsvertragsunterlagen umfasst dabei im Mittel bereits 50 Dokumente. Pro Jahr kommen im Schnitt 20 Dokumente je Akte hinzu (vgl. Nextevolution Consulting Group 2005, 9). In Entsprechung zu einer digitalen Personalakte können auch digitale Bewerberakten geführt werden, die entsprechende digitale Bewerberdokumente vom Zeugnis bis zum handschriftlichen Lebenslauf umfassen können. Über die Bewerbung hinaus benötigte digitale Bewerberdokumente können bei Einstellung dann in die digitale Personalakte übernommen werden. Einmal digitalisierte Akten weisen verschiedene Vorteile auf: So wird eine Verbesserung von Vollständigkeit und Aktualität der Akten berichtet. Anwender finden sich in der standardisierten Dokumentenstruktur besser zu Recht. Das Auffinden von Dokumenten wird erheblich beschleunigt. ebenso sind beliebig viele Parallelzugriffe möglich. Als Folge können spürbare Kosteneinsparungen realisiert werden (vgl. Nextevolution Consulting Group 2005). Neben einem Zugriff durch die Personalabteilung kann auch das Recht von Mitarbeitern auf Einsicht in die eigene Personalakte (§ 83 BetrVG) auf der Basis von Dokumentenmanagementsystemen realisiert werden (vgl. Geis et al. 2003, 40). Wird ein webbasiertes System gewählt, können Mitarbeiter ihre diesbezüglichen Rechte jederzeit über die Browsersysteme (vgl. Kap. 28) ihrer Arbeitsplatz- und/oder Privatrechner wahrnehmen. Aus rechtlicher Sicht ergeben sich möglicherweise Probleme mit der so genannten »Beweisqualität« digitaler Dokumente. Soweit der Gesetzgeber für die entsprechenden Originale die Schriftform vorsieht (also beispielsweise für Arbeitsverträge, Befristungsabreden, Kündigungsschreiben, Aufhebungsverträge oder Arbeitszeugnisse) genügen trotz anders lautender Rechtsauffassungen (vgl. z.B. Geis et al. 2003, 42f.) digital archivierte Dokumente den Arbeitsgerichten in praxi oft nicht. Entsprechend sollten nur Originale, für die der Gesetzgeber nicht ausdrücklich auf der Schriftform besteht, nach der Digitalisierung endgültig vernichtet werden. Aus Sicht der Rationalisierungsziele von Dokumenten-

90

6.2

Anwendung von Dokumentenmanagementsystemen

managementsystemen ist dies insofern unbefriedigend, als dass zusätzlich zur digitalen Archivierung auch immer noch eine redundante »Rumpfakte« in Papierform vorzuhalten ist. Anwendungsvarianten

Zur Realisierung digitaler Personal- und Bewerberakten können Dokumentenmanagementsysteme zunächst als schichtspezifische Datenhaltungssysteme eingesetzt werden. Der Endanwender greift dann entweder über externe Viewer oder aber direkt aus personalwirtschaftlichen Anwendungssystemen auf die digitalisierten Dokumente zu. Beim Zugriff über personalwirtschaftliche Anwendungssysteme können Dokumente im Rahmen von Workflows auch an personalwirtschaftliche Prozesse gekoppelt werden. Solche Anwendungen verfügen entsprechend über eigene Ausgabefunktionalitäten, die die Dokumente wiedergeben können. Dem Anwender bleibt dabei die zusätzliche Involvierung eines Dokumentenmanagementsystems i.d.R. verborgen. Teils kann auch die Eingabe und Ablage über das Anwendungssystem realisiert werden. Diese Integration des Dokumentenmanagement in personalwirtschaftliche Anwendungen hat den Vorteil, dass Bearbeiter stets über einen unmittelbaren Zugriff auf die jeweils aufgabennotwendigen Aktenbestandteile verfügen. Zur Realisierung von digitalen Akten können Dokumentenmanagementsysteme aber auch als schichtübergreifendes Anwendungssystem eingesetzt werden. Anwender greifen dann im Rahmen ihrer Tätigkeit direkt auf die Komponenten des Dokumentenmanagementsystems zu, um Dokumente zunächst einzugeben und abzulegen und später darauf zuzugreifen.

Verbreitung

Eine Praxisstudie zur Verbreitung von digitalen Personalakten zeigt, dass 31% der befragten Unternehmen digitale Personalakten einsetzen, während 51% einen Einsatz planen. In der überwiegenden Mehrheit der Fälle (92%) werden solche digitalen Personalakten auf der Basis von Dokumentenmanagementsystemen realisiert. Zur Art der Anwendung – ob als Datenhaltungsoder Anwendungssystem – existiert derzeit allerdings kein Aufschluss (vgl. Nextevolution Consulting Group 2005).

91

Teil C Anwendungssysteme

7

Personalbedarfsplanungssysteme Personalbedarfsplanungssysteme (Personalbedarfsermittlungssystem, Personalbemessungssystem, Personalkapazitätsplanungssystem, »[HR] Capacity Planning-System«) sind Anwendungen zur Bestimmung zukünftiger qualitativer, quantitativer, zeitlicher und örtlicher Personalbedarfe.

7.1

Architektur und Funktionalität von Personalbedarfsplanungssystemen Systeme zur Personalbedarfsplanung weisen i.d.R. einen ausgeprägten Branchenbezug auf und fallen insofern durchaus heterogen aus. Idealtypisch umfassen Systeme zur Personalbedarfsplanung jedoch Dateien mit bedarfsrelevanten Ereignissen sowie Bedarfsplänen, eine Planungskomponente, eine Analysekomponente sowie die obligatorische Anwenderschnittstelle (vgl. Abb. 7.1). Personalbedarfsplanungssystem Anwenderschnittstelle Planungskomponente Ereignisplanung Vorsysteme

Ereignisse

Bedarfsplanung

Nivellierung

Bedarfspläne

Analysekomponente

Einsatzplanung

Abb. 7.1: Idealtypische Architektur von Personalbedarfsplanungssystemen Eine Ereignisdatei enthält relevante Eingangsdaten für die Bedarfsplanung. Diese stammen aus einer integrierten Ereignisplanung oder werden aus Vorsystemen importiert. Fertige Bedarfspläne werden ebenfalls in einer entsprechenden Datenhaltungskomponente abgespeichert. Eine fakultative Ereignisplanungs95

7

Personalbedarfsplanungssysteme komponente dient der Prognose bedarfsrelevanter Ereignisse, eine Bedarfsplanungskomponente unterstützt darauf aufbauend die Prognose künftiger Bedarfe. Eine fakultative Nivellierungskomponente ermöglicht einen Ausgleich von Bedarfsschwankungen innerhalb des Planungszeitraums. Eine Analysekomponente erlaubt die Auswertung und den Vergleich von Bedarfsplänen.

7.1.1

Ereignisdatei Abstrahiert von konkreten Aufgaben und Arbeitssituationen entsteht Personalbedarf regelmäßig aufgrund von bedarfsgenerierenden »Ereignissen« (vgl. Ernst et al. 2004, 5f.). Solche Ereignisse gestalten sich durchaus heterogen und können etwa aus dem Eingang von Anrufen in einem Call Center, aus Produktionsaufträgen in der industriellen Fertigung, aus dem Eingang einer Bestellung im Versandhandel oder aus dem Erscheinen von Kunden in einem Warenhaus bestehen. Generell sind es jedoch stets spezifische Ereignisse, die einen Personalbedarf auslösen. Entsprechend benötigen Personalbedarfsplanungssystem solche Ereignisse regelmäßig als Inputdaten für die Bedarfsplanung. Eine Ereignisdatei dient daher der strukturierten Ablage bedarfsgenerierender Ereignisse. Die Herkunft der Ereignisse hängt dabei von den Spezifika der Planungssituation ab. Im einfacheren Falle können bedarfsrelevante Ereignisse direkt aus Vorsystemen, etwa Systemen der Produktionsplanung und -steuerung u.a., übernommen werden und stehen dann direkt als Input für die Bedarfsplanung bereit. Teilweise müssen relevante Ereignisse aber auch unter Verwendung der Planungskomponente eigens prognostiziert werden, bevor sie in der Ereignisdatei zur Verfügung gestellt werden können. Sind für mehrere zu planende Qualifikationssegmente unterschiedliche Ereignisse relevant, so sind korrespondierend mehrere Ereigniskategorien parallel aufzunehmen.

7.1.2

Bedarfsplandatei Einmal erstellte und gegebenenfalls nivellierte Bedarfspläne werden für Zwecke der Analyse und der Weitergabe ebenfalls in einer Datenhaltungseinheit abgespeichert. Bedarfspläne bestehen dabei aus Angaben der zeitlichen, örtlichen, qualitativen und quantitativen Bedarfe. Bedarfspläne bestehen dabei regelmäßig aus Tabellen, die die qualitativen Bedarfe für den Planungszeitraum in einem i.d.R. frei wählbaren Zeitraster darstellen. Zur Visualisierung abgespeicherter Bedarfspläne werden üblicherweise Säulendiagramme gewählt, die den Bedarf je Zeitraum als »Bedarfsgebirge« wiedergeben (vgl. auch Abb. 7.2). In den meisten

96

7.1

Architektur und Funktionalität von Personalbedarfsplanungssystemen Fällen können dabei mehr als ein Plan je Planungszeitraum und Qualifikationskategorie abgelegt werden. Diese Abspeicherung von Alternativplänen ermöglicht eine szenario-orientierte Planung von Personalbedarfen.

7.1.3

Planungskomponente Die Planungskomponente besteht grundsätzlich aus einer Bedarfsplanungskomponente, die für die Umsetzung von bedarfsrelevanten Ereignissen in qualitative, quantitative, zeitliche und örtliche Personalbedarfe zuständig ist. Teilweise ist der Bedarfsplanung aber die Planung bedarfsrelevanter Ereignisse voranzustellen, was von einer eigenen Ereignisplanungskomponente übernommen wird. Fakultativ existiert in einigen Systemen weiter die Möglichkeit über den Planungszeitraum hinweg stark schwankende Personalbedarfe mit einer Nivellierungskomponente auszugleichen. Abb. 7.2 deutet diese einzelnen Teilschritte einer Planungskomponente an. E

PB

PB

t Planung Ereignisse

t Planung Bedarfe

t Nivellierung Bedarfe

Abb. 7.2: Teilschritte der Planungskomponente Ereignisplanung

In Abhängigkeit von der Art der bedarfsgenerierenden Ereignisse verfügen einige Systeme über eigene Komponenten, die im Vorfeld der eigentlichen Bedarfsplanung der Prognose solcher Ereignisse dienen. Ob eine eigenständige Ereignisplanung notwendig ist, hängt von der branchenspezifisch sehr unterschiedlichen Art der bedarfsgenerierenden Ereignisse ab. Grundsätzlich können bedarfsgenerierende Ereignisse nach den Kriterien der Bekanntheit ihres Eintrittszeitpunktes sowie der Bekanntheit ihrer Bedarfsfolgen kategorisiert werden. Im einfachsten Fall sind sowohl der Eintrittszeitpunkt als auch die Bedarfsfolgen bekannt. Dies gilt etwa für Bahnunternehmen, bei denen ein fester Fahrplan die Fahrt der Züge als bedarfsrelevante Ereignisse konkret vorwegnimmt. Dabei sind auch die Bedarfsfolgen im Sinne der notwendigen Lokomotivführer, Zugbegleiter etc. bekannt. Solche 97

7

Personalbedarfsplanungssysteme in anderweitigen Plänen (»Fahrplan«) bereits festgelegten Ereignisse werden i.d.R. von entsprechenden Vorsystemen abgefragt und in der Ereignisdatei abgelegt. Für die nachfolgende Bedarfsplanung schwieriger gestalten sich Ereignisse, deren Eintrittszeitpunkt und/oder Bedarfsfolgen nicht bekannt sind. So gilt etwa für das Auftreten von Kunden in Warenhäusern, dass weder der konkrete Eintrittszeitpunkt noch die genauen Folgen für den Verkäuferbedarf feststehen. In diesem Fall können bedarfsrelevante Ereignisse nicht einfach aus Vorsystemen übernommen werden, sondern sind in Auftreten und Bedarfsfolgen von einer Ereignisplanungskomponente zu prognostizieren. Liegt im Rahmen der Planungskomponente eine eigenständige Ereignisplanung vor, dann wird die Aufgabe der Prognose des Eintretens bedarfsrelevanter Ereignisse methodisch unterschiedlich gelöst. Verbreitet sind dabei ƒ vergangenheitsbasierte, ƒ simulationsbasierte und ƒ organisationsbasierte Methoden zur Prognose bedarfsrelevanter Ereignisse. Das Arbeiten mit Vergangenheitsmustern zielt grundsätzlich auf die Identifikation typischer Verlaufsformen des Auftretens der bedarfsgenerierenden Ereignisse in der Vergangenheit. Beispielsweise wird in Warenhäusern nach typischen Kundenbesuchsmustern, in Call Centern nach typischen Anrufeingangsmustern, in Notfallkliniken nach typischen Patienteneinlieferungsmustern gesucht. Regelmäßig werden hierzu Daten aus operativen Vorsystemen wie Kassensysteme der Warenhäuser, Call Center-Systeme oder Patientenverwaltungssysteme herangezogen. Auf dieser Basis werden typische Verlaufsmuster generiert. I.d.R. werden solche Verlaufsmuster dabei für einzelne Tage erstellt. Beispielsweise versucht man zur Bedarfsplanung in Warenhäusern nach Kundenbesuchsmustern für einen »typischen Donnerstag«. Dazu werden Kassendaten der vergangenen Donnerstage verwendet, um etwa über arithmetisches Mittlung die Kundenfrequenz im Tagesverlauf festzuhalten. Abb. 7.3 deutet ein solches vergangenheitsorientiertes Ereignistagesmuster an, das zur Ableitung von Personalbedarfen herangezogen werden kann. Durch Ableitung typischer Wochentage können so typische Wochen-, Monats- oder Jahresmuster erstellt werden. Spezifika, die zu Abweichungen führen, etwa ein erheblich abweichendes Muster für die Kundenfrequenz für den speziellen Donnerstag vor Ostern, sind dabei ebenfalls den Vergangenheitsdaten zu entnehmen und in den Planungszeitraum zu integrieren. Generell wird auf

98

Architektur und Funktionalität von Personalbedarfsplanungssystemen diese Weise versucht, über Vergangenheitsmuster das Problem des unbekannten Eintrittszeitpunktes bedarfsgenerierender Ereignisse zu handhaben. 400 350 300 Ereignisse

7.1

250 200 150 100 50 20-21

19-20

18-19

17-18

16-17

15-16

14-15

13-14

12-13

11-12

10-11

09-10

08-09

07-08

06-07

05-06

0

Uhrzeit

Abb. 7.3: Vergangenheitsbasiertes Ereignistagesmuster In einigen Systemen wird auch die Warteschlangensimulation (Ereignisbasierte Simulation, »Discrete Event Simulation«) verwendet, um das Auftreten bedarfsgenerierender Ereignisse zu prognostizieren. Grundsätzlich dient die Methode der Nachbildung von und dem Experimentieren mit so genannten »Warteschlangen«. Das Grundmodell der ereignisbasierten Simulation beruht darauf, dass gewisse dynamische bedarfsgenerierende Objekte (also etwa Kunden, Patienten, Anrufe, Teile, Dokumente etc.) einem – linearen oder verzweigten – Ablauf folgend verschiedene Bedienstationen (also etwa Kassen, medizinische Geräte, Call Center-Arbeitsplätze, Fertigungsstationen, Büroarbeitsplätze etc.) absolvieren müssen. Das Auftreten eines Objekts entspricht dabei einem bedarfsgenerierenden Ereignis. Da in einer Bedienstation von einem oder mehreren Mitarbeitern gewisse Aktivitäten an den Objekten verrichtet werden, die eine gewisse Zeit in Anspruch nehmen, bilden Objekte vor den Bedienstationen eventuell Warteschlangen (vgl. Troitzsch 2004, 1260f.). Objekte treten entsprechend aus Quellen in das zu simulierende System ein, durchlaufen die modellierte Struktur an Bedienstationen, bilden dabei eventuell Warteschlangen vor einer Bedienstation und verlassen das System in eine Senke. Neben deterministischen Vari99

7

Personalbedarfsplanungssysteme anten ist auf der Basis von Zufallszahlgeneratoren auch ein stochastisches Auftreten von Objekten abbildbar. Die jeweiligen Warteschlangen zeigen dabei auf, wie lange es bei gegebener personeller Ausstattung einer Bedienstation bis zur Abarbeitung eines bedarfsgenerierenden Ereignisses dauert (vgl. Abb. 7.4). Quelle Warteschlange1

Bedienstation1

Warteschlange2

Bedienstation2

Warteschlange...

Bedienstation...

Senke

Abb. 7.4: Simulationsbasierte Ereignisplanung Unter Vorgabe gewisser Servicelevel, wie etwa maximale Wartezeit eines Kunden an einer Kasse oder maximale Liegezeit eines Dokumentes vor seiner Weiterverarbeitung, können so zeitabhängige Personalbedarfe je Bedienstation bestimmt werden. Die ereignisbasierte Simulation eignet sich daher speziell zur Bedarfsplanung in Bereichen mit Bedien- und Warteprozessen. Entsprechend können industrielle Fertigungsprozesse ebenso geplant werden wie Dienstleistungen oder der Verwaltungsbereich von Unternehmen. Eine dritte, insbesondere für das Verwaltungssegment angewendete Methode, wählt eine organisationsorientierte Vorgehensweise. Generell werden dabei Ergebnisse der Aufgabenanalyse als Grundlage der Bedarfsplanung herangezogen. Die Aufgabenanalyse zergliedert eine Gesamtaufgabe nach diversen Kriterien in Teilaufgaben und liefert damit eine einfache Liste bzw. eine Hierarchie zu bearbeitender Teilaufgaben. Im einfachsten Fall werden solche Aufgabenlisten um die geschätzte Häufigkeit und die Zeitpunkte ihres Auftretens im Planungszeitraum und die zur Bearbeitung grundsätzlich benötigte Personalkategorie ergänzt. Die im Planungszeitraum abzuarbeitenden Aufgaben bilden dann die grundsätzlichen bedarfsgenerierenden Ereignisse (vgl. Abb. 7.5).

100

7.1

Architektur und Funktionalität von Personalbedarfsplanungssystemen Aufgabe

Menge/Tag Mitarbeiterkategorie

1. Einkauf 1.1 Bestellung 1.1.1 Ausarbeitung Bestellung

2

Sachbearbeiter

1.1.2 Freigabe Bestellung

2

Abteilungsleiter

1.2.1 Warenannahme

2

Lagerist

1.2.2 Qualitätsprüfung

2

Lagerist

...

...

1.2 Wareneingang

...

Abb. 7.5: Organisationsorientierte Ereignisplanung Werden in diesem Zusammenhang einzelne Aufgaben zu Stellen zusammengeführt, kann eine sich anschließende Bedarfsplanung auch in Form der Stellenplanmethode stattfinden. Eine weitere Variante besteht in der Zusammenstellung von Aufgaben zu Geschäftsprozessen. In diesem Fall werden nicht Einzelaufgaben, sondern zusammenhängende Ketten von Aufgaben zur Grundlage der Bedarfsplanung. Das Erfüllen einer Teilaufgabe führt dabei zu Ereignissen, die das Erfüllen nachgelagerter Teilaufgaben erforderlich machen. Auch hierbei sind Häufigkeiten und Zeitpunkte des Auftretens von Prozessen im Planungszeitraum eine notwendige Ergänzung im Vorgriff auf die eigentliche Bedarfsplanung (vgl. Hüsselmann 2006). Eine solche organisationsorientierte Vorgehensweise ist dabei insbesondere dann nahe liegend, wenn die notwendigen aufwändigen Aufgaben- bzw. Geschäftsprozessanalysen auch für weitere Zwecke durchgeführt werden müssen. Bedarfsplanung

Unter Rückgriff auf die Daten der Ereignisdatei kann die Bedarfsplanungskomponente dann konkrete räumliche, zeitliche und örtliche Bedarfe prognostizieren. Dabei werden grundsätzlich bekannte oder zu erhebende Zusammenhänge zwischen dem bedarfsgenerierenden Ereignis und dem daraus resultierenden Personalbedarf herangezogen. Sind diese Zusammenhänge aufgrund von Erfahrung, betrieblicher Festlegung oder extern zum System durchgeführten arbeitswissenschaftlichen Studien bekannt, wie etwa der Bedarf an Lokomotivführern und Zugbegleitpersonal für die Fahrt eines Nahverkehrszugs, dann ist durch die Bedarfsplanungskomponente eine einfache Umsetzung in Personalbedarfe möglich. In einigen Systemen wird zusätzlich auch die Ermittlung solcher Zusammenhänge etwa über Verfah101

7

Personalbedarfsplanungssysteme ren der »Selbstaufschreibung« entsprechender Mitarbeiter unterstützt. Mitarbeiter ermitteln – teils Self Service-basiert – entsprechende Zeitbedarfe für Aufgaben, die dann für eine Bedarfsplanung verwendet werden können. Etwa können zum Beispiel bei einer geschäftsprozessbasierten Bedarfsplanung die für einzelne Funktionen eines Prozesses ermittelten Zeitbedarfe über den gesamten Geschäftsprozess hinweg aufsummiert und als Gesamtbedarf ausgegeben werden. Bei verzweigten Prozessen sind zusätzlich empirische Daten zur Häufigkeit einzelner Prozesszweige notwendig. Sind einzelne Funktionen von unterschiedlichen Mitarbeiterkategorien zu erfüllen, kann auch dies berücksichtigt werden. Unter Rückgriff auf die Informationen zu Häufigkeiten und mögliche Zeitpunkte des Auftretens des Prozesses im Planungszeitraum können die so geschaffenen Daten in Gesamtbedarfe umgerechnet werden. Abb. 7.6 deutet dieses Umsetzen von Ereignissen in Bedarfe exemplarisch an.

E1 F1 (t = 20 min) E2.1 F2 (t = 15 min)

80%

20% XOR

E2.2 F3 (t = 45 min)

E3 F4 (t = 30 min) E4

Abb. 7.6: Geschäftsprozessbasierte Personalbedarfsplanung In analoger Weise werden vergangenheits- oder warteschlangenbasiert ermittelte bedarfsgenerierende Ereignisse in konkrete Personalbedarfe umgesetzt. Als Ergebnis liegen quantitative zeitabhängige Nettopersonalbedarfe je Mitarbeiterkategorie vor, die in die Bedarfsplandatei eingestellt werden können. Die so erstellten Nettobedarfspläne können dann i.d.R. noch um prozentuale Auf-

102

7.1

Architektur und Funktionalität von Personalbedarfsplanungssystemen schläge für den Reservebedarf (Abwesenheiten wegen Krankheit, Schulung etc.) zu einer Bruttobedarfsplanung ergänzt werden. Insbesondere für operative Bedarfspläne, die im Vorfeld einer Einsatzplanung erstellt werden, werden teilweise Nivellierungsfunktionen angeboten. Eine Nivellierung der Bedarfe zielt grundsätzlich auf den Ausgleich von »Bergen« und »Tälern« des »Bedarfsgebirges« zur Vereinfachung der sich anschließenden Personaleinsatzplanung. Voraussetzung der Nivellierung ist, dass nicht der gesamte Bedarf zeitkritisch ist, sondern zumindest teilweise und begrenzt – etwa innerhalb eines Vor- oder Nachmittages – verschiebbar ist. Entsprechend ist bereits bei der Bedarfsplanung zwischen nicht-verschiebbaren und begrenzt verschiebbaren Personalbedarfen zu unterscheiden. 12 10 8 6 Personalbedarf [h]

Nivellierung

4 2 0 = nicht verschiebbar

= verschiebbar

8 6 4 2 20-21 19-20 18-19 17-18 16-17 15-16 14-15 13-14 12-13 11-12 10-11 09-10 08-09 07-08 06-07 05-06

0

Uhrzeit

Abb. 7.7: Nivellierung geplanter Personalbedarfe Besteht ein bedarfsgenerierendes Ereignis beispielsweise in einer Kundenreklamation, ist die direkte Annahme der Reklamation nicht-verschiebbar, die Durchführung wie z.B. der Retour des Produktes an den Hersteller kann jedoch in bedarfsärmere Zeiten desselben Tages gelegt werden. Neben einer Rückverschiebung von Bedarfen ist dabei teilweise auch eine Vorverlagerung von 103

7

Personalbedarfsplanungssysteme vorbereitenden Tätigkeiten möglich. Entsprechend zielen Nivellierungsalgorithmen auf die Vor- oder Rückverlagerung begrenzt verschiebbarer Bedarfe (vgl. Brecht et al. 1998). Abb. 7.7 deutet das Ergebnis einer Nivellierung von Tagespersonalbedarfen an.

Zeitraum und Zeitrasterung

Die Planungszeiträume und deren Rasterung in Planungszeiteinheiten unterscheiden sich in den vorfindbaren Systemen. Insbesondere Systeme zur Planung des operativen Bedarfs auf Basis von Vergangenheitsdaten im Vorfeld einer Personaleinsatzplanung sind oft ausgesprochen operativ ausgerichtet. So können operative Bedarfe oft für den Planungszeitraum einer Woche bis mehrerer Monats geplant werden. Die mögliche Rasterung dieser Planungszeiträume ist dabei oft fein-granular. Nicht selten können Bedarfe auf ¼ h-Basis, teils sogar auf Minutenbasis, geplant werden. In der Regel ist es dabei auch möglich, Bedarfe in unterschiedlichen Zeitrastern, also auf Stunden-, Tages- und Wochenbasis anzuzeigen. Dagegen sind organisationsbasierte Planungskomponenten notwendigerweise auf längere Planungszeiträume von mehreren Quartalen ausgerichtet, die in der Regel dann auch nicht so fein-granular gerastert werden. Auch hier ist jedoch die Anzeige in unterschiedlichen zeitlichen Rastern, also etwa auf Wochen- und auf Monatsebene, möglich. Verfügt ein System über Ereignisplanungs-, Bedarfsplanungs- und Nivellierungskomponente, ist die Übereinstimmung möglicher Planungszeiträume und deren Rasterung selbstverständlich eine Voraussetzung des integrierten Einsatzes der drei Teilkomponenten.

7.1.4

Analysekomponente Die Analysekomponente dient der Auswertung und dem Vergleich erzeugter Personalbedarfspläne. Entsprechend sind beispielsweise tabellarische und grafische Auswertungen der geplanten Bedarfe nach Mitarbeiterkategorien, Abteilungen, Standorten etc. möglich. Existieren mehrere Alternativplanungen, können diese auch im Sinne von Mehr- und Minderbedarfen systematisch miteinander verglichen werden. Auch in der Analysekomponente können Bedarfe regelmäßig in unterschiedlichen Zeitrastern ausgewertet werden.

7.2

Anwendung von Personalbedarfsplanungssystemen Personalbedarfsplanungssysteme unterstützen die Bestimmung kurz- und mittelfristiger operativer Personalbedarfe. Als solche können sie etwa im Vorfeld von notwendigen Beschaffungs- oder Freisetzungsaktivitäten sinnvoll eingesetzt werden. Die auch

104

7.2

Anwendung von Personalbedarfsplanungssystemen

auf mittlere Frist mögliche Vorwegnahme künftiger positiver oder negativer Nettopersonalbedarfe kann dabei als Grundlage eines proaktiven Beschaffungs- und Freisetzungsmanagements verstanden werden. Ebenso ist die Anwendung (operativer) Personalbedarfsplanungssysteme im Vorfeld einer Personaleinsatzplanung notwendig (vgl. Kap. 8). Entsprechend bieten viele Hersteller Bedarfs- und Einsatzplanungssysteme auch im Sinne einer modularen Makroarchitektur (vgl. Kap. 1) an. Verbreitung und Perspektiven

Derzeit sind keine empirischen Studien zur Verbreitung von Personalbedarfsplanungssystemen bekannt. Gegenwärtig wird unter dem Begriff »Workforce Management (WFM)« insbesondere die integrative Zusammenfassung der Personalbedarfsplanung, der Personaleinsatzplanung und des Arbeitszeitmanagement (vgl. Kap. 14) als zukunftsweisendes Konzept diskutiert (vgl. z.B. Brill 2005). Eine klare und einheitliche Konzeption eines Workforce Management hat sich derzeit allerdings (noch) nicht herausgebildet, und teilweise wird der Begriff auch lediglich als Aufmerksamkeit heischender Neologismus für die Personaleinsatzplanung verwendet. Aufgrund der engen Verzahnung dieser Bereiche ist deren integrative Abbildung in Informationssystemen durchaus sinnvoll, wird aber wie bereits erwähnt auch von verschiedenen Herstellern durchaus schon seit längerem angeboten.

105

8

Personaleinsatzplanungssysteme Personaleinsatzplanungsysteme (PEP-Systeme, Personaldispositionssysteme, Dienstplanungssysteme, Workforce Management-Systeme [WMF], »Work[force]-Scheduling Systems«, »Rostering Systems«) sind Anwendungen zum kurz- bis mittelfristigen Abgleich des quantitativen und qualitativen Personalbedarfs mit dem Personalbestand respektive dem konkreten Personaleinsatz.

8.1

Architektur und Funktionalität von Personaleinsatzplanungssystemen Inzwischen existiert eine durchaus heterogene, stark branchenorientierte Gruppe an Personaleinsatzplanungssystemen. Idealtypisch für ein Personaleinsatzplanungssystem sind dabei Dateien mit Mitarbeiter-, Bedarfs-, Schicht-, Schichtfolgen- und Einsatzplandaten sowie Komponenten zur Bedarfsplanung, Schichtplanung, Schichtfolgenplanung, Mitarbeiterzuordnung sowie zur Analyse und Disposition (in Anlehnung an Ernst et al. 2004, 4f. und Scherf 2005a, 21ff., vgl. Abb. 8.1). Personaleinsatzplanungssystem Anwenderschnittstelle Planungskomponente Bedarfsplanung

Schichtplanung

Schichtfolgenplanung

Bedarfe

Schichten

Schichtfolgen

Bedarfsplanung

Mitarbeiterzuordnung

Mitarbeiter

Analyse- u. DispositionsKomponente

Einsatzpläne

Arbeitszeitmanagement

Abb. 8.1: Idealtypische Architektur von Personaleinsatzplanungssystemen

107

8

Personaleinsatzplanungssysteme Eine fakultative Bedarfsplanungskomponente dient der Bestimmung der zeitlichen, örtlichen, qualitativen und quantitativen Personalbedarfe, die als Inputgröße für jede Einsatzplanung notwendig sind. Die Schichtplanungskomponente plant einzelne Schichten (Dienste, Einsätze oder Anwesenheiten), die den entsprechenden Bedarf decken. Die Schichtfolgenplanung dient der Zusammenstellung einzelner Schichten (Diensten, Einsätzen oder Anwesenheiten) im Zeitablauf. Die jeweils erzielten Zwischenergebnisse werden in korrespondierenden Dateien zwischengespeichert. Die Zuordnungskomponente hat schließlich die Aufgabe der Zuordnung einzelner Mitarbeiter, deren Daten in einer Mitarbeiterstammdatei gehalten werden, zu Schichtfolgen. Die so erzielten Ergebnisse werden in einer Einsatzplandatenbank abgelegt. Eine Analyse- und Dispositionskomponente ermöglicht die Auswertung und kurzfristige manuelle Veränderung erstellter Einsatzpläne.

8.1.1

Datenhaltungskomponenten Korrespondierend mit den Subkomponenten der Planung existieren jeweils eigene Datenhaltungskomponenten.

Bedarfsdatei

Ausgangspunkt jeder Einsatzplanung sind die operativen Personalbedarfe. Entsprechend dient eine Bedarfsdatei der Abspeicherung der qualitativen, quantitativen, zeitlichen und örtlichen Personalbedarfe. Diese können entweder von Vorsystemen, speziell Personalbedarfsplanungssystemen (vgl. Kap. 7), oder aber einer fakultativen internen Bedarfsplanungskomponente stammen. Entsprechend enthält die Bedarfsdatei Bedarfspläne im Sinne einer systematischen Aufstellung operativer Bedarfe für den gesamten Planungszeitraum, die in tabellarischer oder grafischer Form ausgegeben werden können.

Schichtdatei

Unter einer »Schicht« wird generell eine tägliche bzw. nächtliche Anwesenheit verstanden, wobei zunächst offen bleibt, welcher konkrete Mitarbeiter dieser Schicht zugeordnet wird. Der Schichtbegriff ist allerdings nicht durchgängig gebräuchlich. Je nach Anwendungssegment und System finden sich daher auch Synonyme wie »Dienste«, »Anwesenheiten« oder schlicht »Einsätze«. Die von der Schichtplanungskomponente geplanten Schichten werden entsprechend in einer Schichtdatei abgelegt und stehen danach für die Schichtfolgenplanung zur Verfügung.

Schichtfolgendatei Schichtfolgen stellen sinnvolle Folgen einzelner Schichten für einen gewissen Planungszeitraum dar. Entsprechende, von der Schichtfolgenplanungskomponente festgelegte Schichtfolgen wer108

8.1

Architektur und Funktionalität von Personaleinsatzplanungssystemen den in einer Schichtfolgendatei zwischengespeichert und stehen danach für die Mitarbeiterzuordnung zur Verfügung.

Einsatzplandatei

Über die Mitarbeiterzuordnung erstellte Einsatzpläne werden für Zwecke der Bekanntgabe, der Veränderung und des Exports ebenfalls in einer Datei gespeichert. Die Datei dient zunächst der Bekanntgabe abgespeicherter Einsatzpläne. Diese kann etwa per Ausdruck und Aushang, per Mailversand, Short Message Service (»SMS«) oder aber auch per browserbasiertem Zugriff auf die Daten realisiert werden (vgl. Hesseln & Zander 2005, 143). Sind wegen unvorhergesehenen Ereignissen, wie Krankheit, kurzfristige Abänderungen erstellter Einsatzpläne notwendig, dann kann über die Analyse- und Dispositionskomponente auf die abgespeicherten Einsatzpläne zugegriffen und Abänderungen vorgenommen werden. Schließlich versorgt die Datenbank auch externe Systeme mit Einsatzplandaten. Spezielle Adressaten von Einsatzplänen sind Arbeitszeitmanagmentsysteme (vgl. Kap. 14). Hier können importierte Planzahlen dann zur Überprüfung der faktischen Ist-Anwesenheiten im Zeitablauf verwendet werden.

8.1.2

Planungskomponente

Partial- vs. Totalplanung

Die in obiger Architektur aufscheinende Dekomposition der Planungskomponente in einzelne, sukzessive anzuwendende Teilkomponenten ist aus Sicht einer optimierten Gesamtplanung zunächst nicht unbedingt sinnvoll, reduziert aber die teils erhebliche Modellierungskomplexität und macht die resultierenden Teilprobleme »lösbarer« (vgl. Ernst et al. 2004). Aufgrund zahlreicher Interdependenzen zwischen den einzelnen Planungsschritten existieren allerdings auch teilintegrierte Systeme, die zum Preis erhöhter Modellierungs- und Lösungskomplexität hier getrennt aufgeführte Komponenten – wie etwa Schichtfolgenplanung und Mitarbeiterzuordnung – in einer Komponente vereinen. Ebenso existieren auch partielle Einsatzplanungssysteme, die »nur« eine der Komponenten – etwa die Schichtplanung – aufweisen. Die verbleibenden Aufgaben wie die Bildung sinnvoller Schichtfolgen und die Zuordnung von Mitarbeitern sind dann im Rahmen der Dispositionskomponente »manuell« abzuarbeiten.

Optimierung vs. Approximation

Trotz der Dekomposition in Teilplanungsprobleme bleibt das Problem der Personaleinsatzplanung bestehen. Mit Ausnahme der Bedarfsplanung (vgl. dazu Kap. 7) bestehen die Teilschritte der Einsatzplanung in Zuordnungsproblemen, die im Folgenden noch genauer beschrieben werden. Diese Zuordnungsaufgaben lassen sich regelmäßig als Optimierungsproblem unter Nebenbe109

8

Personaleinsatzplanungssysteme dingungen verstehen. Reale Einsatzplanungssituationen sind dabei durch eine sehr große Zahl veränderbarer Variablen und Restriktionen gekennzeichnet. Solche Probleme können dann zwar noch als Optimierungsproblem modelliert werden, können aber mit verfügbaren Optimierungsalgorithmen (vgl. zu einem Überblick Ernst et al. 2004) auch auf sehr schneller Hardware oft nicht mehr oder zumindest nicht mehr in vertretbarer Zeit gelöst werden (vgl. Spengler 2004; Scherf 2005a). Verfügbare Systeme wenden daher neben Optimierungsalgorithmen sehr häufig Approximationsalgorithmen (»Heuristiken«) an (vgl. zu einem Überblick erneut Ernst et al. 2004). Generell lösen Approximationsalgorithmen das Optimierungsproblem näherungsweise. Gefundene Lösungen halten die aufgestellten Restriktionen ein, haben aber keinen Anspruch auf Optimalität. Man spricht daher nicht mehr von optimalen, sondern von »zulässigen« Lösungen des Planungsproblems (vgl. Blazewicz et al. 2007, 35ff.). Anbieter von Einsatzplanungssoftware legen die faktisch verwendeten Algorithmen allerdings häufig nicht offen. Als Marketingpraxis hat es sich (leider) verbreitet, auch solche Annäherungen als »optimierte Lösung« zu bezeichnen. Da die Optimallösung dann eben notwendigerweise unbekannt bleibt, kann man sehr häufig nur eingeschränkte Aussagen über die Güte der gefundenen Lösung machen. Gerade die Güte der gefundenen Lösung ist allerdings zentral, denn auch kleinere Abweichungen von der Optimallösung können betriebswirtschaftlich zentrale Folgen haben. Neben der Lösungsgüte ist allerdings auch die Laufzeit eines Algorithmus eine zentrale Anforderung, denn Laufzeitschwächen von Algorithmen können nur beschränkt durch Steigerung der Hardwaregeschwindigkeit kompensiert werden. Gute Approximationsalgorithmen gehen entsprechend einen »Trade Off« zwischen Lösungsgüte und Laufzeit ein (vgl. Bollenbeck 2006).

Zeiträume und Zeitrasterungen

Einsatzplanungssysteme sind klar operativ ausgerichtet und entsprechend für kurz- bis mittelfristige Planungszeiträume konzipiert. Diese Planungszeiträume können häufig sehr fein gerastert sein. Regelmäßig sind die jeweiligen Planungen in ¼-stündiger, nicht selten sogar auf 1-minütiger Rasterung möglich. Je nach spezifischer Planungsaufgabe können Pläne dabei auch in unterschiedlichen Zeitrastern, d.h. auf Minuten-, Viertelstunden-, Halbstunden-, Stunden-, Tages- und für mittelfristige Perspektive teils auch auf Wochenbasis erstellt werden.

Bedarfsplanung

Konventionell wird die Bedarfsplanung als eigenständige personalwirtschaftliche Teilplanung gesehen und nicht zwingend der Einsatzplanung zugerechnet. In Entsprechung hierzu finden sich

110

8.1

Architektur und Funktionalität von Personaleinsatzplanungssystemen Einsatzplanungssysteme, die keine eigene Bedarfsplanungskomponente aufweisen. Da der operative Personalbedarf ein unverzichtbarer Input für eine Einsatzplanung darstellt, müssen geeignete Bedarfsdaten dann entweder von externen Personalbedarfsplanungssystemen (vgl. Kap. 7) übernommen oder anderweitig bestimmt und manuell eingepflegt werden. Aufgrund der engen Zusammenhänge weisen zahlreiche Systeme allerdings eine integrierte Bedarfsplanungskomponente auf. Die Aufgabe der Bedarfsplanungskomponente besteht damit grundsätzlich in der Feststellung der operativen Personalbedarfe für die Dauer des Planungshorizontes. Dabei müssen Planungszeiträume sowie deren Rasterung notwendigerweise den Zeiträumen und -rastern der nachfolgenden Komponenten entsprechen (vgl. dazu Kap. 7). Stehen die Personalbedarfe fest, besteht ein weiterer Schritt der Einsatzplanung darin, die Anzahl, Dauer und Lage derjenigen Schichten zu bestimmen, die diesen Bedarf decken (vgl. Brecht et al. 1998).

Schichtplanung

Personalbedarf/-einsatz [h]

14 12 10 8 6 4 2 20-21

19-20

18-19

17-18

16-17

15-16

14-15

13-14

12-13

11-12

10-11

09-10

08-09

07-08

06-07

05-06

0

Uhrzeit konventionelle Zweierschicht optimierte Mehrfachschicht

Abb. 8.2: Schichtplanung Mit Bezug auf den spezifizierten Personalbedarf ist es daher Aufgabe der Schichtplanung, in möglichst ökonomischer Weise An111

8

Personaleinsatzplanungssysteme zahl, Dauer und Lage von Schichten zu dessen Deckung festzulegen. Das Optimierungsproblem der Schichtplanung besteht damit grundsätzlich darin, Schichten so Bedarfen zuzuordnen, dass alle Bedarfe gedeckt sind, die Überdeckung aber möglichst gering ausfällt. Abb. 8.2 deutet die Aufgabe der Schichtplanung an. Zunächst gibt das »Bedarfsgebirge« das Ergebnis einer operativen Tagesbedarfsplanung im Einstundenraster wieder. Unterstellt man vereinfachend vertragliche Arbeitszeitdauern von 8h/Tag, könnte der damit angedeutete Personalbedarf zunächst in konventioneller Weise durch zwei aufeinander folgende Schichten, einer Frühschicht und einer Spätschicht, abgedeckt werden. Sind diese Bedarfe allerdings zeitkritisch und entsprechend keine weiteren Nivellierungen des Bedarfs möglich (vgl. Kap. 7), dann ist in jeder Schicht der maximale Personalbedarf vorzuhalten, was erkennbar zu erheblichen Personalüberdeckungen führt. Wiederum vereinfachend unterstellt, dass Schichten jeweils nur zur vollen Stunde beginnen, die Dauer einer Schicht 8h/Tag beträgt und keine Pausen einzuplanen sind, kann in diesem einfachen Problem mittels Optimierung eine Mehrschichtlösung gefunden werden, die die Personalüberdeckung minimiert (vgl. Abb. 8.2 und 8.3). Auch diese Mehrschichtlösung weist zwar noch Überdeckungen auf, allerdings sind diese erheblich geringer als bei der konventionellen Zweischichtlösung. In solchen Anpassungen von Personalbedarf und Personaleinsatz liegt ein wesentliches Produktivitätspotenzial von Personaleinsatzplanungssystemen. Von Einsatzplanungssystemen zu lösende reale Schichtplanungsprobleme weisen jedoch zahlreiche weitere Variablen und Restriktionen auf. Ein erster Punkt betrifft etwa die Berücksichtigung unterschiedlicher Teilzeitschichten. Im Zusammenhang hiermit ist es bei flexibleren Einsatzmöglichkeiten des entsprechenden Personals auch sinnvoll, nicht mit fest vorgegebenen Schichtdauern zu arbeiten, sondern das System neben der optimalen Lage der Schicht auch deren optimale Dauer bestimmen zu lassen. Natürlich sind weiter auch Betriebsdauern von etwa 24h/Tag oder tagesindividuell variierende Betriebsdauern planbar. Weiter können anders als im einfachen Beispiel in der Regel mehrere unterschiedliche Qualifikationskategorien, wie etwa »Meister«, »Facharbeiter« und »Aushilfen«, berücksichtigt werden. Ebenso kann das einstündige Zeitraster verfeinert und die Planung auf der Basis kürzerer Zeiteinheiten durchgeführt werden. Weiter können auch zusätzliche Restriktionen, wie etwa die insgesamt zur Verfügung stehende Personalausstattung oder die Notwendigkeit von Pausen, aufgenommen werden.

112

8.1

Architektur und Funktionalität von Personaleinsatzplanungssystemen Schichten

Gesamteinsatz

Überdeckung

6

6

0

06-07

4

6

2

07-08

3

6

3

08-09

8

9

1

09-10

9

9

0

10-11

11

13

2

11-12

13

13

0

12-13

5

13

8

13-14

8

14

6

14

7

14

5

11

0

Uhrzeit

Bedarf

05-06

S1

S2

S3

S4

S5

S6

S7

S8

S9

6 0 0 3 0 4

14-15

7

15-16

9

16-17

11

17-18

8

11

3

18-19

5

7

2

19-20

3

7

4

20-21

7

7

0

0 0 7

Abb. 8.3: Optimierte Mehrschichtlösung Entsprechend dieser Komplexität von Schichtplanungsproblemen dürften Einsatzplanungssysteme eher approximative denn optimierende Algorithmen verwenden. Schichtfolgenplanung

Die Schichtplanung ergibt die notwendigen Schichten lediglich für einzelne Tage. Die sich anschließende Aufgabe der Schichtfolgenplanungskomponente ist es daher, einzelne Schichten zu sinnvollen Folgen zu kombinieren. Das Zuordnungsproblem besteht entsprechend darin, einzelne Schichten so zu Schichtfolgen zuzuordnen, dass bei einer minimalen Anzahl von Schichtfolgen (dadurch verursachte Kosten o.a.) die notwendigen Schichten gewährleistet werden können. Unterstellt man in obigem Beispiel, dass die gefundenen optimalen Schichten für jeden Tag einer zu planenden 5-Tage Woche gelten und dass alle Schichten beliebig miteinander kombiniert werden können, ergeben sich bereits für die Planungszeitraum einer Woche zahlreiche Kombinationsmöglichkeiten, wie in Abb. 8.4 grundsätzlich angedeutet. Bei der Schichtfolgenplanung existieren verschiedene zu berücksichtigende Restriktionen. 113

8

Personaleinsatzplanungssysteme Woche1

Möglichkeiten Schichtfolge1

Möglichkeiten Schichtfolge2 ...

Mo

Di

Mi

Do

Fr

S1

S1

S1

S1

S1

S4

S4

S4

S4

S4

S6

S6

S6

S6

S6

S9

S9

S9

S9

S9

S1

S1

S1

S1

S1

S4

S4

S4

S4

S4

S6

S6

S6

S6

S6

S9

S9

S9

S9

S9

...

...

...

...

...

Abb. 8.4: Schichtfolgenplanung Zunächst schränken aus betrieblichen oder tariflichen Gründen notwendige zyklische (»rollierende«) Schichtfolgen die grundsätzlichen Kombinationsmöglichkeiten erheblich ein. In diesem Fall sind die Schichtfolgen für alle Mitarbeiter einer bestimmten Kategorie übereinstimmend zu gestalten und so anzulegen, dass sie sich regelmäßig wiederholen, wobei sich die Startzeitpunkte einzelner Schichtfolgen allerdings unterscheiden. Die oben dargestellten umfassenden Kombinationsmöglichkeiten gelten insofern nur für »azyklische« Schichtfolgen, bei denen einzelne Schichtfolgen von einander unabhängig und völlig unterschiedlich ausfallen dürfen. Andererseits existieren auch Systeme, die zyklische und azyklische Schichtfolgen kombinieren können. Ein Teil der Mitarbeiter arbeitet dann nach zyklischen Schichtfolgen, ein anderer Teil azyklisch. Weitere Restriktionen ergeben sich bei der Vorgabe von Schichtblöcken. Hier legt man sich auf gewisse Schichtfolgenbestandteile, die Schichtblöcke, fest. Z.B. gibt der Schichtblock »Frei-Frei-Frei« vor, dass Freischichten von Mitarbeitern etwa zum Zweck ausreichender Erholung stets aus drei freien Tagen am Stück bestehen müssen, wo immer sie eingeplant werden. Korrespondierend können weitere betrieblich sinnvolle oder rechtlich notwendige Schichtblöcke definiert werden. Der Unterschied zu zyklischen Schichtfolgen besteht darin, dass Schichtfolgen zwar aus Sequenzen solcher Schichtblöcke bestehen, diese sich aber untereinander unterscheiden können und sich auch nicht regelmäßig zu wiederholen brauchen. Weitere zu definierende Restriktionen bestehen in der Unzulässigkeit gewisser Schichtfolgenbestandteile (z.B. keine Frühschicht direkt nach 114

8.1

Architektur und Funktionalität von Personaleinsatzplanungssystemen einer Nachtschicht) sowie der Vorgabe von Obergrenzen (z.B. maximal zulässige Zahl aufeinander folgender Nachtschichten) und Untergrenzen (z.B. Zahl der in einer Woche mindestens zu berücksichtigen Ruhetage) definiert werden. In Überlappung mit der Mitarbeiterzuordnung kann die Berücksichtigung von Einsatzwünschen von Mitarbeitern bereits in der Schichtfolgenplanung erfolgen. Entsprechend ihrer Präferenzen geben Mitarbeiter dabei entweder komplette Schichtfolgen, viel häufiger aber gewisse Eigenschaften von Schichtfolgen wie etwa »keine Nachtarbeit in KW 32« oder »freier Nachmittag am 12.09.« an. Gerade die Berücksichtigung kumulierter Mitarbeiterpräferenzen führen zu erheblichen Einschränkungen und Komplikation des Planungsproblems. Ebenso wird der enge inhaltliche Zusammenhang von Schichtfolgenplanung und Mitarbeiterzuordnung offensichtlich. Analog zu der Situation der Schichtplanung stellt sich auch die Schichtfolgenplanung als komplexes Zuordnungsproblem dar. Daher werden auch hierzu eher Approximationsalgorithmen eingesetzt.

Mitarbeiterzuordnung

Die verbleibende Aufgabe der Mitarbeiterzuordnungskomponente besteht darin, Mitarbeiter so zu den geplanten Schichtfolgen zuzuordnen, dass bei möglichst geringen Kosten alle Schichtfolgen mit Mitarbeitern besetzt sind. Zwingende Restriktionen einer solchen Zuordnung ergeben sich zunächst aus der Verfügbarkeit entsprechender Mitarbeiter. Entsprechend sind vorab bekannte Abwesenheiten wie Urlaub, Schulungsteilnahme, Krankenhausaufenthalte etc. in das Zuordnungsmodell einzuspeisen. Im weiteren Sinn bildet auch die mit den Mitarbeitern vereinbarte Periodenarbeitszeit eine Verfügbarkeitsrestriktion. So sollte die Zuordnungskomponente eine kostspielige und ohnehin nur begrenzt mögliche Mehrarbeit von Mitarbeiter möglichst genauso vermeiden wie ein chronisches Unterschreiten der vereinbarten Periodenarbeitszeiten. Als »verfügbar« sollten entsprechend insbesondere Mitarbeiter mit noch nicht erreichter Periodenarbeitszeit gelten und entsprechend prioritär zugeordnet werden. Bestehen Schnittstellen zu Arbeitszeitmanagementsystemen, können hierzu entsprechende Zeitkontenstände importiert werden (vgl. Hesseln & Zander 2005). Werden weiter Mitarbeiter unterschiedlicher Kategorien wie etwa Qualifikationen, Tätigkeitsgruppen etc. verplant, bildet selbstverständlich auch die generelle Eignung des Mitarbeiters für eine entsprechende Schichtfolge eine weitere zwingende Planungsrestriktion. Zumindest fakultativ bieten zahlreiche Systeme auch die Möglichkeit der Berücksichtigung von Mitarbeiterpräferenzen. Neben konkret erwünschten bzw. uner115

8

Personaleinsatzplanungssysteme wünschten Schichten und Schichtfolgen kommen hier durchaus weitere Aspekte wie etwa die gemeinsame Verplanung von Mitarbeitern mit privater Fahrgemeinschaft in parallelen Schichtfolgen in Frage. Häufig können Mitarbeiter hierbei unterschiedliche Präferenzen äußern und diese auch in eine Rangfolge bringen. Gerade diese zusätzlich zu Belangen des Betriebs stattfindende Berücksichtigung von Mitarbeiterbelangen dürfte ein weiteres zentrales Potenzial von Personaleinsatzplanungssystemen darstellen. In mittelbarem Zusammenhang mit den Mitarbeiterpräferenzen bildet auch die gerechte Verteilung von »unbeliebten« Schichtfolgen, etwa solche, die viele Nacht- oder Wochenendeinsätze implizieren, eine weitere Nebenbedingung. Entsprechend verfügen ausgereifte Systeme über die Möglichkeit, unbeliebte Schichtfolgen mittelfristig gleichmäßig über alle Mitarbeiter zu verteilen. Woche1 Mo Müller

S1

...

S1

...

S9

Hinz Kunz

S6

Schmid

S6

...

...

S4 S4

Maier

Korz

Di

S1 ...

S9 S6

... ...

S4

...

S4

... ...

...

Abb. 8.5: Zuordnung von Mitarbeitern zu Schichtfolgen Nach der Zuordnung liegt ein abgeschlossener Einsatzplan für die entsprechende Planungsperiode vor, der üblicherweise in Gantt-Diagrammen visualisiert wird. Entsprechend deutet Abb. 8.5 die für das einfache Beispiel gefundene Zuordnung von Mitarbeitern zu azyklischen Schichtfolgen an.

8.1.3

Analyse- und Dispositionskomponente Die Analyse- und Dispositionskomponente dient der Auswertung und der Anpassung erstellter Einsatzpläne sowie der »manuellen« Bearbeitung von nicht automatisiert übernommenen Planungsaufgaben.

116

8.1

Architektur und Funktionalität von Personaleinsatzplanungssystemen

Analysekomponente

Die Analysekomponente ermöglicht es zunächst, erzeugte Einsatzpläne nach vielfältigen interessierenden Aspekten auszuwerten. So sind etwa Auswertungen der geplanten Schichten je Mitarbeiter, Mitarbeiterkategorie, Abteilung, Standort etc. möglich. Ebenso können geplante Einsätze auf Gesamtkosten, entstehende Mehrarbeitszuschläge, Einhalten gesetzlicher und tariflicher Vorgaben etc. überprüft werden. Bestehen zusätzlich Schnittstellen zum Arbeitszeitmanagement, erweitert sich das Analysespektrum, da neben Plan-Größen auch Ist-Größen des Einsatzes zur Analyse herangezogen werden können. Entsprechend kann etwa überprüft werden, welche eingeplanten Mitarbeiter aktuell nicht zur Schicht erschienen sind, welche Mitarbeiter noch erheblich unter ihrer Periodenarbeitszeit liegen, welche Mehrarbeits- und Ausfallquoten sich im Abteilungsvergleich ergeben etc. Daten des Arbeitszeitmanagements dienen so der Kontrolle der Planeinhaltung und der Verbesserung zukünftiger Einsatzpläne. Teilweise können die erforderlichen Kennzahlen auch durch automatische Prüfläufe generiert werden. Umgekehrt kann die Analysekomponente auch sinnvolle Informationen für das Arbeitszeitmanagement liefern, etwa sollte eine im Arbeitszeitmanagement stattfindende Abwesenheitsplanung sich an Bedarfen orientieren und Abwesenheiten möglichst in bedarfsarme Zeiträume gelegt werden (vgl. Scherf 2005a, 48ff.).

Dispositionskomponente

Die Dispositionskomponente dient zunächst der Anpassung und Veränderung von automatisch generierten Einsatzplänen. Da entscheidungsunterstützende Systeme menschliche Entscheidungsträger nicht ersetzen, sondern in ihrer Entscheidungsfindung unterstützen sollen, bietet sich hier entsprechenden Personaldisponenten die Möglichkeit, nach einer korrespondierenden Analyse der erzeugten Pläne notwendige »manuelle« Veränderungen vorzunehmen und so auch Aspekte zu berücksichtigen, die in den Zielen und Restriktionen der sukzessiven Planungskomponenten möglicherweise nicht abgebildet sind. Insbesondere ist es mittels der Dispositionskomponente möglich, Veränderungen der Ausgangssituation, die so kurzfristig eintreten, dass eine Neuplanung nicht mehr möglich ist, zu berücksichtigen. Wird etwa kurz vor Beginn einer Schicht die Erkrankung eines eingeplanten Mitarbeiters bekannt, ermöglicht es die Dispositionskomponente, nach geeigneten und verfügbaren Ersatzmitarbeitern zu suchen, diese zu kontaktieren und entsprechend kurzfristig einzuplanen (vgl. Scherf 2005a, 26f.). In Systemen, die nicht über alle dargestellten Einsatzplanungskomponenten verfügen, müssen Anwender über die Dispositi117

8

Personaleinsatzplanungssysteme onskomponente die nicht abgedeckten Planungsschritte wie angedeutet »manuell« bearbeiten. Dabei existieren auch Systeme, die gar keine der oben dargestellten Planungskomponenten aufweisen und entsprechend auf eine rein »manuelle« Einsatzplanung abzielen. Die Dispositionskomponente dient dann im Sinne einer »elektronischen Stecktafel« der Abbildung einer vollständig außerhalb des Systems stattfindenden Einsatzplanung.

8.2

Anwendung von Personaleinsatzplanungssystemen Personaleinsatzplanungssysteme bilden das »Paradebeispiel« entscheidungsunterstützender Systeme im Personalmanagement. Im Sinne einer »How-to-Reach«-Analyse bieten sie Anwendern umfassende Unterstützung bei der Verplanung des Personals. Die grundsätzlichen Potenziale dieser Systeme liegen zum einen in einer optimierten bzw. zumindest verbesserten Anpassung von Bedarf und Bestand, die teilweise erhebliche Kosteneinsparungen mit sich bringt (vgl. Frank & Meißer 2005, 204). Weiter dürfte auch der systematische Einbezug der – in Zukunft noch wichtiger werdenden – Mitarbeiter(einsatz)wünschen zu zwar schwerer quantifizierbaren, gleichwohl nachhaltig positiven Effekten führen.

Anwendungsbereiche

118

Personaleinsatzplanungssysteme finden ihren generellen Anwendungsbereich insbesondere in Branchen bzw. Unternehmensbereichen, die durch einen kurzfristig schwankenden und zeitnah abzuarbeitenden Bedarf sowie die Entkopplung von Betriebsund Arbeitszeit gekennzeichnet sind. Ein wesentlicher Anwendungsbereich ist entsprechend zunächst die industrielle Fertigung. Hier existieren oft stark schwankende Bedarfe bei ausgeprägter Entkopplung von Arbeits- und Betriebszeit. Sehr häufig findet sich hier auch eine Kopplung von Einsatzplanungssystem mit Produktionsplanungs- und -steuerungssystemen (PPS) (vgl. Hesseln & Zander 2005, 145f.). Ebenso sind Handel und Banken durch kurzfristig schwankenden Bedarf und zumindest teilweise Entkopplung von Betriebs- und Arbeitszeit gekennzeichnet. Einen weiteren Anwendungsbereich bildet der Sektor Transport und Verkehr, wo Einsatzpläne etwa für Flugzeug-, Bus- oder Zugbesatzungen erstellt werden. Weiter bietet insbesondere der Dienstleistungssektor mit Call Centern, Hotels, Restaurants, Wachdiensten etc. ein breit gefächertes Anwendungssegment. Korrespondierend bieten auch die (Notfall-) Dienste des öffentlichen Bereiches wie etwa Krankenhäuser, Feuerwehren, Rettungssanitäter oder die Polizei weit reichende Anwendungsmöglichkeiten. Allerdings sind alle diese Bereiche durch jeweilige Be-

8.2

Anwendung von Personaleinsatzplanungssystemen

sonderheiten gekennzeichnet. Dementsprechend richten sich angebotene Einsatzplanungssysteme sehr oft auf klar spezifizierte, enge Einsatzfelder. Daneben existiert auch parametrisierbare, branchenübergreifende Software, deren Leistungsfähigkeit in aller Regel allerdings schwächer ist (vgl. Ernst et al. 2004, 10ff.). Verbreitung und Perspektiven

Mit einem Anwendungsgrad von 24% verwendet derzeit etwa ein Viertel der deutschen Unternehmen Personaleinsatzplanungssysteme (vgl. Kabst & Giradinni 2005, 41). Unter dem (eigentlich zu weit gefassten) Begriff »Workforce Management (WFM)« wird derzeit insbesondere die integrative Zusammenfassung von Personalbedarfsplanung (vgl. Kap. 7), Personaleinsatzplanung und Arbeitszeitmanagement (vgl. Kap. 14) als zukunftsweisendes Konzept diskutiert (vgl. z.B. Brill 2005). Eine klare und einheitliche Konzeption eines Workforce Management hat sich derzeit allerdings (noch) nicht herausgebildet, und teilweise wird der Begriff auch lediglich als Aufmerksamkeit heischender Neologismus für die Personaleinsatzplanung verwendet. Aufgrund der engen Verzahnung dieser Bereiche ist deren integrative Abbildung in Informationssystemen durchaus sinnvoll, wird aber auch von verschiedenen Herstellern im Sinne modularer Architekturen (vgl. Kap. 1) durchaus schon seit längerem angeboten. Jenseits dieser Zusammenfassung einzelner Aktivitäten liegen weitere Herausforderungen der Einsatzplanung in der Integration der einzelnen dargestellten Planungsschritte, der Ausweitung bzw. Generalisierung des Anwendungsbereichs, sowie der verstärkten Berücksichtigung von Mitarbeiterpräferenzen (vgl. Ernst et al. 2004, 24).

119

9

Personalentwicklungsplanungssysteme Personalentwicklungsplanungssysteme (teilweise auch Skill Management-System, Karriere- und Nachfolgeplanungssystem, Kompetenz Management-System, »[Carreer and] Succession Planning System«) sind Anwendungen zur Unterstützung der systematischen Entwicklung von Mitarbeitern entsprechend ihrer Qualifikationen und Interessen sowie den Anforderungen im Unternehmen.

9.1

Architektur und Funktionalität von Personalentwicklungsplanungssystemen Der idealtypische Aufbau von Entwicklungsplanungssystemen beinhaltet zunächst Datenhaltungskomponenten mit MitarbeiterQualifikations- und Stellendaten, fakultativ ergänzt um Beurteilungs-, Seminar- und Laufbahndaten sowie Dateien zur Ablage von Nachfolge- und Karriereplänen. Personalentwicklungsplanungssystem Anwenderschnittstelle Analyse & Disposition

Planung (»Matching«)

Mitarbeiter

Qualifikationen

Stellen

Nachfolgepläne

Beurteilungen

Kurse

Laufbahnen

Karrierepläne

Performance Management

Learning Management

Abb. 9.1:

Idealtypische Architektur von Personalentwicklungsplanungssystemen

121

9

Personalentwicklungsplanungssysteme An funktionalen Komponenten existieren eine Planungs- sowie eine Analyse- und Dispositionskomponente (vgl. Abb. 9.1). In der Datenbankkomponente werden zum einen Stammdaten zu Mitarbeitern, Stellen, Qualifikationen bzw. Anforderungen und Laufbahnen, zum anderen die Ergebnisse zu Nachfolge- und Karriereplänen gespeichert. Über die Planungskomponente erfolgt eine Zuordnung von Stellenanforderungen und Mitarbeiterqualifikationen unter Berücksichtigung festgelegter, den Mitarbeitern zugeordneten Laufbahnen im Unternehmen zur Erstellung von Nachfolge- sowie Karriereplänen. Nachfolgepläne benennen dabei geeignete Nachfolger für vakante Positionen, Karrierepläne hingegen stellen den individuellen Entwicklungsplan eines Mitarbeiters im Unternehmen dar. Die Analyse- und Dispositionskomponente dient der Auswertung und »manuellen« Nachbearbeitung erzeugter Pläne.

9.1.1

Datenhaltungskomponenten

Qualifikationsdatei

Eine Qualifikationsdatei bezieht sich zunächst losgelöst von spezifischen Mitarbeitern und Stellen auf die strukturierte Abspeicherung sämtlicher unternehmensrelevanter Qualifikationen. Im Sinne eines strukturierten Verzeichnisses werden Qualifikationen meist in einer Baumstruktur angelegt. Neben der Bezeichnung der Qualifikation zum Beispiel »Business English« werden teils auch qualifikationsspezifische Skalen zur Wiedergabe des Niveaus der Qualifikation abgelegt. Solche Skalen sind dann qualifikationsspezifisch, wenn nicht alle Qualifikationen oder Qualifikationskategorien einer Qualifikationsdatei mit derselben Skala gemessen werden. Teils können weiter »Verlernzeiträume« im Sinne von Verfallszeiten einer Qualifikation abgelegt werden. Ebenso ist es meist möglich, Abhängigkeiten zwischen verschiedenen Qualifikationen darzustellen. Partiell können für eine Qualifikation auch mögliche Ersatzqualifikationen angegeben werden. Derartige Qualifikationsverzeichnisse dienen über die Verknüpfung mit den Mitarbeiterdaten zur Abbildung der Qualifikationsprofile der Mitarbeiter. Über Verknüpfung mit den Stellendaten können in analoger Weise auch Anforderungsprofile von Stellen gebildet werden. Die Verwendung desselben Qualifikationsverzeichnisses zur Bildung von Qualifikations- und Anforderungsprofilen erlaubt dabei den Abgleich von Mitarbeiter- und Stellenprofilen mittels der Planungskomponente.

Mitarbeiterdatei

In einer Mitarbeiterdatei werden relevante Stammdaten zur Person, wie Name, Anschrift, Ausbildung etc. abgelegt. Wichtige mitarbeiterbezogene Daten bilden weiter zunächst das Qualifika-

122

9.1

Architektur und Funktionalität von Personalentwicklungsplanungssystemen tionsprofil und damit zusammenhängend die Bildungshistorie des Mitarbeiters, die entweder über Anbindung eines Learning Management-Systems (vgl. Kap. 20) und einer entsprechenden Kursdatei oder aber direkt in den Mitarbeiterstammdaten abgelegt werden. Qualifikationsdaten beziehen sich dabei auf die Art, Umfang, »Halbwertzeit« etc. der von einem Mitarbeiter erworbenen Qualifikationen. Weitere notwendige Daten beziehen sich auf die Leistungen und Potenziale der Mitarbeiter, die entweder über Anbindung eines Performance Management-Systems (vgl. Kap. 21) und einer entsprechenden Beurteilungsdatei oder aber direkt in den Mitarbeiterstammdaten abgelegt werden. Relevante Beurteilungsdaten beziehen sich dabei insbesondere auf die Potenziale eines Mitarbeiters, neue Qualifikationen zu erwerben und neue Positionen zu übernehmen. Zusätzlich zu Qualifikations- und Leistungsdaten werden regelmäßig auch karrierebezogene Interessen bzw. Abneigungen von Mitarbeitern gespeichert. Dies bezieht sich etwa auf die Frage, ob Mitarbeiter Interessen bzw. Abneigung bezüglich eines Auslandsaufenthalts oder des Erlernens einer spezifischen Fremdsprache aufweisen. Teilweise existieren Systeme, die nicht auf alle Mitarbeiter, sondern explizit auf das Segment der Fach- und Führungskräfte ausgerichtet sind.

Stellendatei

Die Stellendatei beinhaltet neben der Bezeichnung zunächst die organisatorische Einordnung der Stelle mit Über- und Unterordnungen, Weisungsbefugnissen etc. Die Stellendatei bildet damit nicht nur einzelne Stellen, sondern die gesamte Aufbauorganisation bzw. den Stellenplan des Unternehmens ab. Bezogen auf einzelne Stellen werden die Aufgaben der Stelle und unter Rückgriff auf die Qualifikationsdatei die mit den Aufgaben korrespondierenden Anforderungen abgelegt. Mit Blick auf die Besetzung der Stelle werden weitere Aspekte wie zeitliche Gültigkeit, absehbare Vakanzzeiten, Möglichkeiten der Mehrfachbesetzung u.a.m. abgespeichert.

Laufbahndatei

Eine fakultativ verfügbare Laufbahndatei speichert zu absolvierende Stationen zur Erreichung einer bestimmten Position im Unternehmen. Laufbahnen stellen damit personenunabhängige Karrierepfade im Unternehmen dar. Dabei sind alle Laufbahnarten (Führungs-, Fach- und Projektlaufbahn) wie Laufbahnrichtungen (horizontale, vertikale und zentripetale Veränderungen) abbildbar. Zu absolvierende Stationen einer Laufbahn können dabei nicht nur aus Stellen, sondern auch aus Stellenkategorien, Entwicklungsmaßnahmen und Beurteilungen bestehen. Zunächst müssen Laufbahnpositionen nicht zwingend aus konkret vorgegebenen Stellen, sondern aus einer generellen Stellenkategorie 123

9

Personalentwicklungsplanungssysteme bestehen. Eine Stellenkategorie umfasst dabei mehrere gleichartige Stellen, wie etwa »Gruppenleiter im kaufmännischen Bereich« oder »Trainee Technik«. Das Arbeiten mit Stellenkategorien statt mit konkreten Einzelstellen erleichtert das Auffinden einer geeigneten Stelle im Rahmen des Matching. Für die Dauer der Zuordnung zu einer Stelle oder Stellenkategorie können dabei meist Minimal- und teilweise auch Maximaldauern angegeben werden. Weiter können neben Stellen und Stellenkategorien auch notwendige Entwicklungsmaßnahmen in eine Laufbahn mit aufgenommen werden, was erkennbar einen Einschluss der Weiterbildungsplanung in die Karriere- und Nachfolgeplanung darstellt. Auf diese Weise können »On-the-Job«- und »Off-the-Job«-Phasen beliebig kombiniert werden. Zusätzlich denkbare Beurteilungen ermöglichen eine begleitende Evaluation einzelner Laufbahnschritte und gestatten auch Entscheidungen über den weiteren Verbleib von Mitarbeitern. Laufbahnen können dabei linear oder auch verzweigt konzipiert werden. Gegebenenfalls bietet ein verzweigter Verlauf dann je nach aktueller Bedarfssituation unterschiedliche Möglichkeiten. Eventuell entscheiden aber auch die Ergebnisse einer vorangegangenen Beurteilungsstation über den konkreten weiteren Verlauf einer Laufbahn. Abb. 9.2 deutet eine mögliche Laufbahn in abstrahierter Form an. Stelle1 Training1 Stellenkategorie1 Beurteilung1 XOR Stelle3 Stelle2 Training2 Beurteilung2 Stelle4

Abb. 9.2: Beispiel einer Laufbahn 124

9.1

Architektur und Funktionalität von Personalentwicklungsplanungssystemen Die Laufbahndatei enthält dabei i.d.R. mehrere unterschiedliche Laufbahnen für verschiedene Mitarbeitersegmente, die im Rahmen des Customizing unternehmensindividuell erstellt werden können. Entsprechend kann einem Mitarbeiter für Planungszwecke eine oder mehrere Laufbahnen zugewiesen werden.

Karriereplandatei Eine Karriereplandatei nimmt individuelle Karrierepläne als Ergebnis eines »Matching« mit der Planungskomponente auf. Analog zu Laufbahnen bestehen individuelle Karrierepläne aus verschiedenen Stationen, d.h. Stellen(-kategorien), Entwicklungsmaßnahmen und Beurteilungen, die ein Mitarbeiter im Zeitablauf durchlaufen soll. Allerdings sind sie konkretisiert und individuell einem Mitarbeiter zugeordnet. Werden Laufbahnen im Rahmen des Matchings genutzt, basieren individuelle Karrierepläne auf der einem Mitarbeiter zugeordneten Laufbahn. Dabei können Laufbahnen unverändert übernommen oder auch individuell an den Mitarbeiter angepasst werden. Im Unterschied zu Laufbahnen sind Karrierepläne auch dynamisch, d.h. sie können bei Veränderungen im Zeitablauf – wie etwa veränderten Interessenlagen eines Mitarbeiters – nach und nach angepasst werden. Da ein Karriereplan ausdrücklich auch künftige Entwicklungsmaßnahmen vorwegnimmt, ist die Weiterbildungsplanung ein Bestandteil der Karriereplanung. Nachfolgeplandatei

Korrespondierend mit der Karriereplandatei enthält eine Nachfolgeplandatei die bedarfs- und eignungsabhängigen Versetzungsmöglichkeiten von Mitarbeitern im Unternehmen. Nachfolgepläne stellen demnach sicher, dass versetzungs-, fluktuations- oder ruhestandsbedingte Vakanzen zeitnah einer qualifizierten Wiederbesetzung zugeführt werden können. Nachfolgepläne korrespondieren damit eng mit den in den individuellen Karriereplänen festgelegten Versetzungspositionen einzelner Mitarbeiter. Nachfolgepläne sind allerdings mehr als bloße Aggregationen individueller Versetzungsplanungen, da es Aufgabe der Nachfolgeplanung ist, aus Sicht des Unternehmens die adäquate Besetzung relevanter Stellen jederzeit sicherzustellen. Entsprechend sind ausgehend von einer oder mehreren vakanten Stellen geeignete Kandidaten als Nachfolger einzuplanen. Dass die Verplanung eines (internen) Mitarbeiters auf eine vakante Stelle stets eine neue Vakanz zur Folge hat, bedingt den so genannten »Dominoeffekt«. Ein Nachfolgeplan für eine vakante Stelle besteht damit im einfachsten Fall aus einer Versetzungskette, die sicherstellt, dass nicht nur die fragliche Originärvakanz, sondern auch alle Folgevakanzen gedeckt werden können. Da für eine zu besetzende Vakanz i.d.R. unterschiedliche Nachfolgeszenarien möglich sind, 125

9

Personalentwicklungsplanungssysteme besteht ein Nachfolgeplan meist aus mehreren alternativen Versetzungsketten. Abb. 9.3 deutet eine Nachfolgeplanung für eine in der ersten Hierarchieebene eines Unternehmens entstehende Vakanz an. Organisationsstruktur Ebene1

Ebene2

Ebene3

...

Dr. Müller

Kunz

Lohmann

...

v. Ahlsleben

Meier, B.

Kolte

...

Dr. Herrmann

Meier, M.

Böller

...

Heidenreich

Schmitt

Dussek

...

...

...

...

...

Neueinstellung

Neueinstellung

Neueinstellung

...

Alternative1 Alternative2 Alternative3

Abb. 9.3: Nachfolgeplan Umfangreichere Systeme können dabei – anders als in Abb. 9.3 – nicht nur für die Originär-, sondern auch für die Folgevakanzen mehrere unterschiedliche Nachfolgeszenarien berücksichtigen und verplanen gleichzeitig auch mehr als eine Originärvakanz. Entsprechend können Nachfolgepläne aus zahlreichen alternativen, sich überscheidenden Versetzungsketten bestehen und von erheblicher Komplexität sein.

9.1.2

Planungskomponente Grundsätzlich dient die Planungskomponente der möglichst guten Zuordnung von Mitarbeitern zu Stellen (»Matching«). Umfang und Methodenunterstützung eines Matchings fallen dabei je nach System unterschiedlich aus. Grundsätzlich unterscheiden sich vorfindbare Matchingkomponenten nach ƒ der Anzahl simultan möglicher Zuordnungspaare, ƒ der Anzahl zeitlich sukzessiver Zuordnungsvorgänge, ƒ der Art und Anzahl möglicher Zuordnungskriterien und ƒ der Art der Unterstützung der Zuordnung.

Zuordnungspaare 126

Die Planungskomponente zielt auf Zuordnung von Mitarbeitern und Stellen. Nach der Anzahl simultan möglicher Zuordnungs-

9.1

Architektur und Funktionalität von Personalentwicklungsplanungssystemen paare lassen sich Systeme, die Einzelzuordnungen ermöglichen, von Systemen unterscheiden, die simultan vollständige Versetzungsketten bearbeiten können. Im einfachsten Fall bestehen Zuordnungsmöglichkeiten im System lediglich für jeweils einen Mitarbeiter und eine Stelle, d.h. genau ein Matchingpaar. Im Sinne einer Partialplanung wird damit stets nur ein Teilproblem berücksichtigt. Der angesprochene Dominoeffekt und das daraus resultierende Problem der Planung ganzer Versetzungsketten muss vom Anwender dann »manuell« abgebildet werden, indem Folgevakanz für Folgevakanz »manuell« abgearbeitet wird. Komfortabler sind daher Systeme, die das Problem des Dominoeffektes ausdrücklich aufgreifen und die Planung kompletter Versetzungsketten, d.h. simultan mehrere Matchingpaare, unterstützen und dabei auch mehrere Originärvakanzen berücksichtigen können. Solche Systeme zielen im Sinne einer Totalplanung auf eine ganzheitliche Abbildung des Planungsproblems. Sie verlagern damit Planungskomplexität vom Anwender in das System.

Zuordnungsvorgänge

Planungskomponenten unterscheiden sich weiter nach der Anzahl zeitlich aufeinander folgender Zuordnungsvorgänge von Mitarbeitern zu Stellen. Als Minimalvariante können Matchingkomponenten jeweils den nächsten anstehenden Zuordnungsbzw. Versetzungsvorgang vorwegnehmen. Teilweise können aber auch – wie von den Laufbahnen impliziert – mehrere zeitlich aufeinander folgende Versetzungsvorgänge vorweggenommen werden. Aus Sicht der individuellen Karriereplanung und der damit angestrebten Bindungs- und Motivationswirkung auf einzelne Mitarbeiter ist eine solche mittel- bis längerfristige Planung über mehrere Versetzungspositionen hinweg durchaus sinnvoll. Allerdings erhöht dies die Komplexität – insbesondere der Nachfolgeplanung – erheblich. Weiter sinkt mit der Ausdehnung des Planungszeitraums und den in mittlerer bis längerer Frist oft zahlreichen Veränderungen im Stellengefüge und im Mitarbeiterbestand auch die Planungsgüte. Aufgrund solcher Veränderungen nicht einhaltbare Karrierepläne dürften entsprechend nachteilige Effekte auf die Motivation und Bindung haben. Unabhängig von der Zahl sukzessiver geplanter Versetzungspositionen gestaltet sich die Personalentwicklungsplanung damit erkennbar als mittelfristige Planungsaufgabe.

Zuordnungskriterien

Die Planungskomponenten vorfindbarer Systeme unterscheiden sich weiter nach den für eine Zuordnung anwendbaren Kriterien. Die durchaus verbreitete Minimalvariante besteht darin, auf Mitarbeiterseite Qualifikationen und auf Stellenseite Anforderungen als Zuordnungskriterien heranzuziehen. Da für eine umfas127

9

Personalentwicklungsplanungssysteme sende Personalentwicklungsplanung weitere Aspekte relevant sind, ermöglichen umfassendere Systeme die Berücksichtigung weiterer Kriterien. Eine erste Erweiterung der reinen Qualifikations- und Anforderungssicht besteht in der zusätzlichen Berücksichtigung der Potenziale eines Mitarbeiters. Damit verbreitert man mögliche Entwicklungen auch auf Stellensegmente, für die aktuell keine Qualifikationen vorliegen, die aber aufgrund des Potenzials entwickelt werden könnten. Weiter können teilweise auch Wünsche und Abneigungen von Mitarbeitern berücksichtigt werden. Etwa kann so der Wunsch nach einem Auslandseinsatz oder die Abneigung, eine spezifische Fremdsprache zu erlernen, mit in die Entwicklungsplanung aufgenommen werden. Schließlich bilden dem Mitarbeiter zugeordnete Laufbahnen ein weiteres mögliches Matchingkriterium. Hält man festgelegte Laufbahnen im oben beschriebenen Sinne für sinnvoll, dann kann die Zuordnung von Mitarbeitern zu Stellen auch danach erfolgen, ob die Vorgaben einer oder mehrerer zugeordneter Laufbahnen eingehalten werden. Weitere mögliche Kriterien können im Erreichen eines gewissen Beurteilungsergebnisses, der Zustimmung zu einer spezifischen Versetzung durch den Vorgesetzten u.a.m. bestehen. Eine solche, über bloße Qualifikationen und Anforderungen hinausgehende Berücksichtigung von Kriterien im Rahmen des Matching verbessert ohne Frage die Güte der entsprechenden Entwicklungspläne. Allerdings sinkt mit steigender Anzahl berücksichtigter Matchingkriterien auch die Wahrscheinlichkeit, geeignete Zuordnungen überhaupt vornehmen zu können. In Anbetracht dieses Problems findet sich auch die Möglichkeit aus allen verfügbaren Kriterien eine Teilmenge einzubeziehender Kriterien auszusuchen.

Unterstützung der Planung

128

Die Art der Planungsunterstützung zielt auf die implementierten Methoden. Grundsätzlich kann hier zwischen der Unterstützung eines »manuellen« Matching durch den Anwender und einem automatisierten Matching durch das System (mit »manuellen« Nachbesserungsmöglichkeiten durch den Anwender) unterschieden werden. Im Rahmen einer »manuellen« Zuordnung durch den Anwender wird der Anwender insbesondere informationell unterstützt. Erste Unterstützungsmöglichkeiten bestehen etwa in datenbanktypischen Suchmöglichkeiten im Sinne einer Auswahlabfrage auf die Datenkomponenten nach Mitarbeitern oder Stellen, die gewisse Kriterien erfüllen (vgl. auch Kap. 4). Regelmäßig bieten weiter auch Profilvergleiche von Stellen und Mitarbeitern mit Blick auf die Matchingkriterien Qualifikationen und Anforderungen einen einfachen Überblick über Eignungen von Mitarbeitern.

9.1

Architektur und Funktionalität von Personalentwicklungsplanungssystemen Abb. 9.4 deutet den Abgleich einer Stelle mit zwei Mitarbeitern an. Qualifikation

1

2

3

4

5

IT Betriebsysteme IT Programmierung IT Datenbanken Sprachen Englisch Sprachen Französisch Sprachen Spanisch ... Profil Stelle1 Profil Mitarbeiter1 Profil Mitarbeiter2

Abb. 9.4: Profilvergleich Auf der Basis solcher Informationen muss die Zuordnung von Mitarbeitern und Stellen durch den Anwender erfolgen. Da die Art der Unterstützung letztlich auf reinen Auswertungsfunktionalitäten beruht und die anschließende Zuordnung »manuell« erfolgt, fällt die Planungskomponente in diesem Fall mit der Analyse- und Dispositionskomponente zusammen. Automatisierte Varianten des Matching versuchen systemgestützte Vorschläge für Karriere- und Nachfolgepläne zu erzeugen. Dazu sind von den eingesetzten Matchingalgorithmen zwei Aufgaben zu lösen. Zunächst ist die generelle Eignung zu bestimmen, d.h. die Frage zu beantworten, welcher Mitarbeiter für welche Stelle in Frage kommt. Anschließend ist eine geeignete Zuordnung von Mitarbeitern zu Stellen vorzunehmen. Die Bestimmung der Eignung erfolgt dabei oft über die Berechnung von Eignungswerten, die die Tauglichkeit eines Mitarbeiters für eine bestimmte Stelle aufzeigen (vgl. Scholz 2000, 650ff.). Grundsätzlich lassen sich dabei Verfahren mit und ohne Kompensationsmöglichkeiten unterscheiden. Liegen Kompensationsmöglichkeiten vor, können nicht erfüllte Anforderungen durch das Übererfüllen anderer Anforderungen kompensiert werden. Eignungswerte werden teilweise als Abstandsmaß berechnet, das aus einer Aggregation der Abstände zwischen Qualifikation und Anforderungen, wie z.B. die euklidische Distanz. Teilweise werden auch 129

9

Personalentwicklungsplanungssysteme Verlaufsmaße eingesetzt, die auf einen möglichst ähnlichen Verlauf von Qualifikations- und Anforderungsprofil abzielen. Eine dritte Variante besteht aus Binärmaßen, die dem Mitarbeiter dann einen Eignungswert von »1« zuweisen, wenn er alle Anforderungen mindestens erfüllt, während andernfalls der Eignungswert »0« zugewiesen wird. Teilweise werden auch kombinierte Maße zur Berechnung eines Eignungswertes eingesetzt. So berechnete Eignungswerte werden dann für eine automatisierte Zuordnung von Mitarbeitern zu Stellen verwendet. Die damit angedeutete Zuordnungsaufgabe lässt sich dabei als Optimierungsproblem modellieren, bei dem der Gesamteigungswert der zu maximierende Zielwert ist, während weitere Zuordnungskriterien wie zugeordnete Laufbahnen, Interessen, Abneigungen etc. sowie die lediglich einmalige Zuordnung eines Mitarbeiters zu einer Stelle und die Besetzung jeder Stelle mit genau einem Mitarbeiter Restriktionen des Optimierungsproblems darstellen. Die Lösung des Zuordnungsproblems erfolgt dann über den Einsatz von Optimierungs- bzw. aufgrund von Komplexitätsproblemen auch von Approximationsalgorithmen (vgl. dazu die Darstellungen in Kap. 8). Dabei gilt, dass mit zunehmender Zahl von Zuordnungskriterien die Problemkomplexität zu- und die Möglichkeit, eine optimale oder zulässige Lösung zu finden, abnimmt. Auf diese Weise können automatisierte Karriere- und Nachfolgepläne erzeugt werden, die in den entsprechenden Dateien abgelegt werden. Bestehen nach einem Matching Qualifikationsdefizite von zugeordneten Mitarbeitern und/oder wurden Laufbahnen verwendet, die konkrete Entwicklungsmaßnahmen vorsehen, dann können auch Weiterbildungspläne als Teilpläne der Karriereplanung automatisiert abgeleitet werden.

9.1.3

Analyse- und Dispositionskomponente Eine Analyse- und Dispositionskomponente dient der Auswertung und manuellen Nachbearbeitung erstellter Karriere- und Nachfolgepläne. Über die Analysekomponente können vielfältige Auswertungen und Berichte zur Entwicklungsplanung generiert werden. Die Analysekomponente greift dabei insbesondere auf die Nachfolge- und Karrierepläne zu und liefert u.a. Informationen zum Weiterbildungsbedarf, zum Stand der Entwicklung von Mitarbeitern gemäß Laufbahnvorgabe, zu anstehenden Versetzungen etc. Generell bietet die Analysekomponente damit umfangreiche personalentwicklungsbezogene Informationen. Insbesondere bei automatisiert erzeugten Entwicklungsplänen erlaubt die Dispositionskomponente nachträgliche individuelle Abände-

130

9.2

Anwendung von Personalentwicklungsplanungssystemen

rungen, wie sie etwa nach Mitarbeiterentwicklungsgesprächen, kurzfristigen entstandenen Versetzungsbedarfen etc. notwendig werden.

9.2

Anwendung von Personalentwicklungsplanungssystemen Eine umfassende und systematische Entwicklungsplanung profitiert in erheblichem Maße von einer Systemunterstützung. Bereits bei mittlerer Unternehmensgröße sind Profilvergleiche und die Erstellung von komplexen Nachfolgeplänen unter simultaner Berücksichtigung von Qualifikationen, Anforderungen, Interessen, Potenzialen, Abneigungen, Laufbahnen etc. ohne ein entsprechendes Entwicklungsplanungssystem kaum oder nur mit unverhältnismäßig großem Aufwand manuell möglich. Neben der Sicherstellung einer nachhaltigen, qualitativ hochwertigen Besetzung von Stellen, dürfte insbesondere die Attraktions-, Bindungsund Motivationswirkung einer transparenten, kommunizierten Personalentwicklungsplanung weitere wesentliche Potenziale für das Personalmanagement bieten. Allerdings impliziert die Anwendung einen aktuellen und validen Bestand an Qualifikationsund Stellendaten sowie ggf. weiterer Daten, dessen Gewährleistung i.d.R. mit erheblichem Aufwand verbunden ist. Weiter birgt ein »Matching« gewisse methodische Probleme, wie etwa die Merkmalsauswahl oder die anzuwendende konkrete Messmethode im Bereich der Arbeitsanalyse und Eignungsdiagnose (vgl. Scholz 2000, 653f.). Insbesondere bei der Besetzung exponierter Führungspositionen auf höherer Hierarchiestufe dürften faktisch in den Systemen nicht berücksichtigte Kriterien wie interne und externe Netzwerke eine erhebliche Rolle spielen.

Verbreitung

Derzeit betreiben rund 30% der deutschen Unternehmen und Organisationen eine informationssystembasierte Personalentwicklungsplanung (vgl. Kabst & Giradinni 2005, 41).

131

10

Personalkostenplanungssysteme Personalkostenplanungssysteme (Personalkostenmanagementsysteme) sind Anwendungen zur Unterstützung des Personalmanagements bei der Prognose und Analyse von Personalkosten.

10.1

Architektur und Funktionalität von Personalkostenplanungssystemen Personalkostenplanungssysteme weisen neben der obligatorischen Anwenderschnittstelle üblicherweise eine Datenbankkomponente mit Grunddaten, Kostenplänen und Kontrolldaten sowie eine Planungs-, Administrations- und Analysekomponente auf (vgl. Abb. 10.1). Personalkostenplanungssystem Anwenderschnittstelle

Data Warehouse Bedarfsplanung Abrechnung

Planung

Administration

Analyse

Eingangsdaten

Kostenpläne

Kontrolldaten

Abb. 10.1: Idealtypische Architektur von Personalkostenplanungssystemen Eine Datei mit Eingangsdaten enthält zunächst den notwendigen Input an Planungsstammdaten. Eine Planungskomponente stellt dann Methoden zur Erzeugung der Prognosedaten bereit. So erstellte Kostenpläne werden in einer Kostenplandatei abgelegt. Eine Administrationskomponente unterstützt die arbeitsteilige Erstellung von Personalkostenplänen. Im weiteren Verlauf werden Ist-Kostendaten insbesondere aus der Abrechnung auch als Kontrolldaten bezüglich der Einhaltung der Kostenpläne benötigt. Eine Analysekomponente dient der Auswertung verschiedener Kostenpläne sowie dem Vergleich von Soll- und Ist-Kosten. 133

10

Personalkostenplanungssysteme

10.1.1

Datenhaltungskomponente Art und Umfang der Datenhaltungskomponente variieren mit der konkreten Ausgestaltung der Planungskomponente. Dabei bestimmen insbesondere die Planungsmethode und die beplanbaren organisatorischen Ebenen die Ausgestaltung der Datenhaltung. Unabhängig hiervon kann generell zwischen Eingangs-, Ergebnis- und Kontrolldatenbeständen einer Personalkostenplanung unterschieden werden.

Eingangsdaten

134

Eingangsdaten sind die für die Durchführung einer Planung notwendigen Grunddaten. Diese können entweder aus Vorsystemen, insbesondere Data Warehouse-Systemen (vgl. Kap. 5), Personalabrechnungssystemen (vgl. Kap. 13) oder Personalbedarfsplanungssystemen (vgl. Kap. 7) übernommen werden oder sind manuell einzupflegen. Solche Inputdaten variieren in Abhängigkeit von der methodischen Umsetzung der Planungskomponente. Bei der Realisierung von Hochrechnungen bilden i.d.R. Mitarbeiter- und/oder Stellenstammdaten, Daten zur Organisationsstruktur sowie relevante Kostenarten zentrale Eingangsdaten. Alternativ oder additiv zu aktuellen Daten werden teilweise auch Daten aus Vormonaten oder arithmetische Mittel aus mehreren Vormonaten als Inputdaten verwendet. Neben solchen Ist-Daten werden regelmäßig auch Daten zu absehbaren künftigen Veränderungen benötigt und daher zusätzlich aufgenommen. Dies betrifft etwa Ein- und Austritte von Mitarbeitern bzw. Schaffung oder Streichung von Stellen sowie damit einhergehende Veränderungen der Organisationsstruktur ebenso wie absehbare Veränderungen einzelner Kostenarten wie etwa Veränderung der tariflichen Grundentlohnung oder der Beitragssätze für Krankenkassen. Bei Verwendung der Zeitreihenanalyse sind insbesondere Zeitreihen, also zeitabhängige Folgen von Kostendaten, als Eingangsdaten notwendig. Dies betrifft regelmäßig die Zeitreihen mit Vergangenheitsdaten einzelner zu verplanender Kostenarten je Mitarbeiter, Stelle, Organisationseinheit und/oder Kostenstelle. Entsprechend dienen hier historisierte Kostendatenreihen als Inputdaten. Bei Verwendung der Simulation bilden ebenfalls IstKostendaten notwendige Inputgrößen für die Planungskomponente. Darüber hinaus verwenden Simulationsmodelle auch Daten zu Größen, die Personalkosten determinieren. Je nach Simulationsmodell sind dies zunächst die Zahl der Mitarbeiter bzw. der Full Time Equivalents (FTE’s). Weiter werden auch die Determinanten des Mitarbeiterbestands im Sinne personalbedarfsdeterminierender Größen (vgl. auch Kap. 7) zur Durchführung von Simulationen benötigt.

10.1 Architektur und Funktionalität von Personalkostenplanungssystemen Kostenplandaten

Die Ergebnisse der Planungen mit der Planungskomponente werden in einer eigenen Datenhaltungskomponente niedergelegt. Im Ergebnis besteht ein Kostenplan dabei aus einer zukunftsgerichteten Zeitreihe von Kosten. Diese Kosten werden dabei i.d.R. als einzelne Kostenarten und als Gesamtkosten dargestellt. Weiter werden i.d.R. sowohl individuelle Kosten je Planungszeiteinheit als auch über die Planungszeiteinheiten des Planungszeitraumes kumulierte Kosten gespeichert. Die Darstellungsform der Kostenpläne ist sowohl tabellarisch als auch grafisch möglich. In den meisten Fällen können dabei mehr als ein Plan je Planungszeitraum abgelegt werden. Diese Abspeicherung von Alternativplänen ermöglicht eine szenario-orientierte Planung.

Kontrolldaten

Kontrolldaten sind Ist-Daten aus der Personalabrechnung, die während des Ablaufs des Planungszeitraumes sukzessive hochgeladen werden. Diese Ist-Daten dienen der Kontrolle der Planeinhaltung durch kontinuierliche Plan-Ist-Vergleiche. Entsprechend müssen Daten korrespondierend zu den verplanten Kostenarten und Planungsebenen vorgehalten werden.

10.1.2

Planungskomponente Die Planungskomponente bildet den zentralen methodischen Kern eines Personalkostenplanungssystems. Unter Verwendung der entsprechenden Eingangsdaten werden hier die konkreten Prognosewerte für einzelne Kostenarten generiert. Die Planungskomponenten unterscheiden sich dabei nach ƒ Planungszeitraum und -rasterung, ƒ Planungskostenarten, ƒ Planungsebenen, ƒ Planungsmethoden und ƒ Planungswährungen.

Zeitraum und Zeitrasterung

Der Zeitraum einer Planung (Planungshorizont) betrifft die Zeitspanne, die ein System maximal verplanen kann. Die Zeitrasterung bezieht sich auf mögliche Unterteilungen des Planungszeitraums in kleinere zu verplanende Zeiteinheiten. Wegen der inzwischen meist monatlich erfolgenden Abrechnungen und korrespondierender Auszahlungen wird diese Zeiteinheit meist auf einen Monat festgelegt. Teilweise sind zusätzlich auch andere Rasterungen möglich. Die Kostenplanung erfolgt dann meist zunächst für eine solche Basiszeiteinheit. Der Planungszeitraum wird dann durch die Zusammenstellung entsprechender Basiszeiteinheiten realisiert. Dabei können solche Folgen von Basis135

10

Personalkostenplanungssysteme zeiteinheiten homogen oder heterogen beplant werden. Im Falle homogener Folgen sind die Kostenpläne jeder Basiszeiteinheit gleich. Bei heterogenen Folgen existieren abweichende Basiszeiteinheiten in einer Folge, etwa wenn im Monat November die einmalige Auszahlung eines Weihnachtsgelds erfolgt. Durch dieses Vorgehen der Abbildung von Planungszeiträumen als Folge von Basiszeiteinheiten sind meist beliebige Planungszeiträume beplanbar. Entsprechend sind meist auch mittel- und langfristige Personalkostenplanungen möglich.

Kostenarten

Weiter existieren gewisse Unterschiede bezüglich der einzelnen Personalkostenarten, die im System verplant werden können. Personalkosten können dabei unterschiedlich gegliedert werden. Verbreitet ist die Unterscheidung von direkten und indirekten Personalkosten. Unter direkten Kosten werden diejenigen Kosten verstanden, die für den Einsatz eines Mitarbeiters unmittelbar anfallen. Dies sind verschiedene Entgeltformen und Personalnebenkosten (Personalzusatzkosten). Kosten der Durchführung personalwirtschaftlicher Funktionen, teilweise auch der Mitbestimmung, gelten dagegen als indirekte Personalkosten (vgl. Henselek 2004). Folgt man dieser Zweiteilung, wird durch derzeitige Systeme insbesondere die Planung direkter Personalkosten unterstützt (vgl. Abb. 10.2).

Personalkosten

Direkte Personalkosten

Personalgrundkosten

Personalnebenkosten

(Netto-)Löhne

gesetzlich

(Netto-)Gehälter

tariflich

Indirekte Personalkosten

Personalarbeitskosten

Mitbestimmungskosten

betrieblich

Abb. 10.2: Kostenarten der Personalkostenplanung Regelmäßig geplant werden können die direkten Personalgrundkosten. Dies betrifft das direkte Entgelt in Form von (Netto-)Löhnen bzw. (Netto-)Gehältern. Ebenso finden die Personalnebenkosten gewöhnlich eine Abbildung in Personalplanungssystemen. 136

10.1 Architektur und Funktionalität von Personalkostenplanungssystemen Dies betrifft zunächst die gesetzlichen Bestandteile, insbesondere die Arbeitgeber- und Arbeitnehmeranteile an den Sozialversicherungen. Ebenso können tarifliche Kostenbestandteile wie Urlaubsgeld, Gratifikationen oder Zulagen nach Maßgabe individueller Tarifverträge geplant werden. Werden auf betrieblicher Basis freiwillig weitere Entgeltbestandteile gewährt, können auch diese in die Kostenplanung aufgenommen werden. Neben Systemen, die eine gewisse Kategorisierung direkter Kosten vorgeben, existieren auch Systeme, die im Rahmen der Implementierung eine freie Bestimmung zu verplanender (direkter) Kostenarten ermöglichen. Entsprechend können häufig zahlreiche direkte Personalkostenarten in beliebiger Kategorisierung verplant werden. Voraussetzung dabei ist, dass entsprechende Eingangsdaten zu den Kostenarten vorliegen. Soll ein umfassenderes Kostenmanagement stattfinden, sind entsprechend auch korrespondierende Kontrolldatenstrukturen notwendig. Im Unterschied zu den direkten Personalkosten können Kosten der Personalarbeit, also etwa Kosten für künftige Personalentwicklung, dagegen in gegenwärtigen Kostenplanungssystemen meist nicht berücksichtigt werden. Gewisse Möglichkeiten bieten hier funktional orientierte Anwendungssysteme, wie mit Blick auf die Entwicklungskosten etwa Learning Management-Systeme (vgl. Kap. 20). Ebenso müssen eventuelle Kosten der Mitbestimmung regelmäßig anderweitig gemanagt werden. Planungsebenen

Personalkostenplanungen können meist alternativ bezogen auf verschiedene, teils aufeinander aufbauenden Ebenen durchgeführt werden. Auf der Mikroebene bezieht sich die Planung auf Kosten, die einzelne Mitarbeiter oder Stellen verursachen. Um Unterschiede zwischen Soll-Kosten einer Stelle und faktischen Ist-Kosten von Mitarbeitern zu berücksichtigen, existieren auch Systeme, die Kosten für beide Objekte verplanen. Entsprechend werden hier in detaillierter Weise Kostenarten auf individueller Ebene geplant. Teilweise werden aus Aufwandsgründen allerdings auch Kategorien vergleichbarer Mitarbeiter und/oder Stellen gebildet. Auf der Mesoebene kann sich die Planung auf die Kosten einzelner Organisationseinheiten und/oder Kostenstellen nach Kostenstellenplan beziehen. Sind Planungen bereits auf der Mikroebene erfolgt, kann die Mesoebene etwa über die Zuordnung von Mitarbeitern und/oder Stellen zu Organisationseinheiten und/oder Kostenstellen erkennbar über eine Aggregation erfolgen. Allerdings existieren auch Systeme, die erst auf Mesoebene aufsetzen. Korrespondierend ergibt sich dann die Personal-

137

10

Personalkostenplanungssysteme kostenplanung für die Makroebene des Unternehmens durch Aggregation. Zentral für die Ergebnisse jeder Kostenplanung ist die methodische Umsetzung der Generierung von Prognosedaten. Mit Hochrechnungen und seltener auch Zeitreihenanalysen sowie Simulationen lassen sich drei grundsätzliche Ansätze unterscheiden. I.d.R. wird dabei lediglich eine der Methodengruppen angeboten.

Planungsmethoden

Die gebräuchlichste methodische Variante stellen Hochrechnungen der Personalkosten dar. Hochrechnungen basieren dabei auf Modellen, die Kosten nach Kostenart, Planungsebene und Basiszeiteinheit darstellen, wie in Abb. 10.3 für die Ebene der Mitarbeiter angedeutet. Analoge Hochrechnungen sind auch für Stellen, Organisationseinheiten oder Kostenstellen möglich.

Nebenkosten

Grundkosten

Basiszeiteinheit1 Mitarbeiter1

Mitarbeiter2

Kostenart1

k11

k21

Kostenart2

k12

Kostenart3

k13

Kostenart...

Mitarbeiter3 Mitarbeiter... k31

k..1

...

k32

k..2

...

k22

k33

k2..

k3..

Kostenart7

k17

k27

Kostenart8

k18

k28

k38

Kostenart9

k19

k29

k39

Kostenart...

k1..

6

...

...

6

... k....

...

k..7

...

k..8

... ...

k3...

k....

...

...

....

...

Abb. 10.3: Basisdaten modellbasierter Hochrechnung Fixe Kostenarten werden dabei direkt aus der Abrechnung übernommen. Variable Kostenarten, wie sie speziell durch leistungsorientierte Entgeltformen entstehen, werden dabei häufig mit einem Mittelwert mehrerer Vorperioden angesetzt. Teils können auch Schätzwerte eingegeben werden. In seltenen Fällen ist auch die systemseitige Generation von Zufallszahlen innerhalb vorgegebener Intervalle möglich. Die Plankosten einer Kostenart ergeben sich dann als Summe dieser Kostenart über alle Mitarbeiter. Analog ergeben sich die Plankosten je Mitarbeiter als Summe der 138

10.1 Architektur und Funktionalität von Personalkostenplanungssystemen

BZE1

BZE1

BZE1

BZE1

BZE1

BZE1

BZE1

BZE1

2

3

4

5

6

7

8

9

10

11

BZE1

BZE1

1

BZE2

BZE1

Kosten über alle Mitarbeiter. Entsprechend werden die Gesamtkosten je Basiszeiteinheit als Summe über alle Kostenarten und alle Mitarbeiter berechnet. Existieren im Zeitablauf Perioden mit unterschiedlichen Kostenstrukturen, so sind verschiedene Basiszeiteinheiten sowie deren zeitliche Abfolge im Planungszeitraum anzugeben. Beispielsweise kann die einmal jährlich stattfindende Auszahlung von Weihnachtsgeld durch eine Folge von elf »normalen« Monaten und einem »Weihnachtsgeld«-Monat abgebildet werden (vgl. Abb. 10.4).

...

12

...

t

Planungszeitraum

Abb. 10.4: Abbildung des Planungszeitraums durch Basiszeiteinheiten Analoges gilt für absehbare Änderungen im Planungszeitraum. Ändern sich einzelne Kostenarten im Planungszeitraum, etwa die Krankenkassenbeiträge durch eine Beitragssatzänderung, dann sind für die Zeit vor und nach der Änderung zwei Basiszeiteinheiten vorzusehen und entsprechend anzuordnen. Ändert sich die Mitarbeiterstruktur durch Ein- und Austritte, ist auch dies in entsprechenden Basiszeiteinheiten umzusetzen. Die Güte einer hochrechnungsbasierten Personalkostenplanung hängt damit erkennbar besonders von der zutreffenden Einschätzung solcher künftigen Veränderungen ab. Einige Systeme verwenden Methoden der Zeitreihenanalyse, um die Erkennung einer generellen Entwicklung (»Trend«) in den Personalkosten für die Prognose künftiger Werte heranzuziehen. Notwendige Eingangsdaten sind dabei Zeitreihen der zu verplanenden Kostenarten, also zeitabhängige Folgen historischer Kostendaten. Das so erhobene Verlaufsmuster von Kostendaten wird dabei je nach eingesetztem Verfahren in mehrere Komponenten zerlegt. Die zentral interessierende Trendkomponente gibt dabei die allgemeine Grundrichtung der Zeitreihe an. Daneben können zeitliche Einflüsse in Form von saisonalen (unterjährigen) und zyklischen (mittelfristigen) Schwankungen berücksichtigt werden. Regelmäßig werden auch zufällige Schwankungen berück139

10

Personalkostenplanungssysteme sichtigt. Neben einfacheren Methoden, die einen linearen Verlauf des Trends unterstellen, können teils auch progressive oder degressive Trendverläufe erkannt werden (vgl. etwa Kirchgässner & Wolters 2006). Grundsätzlich wird die erkannte Trendkomponente dann auf den gesamten Planungszeitraum fortgeschrieben. Abb. 10.5 deutet eine sechsmonatige univariate Zeitreihe von IstKostendaten an, deren linearer Trend für den Planungszeitraum eines weiteren halben Jahres hochgerechnet wird. 39.000

Ist-Daten

Plan-Daten

Kosten [€]

38.000 37.000 36.000 35.000 34.000 33.000 1

2

3

4

5

6

7

8

9

10

11

12

Zeit [Monate]

Abb. 10.5: Kostenplanung mittels Zeitreihenanalyse Aufgrund der Basierung auf Vergangenheitsdaten können bekannte zukünftige Veränderungen im Unterschied zu Hochrechnungen nicht berücksichtigt werden. Wegen ihrer generellen Vorgehensweise eignen sich Trendverfahren weiter insbesondere für Kostenplanungen auf Meso- und Makroebene. Auf der Ebene individueller Kosten wird man Zeitreihenanalysen dagegen schon aus Aufwandsgründen kaum flächendeckend anwenden können. Simulation

140

Einige Systeme verwenden auch die Simulation zur Generierung von Prognosedaten. Aufgrund der Aufgabenstellung eignen sich insbesondere gleichungsbasierte Simulationsverfahren (vgl. Troitzsch 2004) zur Anwendung im Rahmen einer Personalkostenplanung. Abb. 10.6 deutet ein einfaches Grundmodell der Simulationsmethode System Dynamics an.

10.1 Architektur und Funktionalität von Personalkostenplanungssystemen

Austritte EG1

Eintritte EG1

Austritte EG2

Eintritte EG2

5

654

PersonalVeränderung bestand EG1 EG1

-3

715

1.002.321

50.234.278

Kumulierte Personal- Personalkosten kosten

PersonalVeränderung bestand EG2 EG2

Abb. 10.6: Simulationsmodell zur Personalkostenplanung Dabei werden gegenwärtige Personalbestände und stochastische künftige Ein- und Austritte in zwei Einkommensgruppen (EG) zur Grundlage der Prognose von zeiteinheitsbezogenen und kumulierten Personalkosten des Planungszeitraums verwendet. Die zugrunde liegenden Simulationsmodelle sind allerdings bereits erstellt und bleiben für den Anwender i.a.R. verborgen. Eigene Modellierungen der entsprechenden Planungssituation sind daher nicht nötig bzw. möglich. Daher spezifiziert der Anwender über entsprechende Masken lediglich relevante Eingabeparameter wie Ist-Personalbestand und bekannte Intervalle für Ein- und Austritte innerhalb einer Planungszeiteinheit. Als Ausgabe erhält er dann individuelle und kumulierte Kosten je Zeiteinheit in tabellarischer und grafischer Form. Aufgrund ihrer eher aggregierten Ausrichtung eignet sich auch die Simulation eher für die Meso- und Makroebene der Personalkostenplanung. Währungen

Insbesondere für den Einsatz in internationalen Unternehmen spielen die verwendbaren Planungswährungen eine Rolle. Sollen Kosten über mehrere Währungen hinweg geplant werden, ist Mehrwährungsfähigkeit erforderlich. Dann können Planungen zunächst in unterschiedlichen Währungen erfolgen. Die heterogenen Angaben der Kosten können im weiteren Verlauf für Zwecke der Zusammenführung und Auswertung aber auch in 141

10

Personalkostenplanungssysteme eine oder mehrere Referenzwährungen transformiert werden. Gegenwärtige Systeme sind allerdings nur teilweise mehrwährungsfähig.

10.1.3

Administrationskomponente Eine Administrationskomponente dient insbesondere der Organisation einer arbeitsteilig durchgeführten Personalkostenplanung. Werden Teilpläne von verschiedenen Anwendern erstellt – typischerweise etwa für verschiedene Organisationseinheiten – dann regelt die Administrationskomponente zunächst den Zugriff auf entsprechende Bereiche der Datenbankkomponente. Entsprechend kann ein Zugriff auf Datenbestände anderer Organisationseinheiten verhindert werden. Ebenso wird die Zusammenführung der Teilpläne zu einem Gesamtplan unterstützt. Werden im Sinne des Szenariogedankens oder einer »How-To-Reach«-Analyse mehrere Alternativpläne erstellt, so wird auch die Verwaltung der einzelnen Planversionen ermöglicht. Unterliegen einzelne Planungen einer Genehmigung durch entsprechende Führungskräfte, wird teils auch das notwendige Genehmigungs- und Freigabeverfahren von der Administrationskomponente unterstützt.

10.1.4

Analysekomponente Die Analysekomponente dient der systematischen Auswertung der erzeugten Plandaten und deren Vergleich mit Ist-Daten. So können erstellte Pläne zunächst nach Kosten je Kostenart, Mitarbeiter, Stelle, Kostenstelle und Organisationseinheit ausgewertet werden, um Aufschlüsse über künftige Personalkostenstrukturen zu erhalten. Insbesondere können so auch Quervergleiche zwischen Mitarbeitern, Stellen, Kostenstellen und/oder Organisationseinheiten angestellt werden. Solche auf Einzelpläne bezogenen Auswertungen können insbesondere das Erkennen von Änderungsbedarf und die Vornahme von Freigabeentscheidungen unterstützen. Werden mehrere alternative Pläne erstellt, dient die Analysekomponente insbesondere auch dem systematischen Vergleich dieser Pläne. So können etwa im Rahmen einer szenario-orientierten Planung die Spannbreite zwischen »Best Case«- und »Worst Case«-Szenarien systematisch analysiert werden. Sollen mit im Rahmen einer Planung gewisse Kosten- bzw. Budgetvorgaben erreicht werden, die in einem ersten Planungsdurchgang verfehlt wurden, so kann die Analysekomponente weiter auch zur Identifikation von Anhaltspunkten dienen, die zum Erreichen der Kostenvorgaben beitragen können. Die ziel-

142

10.2 Anwendung von Personalkostenplanungssystemen gerichtete gemeinsame Anwendung von Analyse- und Planungskomponente erweitert in diesem Sinne die eigentlich auf eine »What-If«-Planung ausgerichteten Systeme zumindest tendenziell in Richtung einer »How-To-Reach«-Planung. Über die Analyse reiner Plan-Daten hinaus, dient die Analysekomponente unter Rückgriff auf Kontrolldaten auch dem systematischen Abgleich der Plan-Daten mit den sich sukzessive ergebenden tatsächlichen Personalkosten. Neben anwenderseitigen Vergleichen von Plan und Ist sind auch automatisierte, vom System erstellte Meldungen an den Anwender möglich. Nach der Definition entsprechender Abweichungstoleranzen wird der Anwender durch Meldungen nach Starten des Systems, Sprach- oder Textnachrichten auf Mobiltelefon, e-Mails oder Telefaxe automatisch auf signifikante Plan-Ist-Abweichungen aufmerksam gemacht (»Exception Reporting«). Auch diese Auswertungen können nach Mitarbeitern, Stellen, Kostenstellen und/oder Organisationseinheiten durchgeführt werden. Solche Möglichkeiten erweitern die Funktionalität von Personalkostenplanungssystemen in Richtung eines umfassenderen Personalkostenmanagements.

10.2

Anwendung von Personalkostenplanungssystemen Mit den erheblichen ökonomischen Auswirkungen der Personalkosten kommt einem entsprechenden Management dieser Kosten eine zentrale Bedeutung zu. Die Vielschichtigkeit notwendiger Planungs- und Steuerungsvorgänge legt dabei die Verwendung entsprechender Kostenplanungssysteme nahe. Allerdings stehen solche Personalkostenplanungssysteme stets in unmittelbarem Wettbewerb zu Tabellenkalkulationssystemen (vgl. Paatz et al. 2007), die eine hochrechnungs- wie zeitreihenbasierte Planung in unproblematischer und durchaus umfassender Weise unterstützen. Aufgrund der funktionalen Nähe werden gegenwärtige Personalkostenplanungssysteme im Sinne einer modularen Architektur (vgl. Kap. 1) teilweise mit Personalabrechnungssystemen (vgl. Kap. 13) und auch mit anderen Planungssystemen der Unternehmensplanung angeboten. Dies vereinfacht den Datenaustausch und eine integrierte Anwendung. Neben den derzeit zentral berücksichtigten direkten Personalkosten wäre zukünftig auch das Management der indirekten Personalkosten, insbesondere Kosten der einzelnen Personalfunktionen eine sinnvolle Ergänzung. Eine Anwendung von Personalkostenplanungssystemen steht dabei in unmittelbarer Konkurrenz zur Anwendung von Vergütungsmanagementsystemen (vgl. Kap. 22), die ähnliche Aufgaben 143

10

Personalkostenplanungssysteme bearbeiten. Während Kostenplanungssysteme Vergütungsstrukturen als weitgehend konstant ansehen und auf der Basis absehbarer Änderungen im Stellen- bzw. Personalbestand auf die Planung und Steuerung direkter Personalkosten ausgerichtet sind, zielen Vergütungsmanagementsysteme auf die strategiekonforme Gestaltung von Vergütungsstrukturen und betonen damit Gestaltungsaufgaben. Insofern haben Vergütungsmanagementsysteme als die funktional breitere und gestaltungsorientiertere Kategorie zu gelten, die zentrale Aspekte einer kurz- bis mittelfristigen Personalkostenplanung und -steuerung im Sinne eines Kuppelproduktes bereitstellt.

Verbreitung

144

Derzeit sind keine empirischen Studien zur Verbreitung systemgestützter Personalkostenplanung bekannt.

11

Online Analytical Processing-Systeme Online Analytical Processing (»OLAP«)-Systeme sind Anwendungen zur entscheidungsorientierten, multidimensionalen und (dis-) aggregierenden Analyse von Daten. OLAP-Systeme setzen häufig auf Data Warehouse-Systemen (vgl. Kap. 5) auf und bilden zusammen mit den Data Mining-Systemen (vgl. Kap. 12) den zentralen Kern der so genannten Business Intelligence-Systeme.

11.1

Architektur und Funktionalität von OLAP-Systemen Die generellen Komponenten von OLAP-Systemen bilden neben der Anwenderschnittstelle insbesondere eine Komponente zur Datenhaltung sowie eine Komponente zur Durchführung von OLAP-Analysen (vgl. Abb. 11.1). OLAP-System Anwenderschnittstelle Data Warehouse

Analysekomponente Datenhaltungskomponente

Quellsysteme ROLAP

MOLAP

Abb. 11.1: Idealtypische Architektur von OLAP-Systemen Eine fakultative Datenhaltungskomponente dient der analyseorientierten Speicherung relevanter Daten. Die OLAP-Komponente übernimmt dann die Durchführung entsprechender Analysen.

11.1.1

Analysekomponente Online Analytical Processing wird als eine Art Gegenbegriff zum so genannten Online Transaction Processing (»OLTP«) vorge145

11

Online Analytical Processing-Systeme schlagen, um auf zentrale Differenzen in den Anforderungen an transaktionsorientierte operative Systeme und entscheidungsorientierte analytische Systeme aufmerksam zu machen (vgl. Codd et al. 1993). Transaktionsorientierte operative Systeme dienen der schnellen Erfassung und Verarbeitung von Daten mit meist geringem Volumen. Sie eignen sich aber weniger für umfassende und komplexe Analysen großer Datenvolumina zur Ableitung entscheidungsrelevanter Informationen (vgl. Mertens 2007), die entsprechend von OLAP-Systemen geleistet werden sollen. Aufgrund unterschiedlicher Auffassungen und auch ungerechtfertigter Verwendungen des OLAP-Begriffs wird inzwischen das so genannte FASMI (»Fast Analysis of Shared Multidimensional Information«)-Konzept zur Identifikation von OLAP-Systemen vorgeschlagen (vgl. Pendse 2004). Das Schnelligkeitskriterium erfordert vom entsprechenden System, dass die Abfrageergebnisse sehr schnell, d.h. i.d.R. in weniger als 30 Sekunden zur Verfügung stehen müssen, da der Anwender sonst den gedanklichen Zusammenhang verliert. Das Analysekriterium verlangt, dass beliebig komplexe Analysen im Sinne von Endbenutzerwerkzeugen, d.h. ohne Programmierung, spezifiziert werden können. Weiterhin sollen OLAP-Systeme für den Mehrbenutzerbetrieb mit entsprechenden Zugriffsschutzmechanismen ausgerichtet sein. Die Multidimensionalität gilt als Schüsselkriterium des OLAP, das die Möglichkeit einer mehrdimensionalen konzeptuellen Sicht auf Daten zulässt. Schließlich soll ein Anwender durch das System alle erwünschten Informationen erhalten und nicht durch die Beschränkungen des OLAP-Systems eingeschränkt werden. Auch diese Kriterien gestalten sich jedoch eher breit und unscharf. Entsprechend können vergleichsweise viele Systeme als OLAP-Systeme gelten. Trotz dieser eher breiten und unscharfen Bestimmung bilden ƒ die multidimensionale Datenanalyse (»Slicing & Dicing«) und ƒ die (dis-)aggregierende Datenanalyse (»Drill down & Roll up«) den zentralen funktionalen Kern gegenwärtiger OLAP-Anwendungen. Diese Analysemöglichkeiten sind von der OLAP-Komponente (»OLAP-Engine«) entsprechend zur Verfügung zu stellen.

Multidimensiona- Die multidimensionale Datenanalyse zielt auf Analysen personalwirtschaftlicher (und sonstiger) Kennzahlen nach mehreren le Datenanalyse Dimensionen gleichzeitig. Die zentrale Beschränkung einer Kennzahlenanalyse mittels einer Standardabfrage liegt darin, dass sie relevante Kennzahlen lediglich zu einer Dimension sinnvoll 146

11.1 Architektur und Funktionalität von OLAP-Systemen

77

234 123 322 111

89

Kennzahl (z.B. Personalbestand)

98

345 134 114 Dimension2 (z.B. Projekt)

(z Dim .B e . S ns ta ion nd 3 or t)

Dimension1 (z.B. Zeit)

ins Verhältnis setzen können, also etwa Personalbestand je Standort, Personalbestand je Projekt oder Personalbestand je Zeiteinheit. Eine Kreuztabellenabfrage erweitert die Analysemöglichkeiten auf zwei Dimensionen. Entsprechend könnte die Kennzahl Personalbestand je Standort und Projekt, je Standort und Zeiteinheit, je Zeiteinheit und Projekt etc. gleichzeitig analysiert werden (vgl. hierzu auch die Ausführungen zur Datenbankabfrage in Kap. 4). Eine simultane Analyse nach mehr als zwei Dimensionen, z.B. des Personalbestandes nach Zeiteinheit, Projekt und Standort ist dagegen aufgrund von Beschränkungen des relationalen Datenbankmodells regelmäßig schwierig. Relationale Datenbanken sind auf die optimierte und redundanzfreie Speicherung von Daten von transaktionsorientierten Systemen und nicht auf Analysezwecke des Managements ausgerichtet. Im Managementkontext ist es jedoch oft erforderlich, relevante Kennzahlen aus mehreren Perspektiven gleichzeitig zu analysieren (vgl. Codd 1970 und Codd et al. 1993). Daher sollen OLAP-Systeme anwendenden Entscheidungsträgern speziell die Möglichkeit einer solchen multidimensionalen Datenanalyse anbieten, was üblicherweise in einem Datenwürfel visualisiert wird (vgl. Abb. 11.2).

Abb. 11.2: Multidimensionale Datenanalyse Dabei sind auch Analysen mit mehr als drei Dimensionen möglich. OLAP-Systeme bieten zuweilen bis zu 30 und mehr Dimensionen an. Praktische Anwendungen der multidimensionalen Analyse umfassen i.d.R. allerdings zwischen vier und zwölf Analysedimensionen (vgl. Pendse 2004, o.S.). Werden mehr als drei Analysedimensionen verwendet, spricht man auch von so genannten Hyperwürfeln (»Hypercubes«). Dabei muss ein Anwender nicht stets alle angebotenen Dimensionen (und Kennzahlen) 147

11

Online Analytical Processing-Systeme in seine Analyse einbeziehen, sondern kann sich auf die jeweils relevanten Dimensionen (und Kennzahlen) beschränken. Die multidimensionale Analyse ermöglicht dem Anwender die flexible Auswertung der Datenwürfel, insbesondere kann ƒ die Bildung beliebiger Datenscheiben (»Slicing«) oder ƒ die Bildung beliebiger Datenwürfel (»Dicing«) vorgenommen werden. Bei der Bildung einzelner Datenscheiben wird ein Element einer Analysedimension besonders betrachtet, wie z.B. der Personalbestand eines speziellen Standorts, während die anderen Analysedimensionen erhalten bleiben (vgl. Abb. 11.3).

336 117 188 Januar

234 123 89 321 112 198

Februar

322 111 98 301 123 123

März

345 134 114 tA

Berlin

342 112

77

335 109

88

298 127 223 Saarbrücken

Hamburg

k tC tB oje ojek ojek r P Pr Pr

Abb. 11.3: Multidimensionale Datenanalyse (»Slicing«) Die Analyse von Teildatenwürfeln ermöglicht die gleichzeitige Auswahl von Elementen mehrerer Analysedimensionen, also z.B. der Beschränkung der Analyse des Personalbestandes auf gewisse Standorte, gewisse Projekte und gewisse Zeiteinheiten (vgl. Abb. 11.4).

336 117 188 342 234 Januar 321 112 198 335 Februar 322 301 123 123 298 127 223 Berlin März 345 134 114 Saarbrücken Hamburg A B kt C t t k k je oje oje Pro Pr Pr

112 77 123 89 109 88 111 98

Abb. 11.4: Multidimensionale Datenanalyse (»Dicing«) 148

11.1 Architektur und Funktionalität von OLAP-Systemen Die Kombination beider Varianten (»Slicing & Dicing«) bietet dem Anwender völlig flexible Möglichkeiten, personalwirtschaftliche Kennzahlen aus beliebigen Perspektiven und Blickwinkeln zu analysieren. (Dis-)Aggregieren- Dass Analysedimensionen von Datenwürfeln auch in hierarchide Datenanalyse schen Schichten geordnet sein können, ermöglicht zusätzlich die (dis-)aggregierende Datenanalyse. Ein einfaches Beispiel einer hierarchischen Analysedimension bildet der »Standort«, der etwa in Städte, Länder und Kontinente hierarchisch gegliedert werden kann. Die Dimensionen entsprechender Datenwürfel sind daher gegebenenfalls hierarchisch gegliedert. Der Pfad von der obersten (z.B. »Kontinent«) bis zur untersten Hierarchieebene (z.B. »Einzelstandort«) wird dabei als Konsolidierungspfad bezeichnet. Obwohl OLAP-Systeme i.d.R. mehr zulassen, umfassen Konsolidierungspfade realer Anwendungen selten mehr als sechs hierarchische Ebenen (vgl. Pendse 2004, o.S.). Weisen auszuwertende Datenwürfel auf diese Weise eine oder mehrere hierarchische Dimensionen auf, dann werden zusätzlich ƒ die aggregierende Datenanalyse (»Roll Up«) und ƒ die disaggregierende Datenanalyse (»Drill Down«) möglich. Die aggregierende Datenanalyse bewegt sich im Konsolidierungspfad von unten nach oben. Der Anwender beginnt auf der untersten oder einer der unteren Hierarchieebenen der Dimension, z.B. der Ebene der Einzelstandorte, und geht dann auf eine aggregiertere Ebene, z.B. die Landesebene, über. Der Anwender erhält so zunehmend generelle Informationen über die Kennzahl in der entsprechenden Dimension (vgl. Abb. 11.5).

336 117 188 342 112 77 234 123 89 Januar 809 698 354 321 112 198 335 109 88 Februar 322 111 98 Februar 788 332 384 301 123 123 298 127 223 Berlin März 345 134 114 März 799 403 489 Saarbrücken Hamburg A A B B tC tC kt kt kt kt jek jek e e e e j j j j o o o o o o Pr Pr Pr Pr Pr Pr Januar

Deutschland

Abb. 11.5: Aggregierende Datenanalyse (»Roll Up«) Die disaggregierende Datenanalyse bildet die Komplementäroperation zur aggregierenden Datenanalyse. Die Analyse beginnt 149

11

Online Analytical Processing-Systeme hierbei auf einer aggregierten Ebene und springt dann sukzessive auf tiefere Ebenen. Der Anwender erhält so zunehmend detaillierte Informationen zur Aufschlüsselung der Kennzahl in der entsprechenden Dimension (vgl. Abb. 11.6).

Januar

809 698 354

Februar

788 332 384

März

799 403 489

P

jek ro

B tC kt jek e j o o Pr Pr

tA

Deutschland

336 117 188 342 112 77 Januar 234 123 89 321 112 198 335 109 88 Februar 322 111 98 301 123 123 298 127 223 Berlin 345 134 114 März Saarbrücken Hamburg A B tC kt kt jek e e j j o o o Pr Pr Pr

Abb. 11.6: Disaggregierende Datenanalyse (»Drill Down«) Existieren mehrere hierarchische Dimensionen, können solche aggregierende und disaggregierende Analysen auch in mehreren Dimensionen parallel durchgeführt werden. Multidimensionale und (dis-)aggregierende Analyse können dabei auch simultan angewendet werden. Damit wird eine ausgesprochen flexible Form der Bereitstellung deskriptiver entscheidungsunterstützender Information im Sinne einer »What«-Analyse ermöglicht. Zu Recht werden OLAP-Systeme daher häufig den entscheidungsunterstützenden Systemen zugerechnet. In Korrespondenz mit der methodisch unscharfen Bestimmung des OLAP-Konzeptes nach FASMI werden teils jedoch auch zusätzliche Funktionen mit simulativem Charakter wie etwa die Simulation im Rahmen von OLAP-Systemen angeboten und entsprechend dem OLAP zugerechnet und als »dispositives OLAP« bezeichnet. Abfragesprachen und -werkzeuge

150

Die Spezifikation von Analysen kann dann über die Verwendung von Abfragewerkzeugen oder auch Abfragesprachen wie MDX (»Multidimensional Expressions«) erfolgen. Häufig sind Abfragewerkzeuge als interaktive Kreuztabellen (»Pivottable«) mit jeweils mehreren Analysedimensionen je Spalte und Zeile realisiert, die dann gleichzeitig auch der Ergebnisausgabe dienen. Zentraler Unterschied zu den statischen Kreuztabellen der Datenbankabfrage (vgl. Kap. 4) bildet dabei die Möglichkeit die Analysedimensionen innerhalb der Kreuztabelle je nach Abfragebedarf im

11.1 Architektur und Funktionalität von OLAP-Systemen Sinne einer multidimensionalen und (dis-)aggregierenden Analyse beliebig zu verändern. Korrespondierend hierzu können auch interaktive Pivotcharts verwendet werden, wobei in der Regel Säulendiagramme als Standarddiagrammtyp verwendet werden. Inzwischen verfügen solche Diagramme oft über so genannte »Point & Click«-Funktionen, die es erlauben Analysen wie etwa einen »Drill Down« direkt über Anklicken eines entsprechenden Diagrammbestandteils zu starten. Pull- und PushInformationen

Neben Analysen, die vom Anwender gemäß seinen Informationsbedürfnissen spezifiziert werden (»Pull«-Informationen), sind auch automatisierte, vom System erstellte Meldungen an den Anwender möglich. Nach der Definition entsprechender Kriterien bzw. Schwellenwerte wird der Anwender automatisch über signifikante Entwicklungen oder Abweichungen aufmerksam gemacht (»Push«-Informationen, »Exception Reporting«). Neben automatisierten Meldungen nach Starten des Systems sind auch Sprachoder Textnachrichten auf Mobiltelefon, e-Mails oder Telefaxe zur Realisierung dieser automatisierten Informationsversorgung möglich.

11.1.2

Datenhaltungskomponente OLAP-Systeme können entweder über eine eigenständige Datenhaltungskomponente verfügen oder aber direkt auf Data Warehouse-Systemen als datenhaltenden Systemen aufsetzen (vgl. Kap. 5). Die Daten der Datenhaltungskomponente werden i.d.R. nicht eigens für Zwecke der Steuerung und Kontrolle eingegeben, sondern entstammen verschiedenen Quellsystemen aus dem Segment personalwirtschaftlicher Anwendungssysteme. Sollen in einem OLAP-System Daten aus mehreren heterogenen Quellsystemen analysiert werden, dienen häufig Data Warehouse-Systeme als integrative Datenhaltungssysteme von OLAP-Systemen. Die Datenhaltung wird dann meist komplett an das Data Warehouse ausgelagert, so dass keine eigenständige Datenhaltungskomponente mehr nötig ist. Um datenhaltende und datenanalysierende Systeme verschiedener Hersteller im Rahmen des OLAP unproblematisch kombinieren zu können, existieren derzeit verschiedene Bemühungen zur Schaffung von Datenaustauschstandards wie »OLE DB for OLAP« oder »Multidimensional API«, die einen unproblematischen Datenaustausch ermöglichen sollen. (Umgekehrt verfügen Data Warehouse-Systeme oft ihrerseits über umfangreiche integrierte OLAP-Funktionalitäten, so dass kein separates OLAP-System mehr nötig ist [vgl. Kap. 5]). Die Datenhaltungskomponente ist damit zunächst eine fakultative Kompo151

11

Online Analytical Processing-Systeme nente. Verfügen OLAP-Systeme über eine eigene Datenhaltungskomponente, kann diese auf der Basis unterschiedlicher Datenbankmodelle realisiert werden (vgl. Kap. 4). Grundsätzlich wird diesbezüglich zwischen ƒ relationalem OLAP (»ROLAP«), ƒ multidimensionalem OLAP (»MOLAP«) und ƒ hybridem OLAP (»HOLAP«) unterschieden (vgl. Lusti 2002, 160ff.).

Relationales OLAP

Das relationale OLAP verwendet relationale Datenbanksysteme und spezifische Modellierungsschemata, um die Datenhaltung zu realisieren. Da die multidimensionalen Analysemöglichkeiten dabei auf der Basis von zweidimensionalen Tabellen und nicht auf physisch multidimensionalen Datenstrukturen beruhen, wird auch von »virtuellem OLAP« gesprochen. Das einfachste Modellierungsschema ist das so genannte »Starschema«. Es besteht aus einer Faktentabelle und mehreren Dimensionstabellen. Die Faktentabelle bildet die relevanten Kennzahlen (»Fakten«) ab, während in den Dimensionstabellen die entsprechenden Analysedimensionen abgespeichert werden. Entsprechend existiert für jede Dimension eine eigene Tabelle. Fakten- und Dimensionstabellen werden im Sinne des relationalen Datenbankmodells mit Schlüsseln in Beziehung gesetzt. Dass sich die Dimensionstabellen sternförmig um die zentrale Faktentabelle anordnen, erklärt die Bezeichnung »Starschema« (vgl. Schinzer et al. 1999, 48f.). Zeit

Standort

Zeit-ID Tag Monat ... Jahr

Standort-ID PLZ Ort ...

Projekt

Fakten-Tabelle Zeit-ID Projekt-ID Standort-ID Personalbestand ...

Projekt-ID Teilprojekt Projekt ... Projektfamilie

Abb. 11.7: Starschema im ROLAP 152

11.1 Architektur und Funktionalität von OLAP-Systemen Abb. 11.7 gibt das konkrete Starschema wieder, das notwendig ist, um die oben dargestellten Analysen auf ROLAP-Basis zu ermöglichen. Da das Starschema auf die Normalisierung der Daten verzichtet, werden Daten in den Dimensionstabellen redundant gehalten, was zu entsprechenden Volumina und Performanzfolgen führt. Aus diesem Grund werden auch verfeinerte Datenschemata vorgeschlagen (vgl. Schinzer et al. 1999, 49f.). Multidimensionales OLAP

Das multidimensionale OLAP verwendet dagegen multidimensionale Datenbanken, die die auf konzeptioneller Ebene multidimensional dargestellten Datenstrukturen auch in ihrer physischen Datenbankstruktur multidimensional umsetzt. Im Unterschied zu relationalen Datenbanken hat sich aber noch keine einheitliche und generell akzeptierte Speichertechnologie durchgesetzt. Entsprechend existieren verschiedene proprietäre Systeme diverser Anbieter. Mit dieser physischen Umsetzung der Multidimensionalität entsteht i.d.R. das Problem, dass mit zunehmender Dimensionalität die Zahl grundsätzlich entstehender Datenzellen stark ansteigt, jedoch ohne dass jede Zelle mit Werten besetzt ist. Entsprechend sind i.d.R. lediglich 1-10% der Zellen besetzt (»Sparsity«-Problem). Da die übrigen Zellen mit »Not Available«-Werten gefüllt werden, führt dies zu einem Aufblähen des Datenvolumens und entsprechenden Performanzverlusten. Entsprechend werden verschiedene Verfahren zum Umgang mit dünn besetzen Würfeln diskutiert (vgl. Pedersen & Jensen 2001, 44f.).

Hybrides OLAP

Das hybride OLAP versucht die Vorteile von relationalem und multidimensionalem OLAP zu kombinieren. In Abhängigkeit von Kriterien wie Abfragehäufigkeit und Aggregationsniveau werden Daten entweder relational oder multidimensional abgelegt. Häufig benötigte Daten mit hohem Aggregationsniveau werden multidimensional, weniger häufig benötigte Daten mit niedrigem Aggregationsniveau und entsprechendem Volumen werden relational abgelegt. Auf diese Weise weisen HOLAP-Systeme eine besondere Flexibilität auf (vgl. Schinzer et al. 1999, 54).

Präaggregation

Um wie beschrieben eine aggregierende und disaggregierende Datenanalyse zu ermöglichen, werden je nach Datenhaltungskonzept die verschiedenen Aggregationsstufen von Daten (»Granularitäten«) teils zur Laufzeit der Abfrage aus den Detaildaten erzeugt. Aufgrund der Zeitaufwändigkeit und Performanceanforderungen dieses Vorgehens werden aber oft auch verschiedene Aggregationsschichten in der Datenhaltungskomponente redundant gehalten, um einen schnellen Zugriff auf solche präaggregierten Datenbestände zu ermöglichen. Weiter werden einmal 153

11

Online Analytical Processing-Systeme bestehende Daten im Rahmen zyklischer Aktualisierungsvorgänge i.d.R. nicht einfach überschrieben, sondern historisiert. Entsprechend werden relevante Kennzahlen als Zeitreihen gehalten, und die »Zeit« bildet regelmäßig eine wichtige Analysedimension. Auch aufgrund des Haltens historisierter Daten auf unterschiedlichen Aggregationsstufen weisen Datenhaltungskomponenten von OLAP-Systemen oft umfangreiche Datenvolumina auf.

Referenzdatenstrukturen

Neben »leeren« Systemen, in denen die Anwender entsprechende unternehmensindividuelle Datenstrukturen von Grund auf anlegen müssen, existieren zunehmend auch OLAP-Systeme mit Referenzdatenstrukturen. Solche Strukturen bestehen aus vordefinierten Daten-Würfeln bzw. -Schemata, die entsprechende personalwirtschaftliche Kennzahlen und korrespondierende Dimensionen als Referenzbeispiele vorgeben. I.d.R. beruhen solche Referenzdatenstrukturen auf der Zusammenarbeit von Softwareanbieter und mehreren Pilotkunden des entsprechenden OLAP-Systems. Werden Referenzdatenstrukturen angeboten, können diese vom anwendenden Unternehmen – unmodifiziert oder modifiziert – übernommen und mit unternehmensindividuellen Daten gefüllt werden.

11.2

Anwendung von OLAP-Systemen

Anwendungsbereiche

Durch die Ermöglichung spezifischer »What?«-Analysen liegt der Anwendungsbereich von OLAP-Systemen speziell in der Steuerung und Kontrolle des gesamten personalwirtschaftlichen Geschehens, während aufgrund des Fehlens prognostizierender Methoden eine Anwendung in der Planung i.d.R. nicht gegeben ist. Zunächst können OLAP-Systeme dazu verwendet werden, beliebige personalwirtschaftliche Funktionsbereiche wie etwa die Personalbeschaffung zu steuern und zu kontrollieren. Beispielsweise können zur Steuerung und Kontrolle der Personalbeschaffung Kennzahlen wie »Zahl der Einstellungen« oder »Beschaffungskosten« nach beliebigen Dimensionen wie »Geschäftsbereich«, »Bewerbersegment«, »Standort«, »Beschaffungsmedium«, »Beschaffungsmitarbeiter« etc. analysiert werden. Insbesondere in der Interaktion mit Data Warehouse-Systemen können OLAP-Systeme unter Anbindung der jeweiligen Administrations- und Dispositionssysteme aber auch zur generellen Steuerung und Kontrolle des gesamten Personalbereichs (sowie weiterer betrieblicher Funktionsbereiche) herangezogen werden. Solche generellen Anwendungen sind insbesondere wegen der damit einhergehenden Möglichkeit einer gesamthaften Sicht auf relevante Analyseobjekte, wie etwa einzelne Mitarbeiter, sinnvoll. In Abhängigkeit von

154

11.2 Anwendung von OLAP-Systemen den Quelldatenbeständen können letztlich beliebige personalwirtschaftlich relevante Kennzahlen (»Key Performance Indicators/KPIs«) (vgl. z.B. Schulte 2002 und Aerts et al. 2004) und deren Entwicklung im Zeitablauf nach beliebigen Dimensionen analysiert werden. In funktionsübergreifenden Anwendungen können Personalkennzahlen so auch im generellen betrieblichen Kontext analysiert werden. Eine Anwendung in der Planung ist wegen des deskriptiven Charakters bzw. des Fehlens simulativer Komponenten dagegen i.d.R. nicht möglich. Ausnahmen bilden solche OLAP-Systeme, die über die dargestellte multidimensionale und (dis-)aggregierenden Datenanalyse hinaus zusätzliche, auch prognostizierende Methoden anbieten. Da solche Anwendungen neue (Plan- bzw. Soll-)Daten schaffen, sind diese dann zusätzlich zu den importierten Daten der Quellsysteme in der Datenhaltungskomponente abzulegen. OLAP-Systeme eignen sich damit zur umfassenden Informationsversorgung des Personalmanagements und bieten das generelle Potenzial, die konventionell auf Berichten (»Reports«) beruhende personalwirtschaftliche Informationsversorgung in Richtung komplexer interaktiver Analysen weiter zu entwickeln. In diesem Sinne bilden OLAPSysteme die leistungsfähige aktuelle Variante von »Personalinformationssystemen« im engeren Sinne. Unter Anbindung von Browsersystemen (vgl. Kap. 28) können so webbasierte »HR Cockpits« realisiert werden, die den Führungskräften der Fachabteilung »Personal« wie der übrigen Fachabteilung personalisierte Informationen zu den für sie jeweils relevanten Aspekten des Personalmanagements liefern. Verbreitung

Die konkrete Verbreitung von OLAP-Systemen im Personalmanagement ist derzeit unbekannt. Mit der zunehmenden generellen Verbreitung von Data Warehouse-Systemen und der Aufnahme von OLAP-Funktionen in Tabellenkalkulationssysteme (vgl. Vidmar & Hudomalj 2002) zeichnet sich jedoch die sukzessive Diffusion von OLAP auch im Personalmanagement ab.

155

12

Data Mining-Systeme Data Mining-Systeme (»Knowledge Discovery-Systeme«, »KDDSysteme«, Datenmustererkennungssysteme, Systeme zur Wissensentdeckung in Datenbanken) sind Anwendungen zur Identifizierung von gültigen, bislang unbekannten, potenziell nützlichen und verständlichen Mustern in Daten (vgl. Fayyad et al. 1996, 1). Data Mining-Systeme setzen häufig auf Data Warehouse-Systemen (vgl. Kap. 5) auf und bilden zusammen mit den OLAP-Systemen (vgl. Kap. 11) den zentralen Kern der Business Intelligence-Systeme.

12.1

Architektur und Funktionalität von Data Mining-Systemen Obwohl Data Mining-Systeme unterschiedliche Strukturen aufweisen (vgl. Düsing 2005, 256f.), lassen sich neben der Anwenderschnittstelle idealtypisch die Bestandteile Vorgehensmodell, Datenzugriffskomponente, Analyse- und Visualisierungskomponente, Datenbank sowie eine Analyseprozesskomponente unterscheiden (vgl. Abb. 12.1). Data Mining-System Anwenderschnittstelle Datensenken Datenquellen

Analyseprozesskomponente Datenzugriff

Datenvorverarbeitung

Analyseprozesse

Analyse

Visualisierung

Datenmuster

Abb. 12.1: Idealtypische Architektur von Data Mining-Systemen Das Vorgehensmodell gibt dem Anwender eine generelle Orientierung über den Ablauf eines Data Mining-Projektes und ermöglicht die Verwaltung verschiedener Data Mining-Projekte. Die Datenzugriffskomponente sorgt für die Anbindung externer Daten157

12

Data Mining-Systeme quellen. Die Vorverarbeitungskomponente dient der Vorverarbeitung der zu analysierenden Daten. Die Analysekomponente stellt entsprechende Mining-Algorithmen zur Verfügung, während die Visualisierungskomponente für eine grafische Aufbereitung von Analyseergebnissen sorgt. Die Analyseprozess-Komponente dient der Gestaltung und Durchführung komplexer Analyseprozesse. In der Datenhaltungskomponente werden erstellte Analyseprozesse und deren (Zwischen-)Ergebnisse abgelegt.

12.1.1

Vorgehensmodell Data Mining-Systeme basieren teilweise auf normativen Vorgehensmodellen zum Data Mining (vgl. Giraud-Carrier & Povel 2003, 181f.), die verschiedene Phasen vorschreiben, den Prozesscharakter des Data Mining betonen, sowie der Strukturierung und systematischen Abspeicherung von Data Mining-Projekten dienen. Allerdings ist die Anwendung von Vorgehensmodellen auch in Systemen, die mit Vorgehensmodellen arbeiten, meist fakultativ.

CRISP-DM

158

Obwohl unterschiedliche Akzente gesetzt werden, gleichen sich die angebotenen Vorgehensmodelle grundsätzlich darin, dass ein Vorgehen in einzelnen, auch durch Rückkopplungen gekennzeichneten Phasen vorgeschlagen wird. Ein bekanntes und verbreitetes Vorgehensmodell, das in verschiedenen Systemen Anwendung findet, bildet beispielsweise das »CRISP-DM« (»Cross Industry Standard Process for Data Mining« [www.crisp-dm.org]). Dabei soll die Schaffung von umfassendem Geschäftsverständnis das Verständnis des konkreten Entscheidungsproblems ermöglichen, vor dessen Hintergrund Data Mining entscheidungsunterstützende Informationen erbringen soll. Die sich anschließende Schaffung eines grundsätzlichen Datenverständnisses beginnt zunächst mit einer Zusammenstellung und Exploration der relevanten Daten aus den entsprechenden Anwendungs- bzw. Datenbanksystemen. Die Datenvorbereitung umfasst im Anschluss alle Aktivitäten, um die geladenen Rohdaten in verwertbare Data Mining-Dateien zu überführen. Im Einzelnen gehören hierzu die Auswahl von Daten, die Bereinigung von Daten sowie die Zusammenführung von Daten aus unterschiedlichen Quellen, das Schaffen neuer abgeleiteter Datenfelder, sowie ggf. die Formatierung und Umkodierung von Daten. In der Modellierungsphase werden schließlich geeignete Data Mining-Methoden ausgewählt und korrespondierende Parameter der Methode bestimmt. I.d.R. sind danach mehrere Testläufe zur Evaluierung der Güte des angestrebten Modells notwendig. Typischerweise werden die ver-

12.1 Architektur und Funktionalität von Data Mining-Systemen fügbaren Datensätze in eine Trainings- und eine oder mehrere Testdatenmenge(n) aufgeteilt. Die Methode wird dazu zunächst an der Trainingsdatenmenge angewendet, während die Güte gefundener Ergebnisse, insbesondere ihre Vorhersageleistung, im Anschluss an der Testdatenmenge evaluiert wird. Trotz dieser Maßnahmen schließt sich nochmals eine separate Evaluationsphase an, die überprüft, inwieweit die Ergebnisse den grundsätzlichen Geschäftszielen und den Anforderungen der Entscheidungssituation entsprechen. Eine letzte Phase dient der Anwendung. Hier sind die gefundenen Datenmuster so darzustellen, dass entsprechende personalwirtschaftliche Entscheidungsträger sie verstehen und verwenden können (vgl. Shearer 2000, 14ff.).

12.1.2

Datenzugriffskomponente Data Mining-Systeme zielen auf die Analyse von externen Daten unterschiedlicher Herkunft und Art. Entsprechend verfügen Data Mining-Systeme zunächst über eine Datenzugriffskomponente, die je nach System ein mehr oder minder breites Spektrum an Datenquellen anbinden kann. Dazu werden Abfragesprachen wie speziell SQL oder auch benutzerfreundliche Abfragewerkzeuge zur Spezifikation der benötigten Daten angeboten (vgl. auch Kap. 4). Neben dem expliziten Zugriff auf spezielle Datenbankdateiformate kann weit verbreitet auch auf Daten aus Tabellenkalkulationssystemen oder ASCII-Textdateien zugegriffen werden (vgl. Goebel & Gruenwald 1999, 26f.). Dabei kann grundsätzlich zwischen einem Online-Zugriff und einem Offline-Zugriff auf die entsprechenden Datenquellen unterschieden werden. Beim Online-Zugriff werden Daten direkt im laufenden Betrieb bei den entsprechenden Quellsystemen abgegriffen, während beim Offline-Zugriff ein Duplikat der entsprechenden Datei(en) erstellt wird, auf das dann zugegriffen wird (vgl. Goebel & Gruenwald 1999, 21f.).

12.1.3

Vorverarbeitungskomponente So angebundene Daten können gewissen Vorverarbeitungen unterzogen werden, die sich auf Datensätze und/oder Datenfelder beziehen können. Beispielsweise kann man im Rahmen von Datensatzoperationen Datensätze aus unterschiedlichen Datenquellen integrieren, eine Zufallsstichprobe aus allen Datensätzen ziehen oder mittels eines Filters spezifische Datensätze zur Analyse auswählen. Datenfeldoperationen zielen etwa auf das Füllen leerer Felder (»Missings«) mit Defaultwerten oder die Generierung 159

12

Data Mining-Systeme neuer, abgeleiteter Datenfelder aus vorhandenen Datenfeldern (vgl. Collier et al. 1999, 4ff.).

12.1.4

Analysekomponente Die Analysekomponente stellt im Rahmen der Anwendung die eigentlichen Data Mining-Methoden zur Verfügung. Welche konkreten Analysen und korrespondierenden Methoden(-gruppen) zum Data Mining zu zählen sind, ist allerdings nicht abschließend geklärt. So finden sich in Data Mining-Systemen neben Methoden der »künstlichen Intelligenz« auch altbekannte statistische Methoden wie etwa die Cluster- oder Diskriminanzanalyse (vgl. Berry & Linoff 2004). Die Gemeinsamkeit dieser Methoden liegt in ihrer Eigenschaft, automatisiert Muster oder Strukturen in Daten finden zu können, die dem menschlichen Anwender i.d.R. sonst verborgen blieben. Hieraus erklärt sich auch die metaphorische Bezeichnung »Data Mining« (»Datenbergbau«), die auf das Graben nach verborgenen »Nuggets« verweist. Nach dem Umfang der Methoden-Komponente können Einzelwerkzeuge und so genannte »Data Mining-Suiten« unterschieden werden. Einzelwerkzeuge spezialisieren sich auf eine einzelne Analyseart und meist auch auf eine bestimmte Methode. »Data Mining-Suiten« weisen dagegen ein umfangreicheres Angebot an Analysen mit i.d.R. jeweils mehreren korrespondierenden Methoden auf (vgl. Collier et al. 1999, 3f.; Gaul & Säuberlich 1999, 144ff.; Goebel & Gruenwald 1999, 29f.; Giraud-Carrier & Povel 2003, 185f.).

Klassifikationsanalyse

Assoziationsanalyse

Clusteranalyse

Abweichungsanalyse

Abb. 12.2: Zentrale Analysearten des Data Mining Das angebotene Methodenspektrum variiert dabei je nach System. Verbreitet angebotene Analysenmethoden sind dabei ƒ die Klassifikationsanalyse, ƒ die Assoziationsanalyse, ƒ die Clusteranalyse und ƒ die Abweichungsanalyse (vgl. auch Abb. 12.2). 160

12.1 Architektur und Funktionalität von Data Mining-Systemen Klassifikationsanalyse

Grundsätzlich ordnet die Klassifikationsanalyse Datensätze anhand deren Datenfeldausprägungen vom Anwender vordefinierten Klassen zu. Liegt beispielsweise eine Bewerberdatei vor, die neben anderen Attributen auch abbildet, ob ein Bewerber eingestellt wurde oder nicht, dann können Bewerberdatensätze in die Klassen »Einstellung = ja« und »Einstellung = nein« aufgeteilt werden. Im Rahmen der Zuordnung zu einer Gruppe werden die Datensätze sukzessive mit weiteren Datenfeldausprägungen in Verbindung gebracht. Beispielsweise wird überprüft, ob sich eingestellte und nicht eingestellte Bewerber systematisch bezüglich des Vorliegens einer Ausbildung unterscheiden. Die Datensätze werden so anhand verschiedener Attribute sukzessive in Teilmengen aufgespaltet, bis eine möglichst gute Klassifikation in eingestellte und nicht eingestellte Bewerber erreicht ist. Dieser Aufspaltungsvorgang wird üblicherweise in einer Baumstruktur visualisiert (vgl. Abb. 12.3).

Einstellung = ja Einstellung = nein Ausbildung ja

Alter  60

WENN Ausbildung = ja UND Alter < 60 DANN Einstellung = ja

Ausbildung nein

Alter t 60

WENN Ausbildung = nein DANN Einstellung = nein

WENN Ausbildung = ja UND Alter t 60 DANN Einstellung = nein

Abb. 12.3: Klassifikationsbaum und Regeln (Strohmeier & Piazza 2005, 119) Basierend auf den einzelnen Aufspaltungsvorgängen lassen sich »Wenn-Dann«-Regeln zur Einstellung von Bewerbern ableiten. Diese Regeln bilden das in der Datenbank erkannte Muster. Entsprechend der Visualisierung in Bäumen werden hierzu angebo161

12

Data Mining-Systeme tene Methoden wie etwa der »C5.0«-Algorithmus unter der Bezeichnung Klassifikationsbaum (Entscheidungsbaum) zusammengefasst (vgl. Berry & Linoff 2004, 165ff.).

Assoziationsanalyse

Die Assoziationsanalyse zielt auf die Entdeckung von simultanen (statische Assoziationsanalyse) oder sukzessiven (sequentielle Assoziationsanalyse, Sequenzanalyse) Verknüpfungen von Datenfeldern und/oder Datenfeldausprägungen. Sie sucht damit nach dem überzufälligen Auftreten von Abhängigkeiten. Anders als etwa bei der Regressionsanalyse werden ex ante keine konkreten Abhängigkeiten unterstellt. Vielmehr ist es gerade die Aufgabe der Assoziationsanalyse, solche Abhängigkeiten in einer größeren Gruppe von Datensätzen bzw. Datenfeldausprägungen zu finden. Hierfür angebotene Algorithmen wie etwa der »Apriori«Algorithmus lösen dabei insbesondere das Problem exponentiell wachsender Kombinationsmöglichkeiten (vgl. Berry & Linoff 2004, 349ff.). Im Rahmen der sequentiellen Assoziationsanalyse kann beispielsweise bei Vorliegen einer umfangreicheren Mitarbeiterdatei mit entsprechenden zeitbezogenen Daten nach typischen Verlaufsmustern im Zeitablauf gesucht werden, die die Gesamtentwicklung eines Mitarbeiters im Zeitablauf abbilden. Eine typische sequentielle Assoziationsregel könnte damit etwa WENN in t0 UND in t0 UND in t0 DANN in t1

Beurteilung = »Stufe C« Potenzial = »Stufe 3« Anzahl Trainingsmaßnahmen ” »1« Kündigung durch Mitarbeiter = »ja«

lauten. Clusteranalyse

162

Die Clusteranalyse bildet Gruppen (»Cluster«) gleichartiger Datensätze. Cluster werden dabei so gebildet, dass die Datenfeldausprägungen von Datensätzen innerhalb eines Clusters sich möglichst ähnlich sind, während die Datenfeldausprägungen von Datensätzen aus verschiedenen Clustern möglichst unterschiedlich ausfallen. Ex ante ist dabei nicht bekannt, bezüglich welcher Datenfelder sich die gefundenen Cluster unterscheiden bzw. ähneln werden. Hierfür angebotene Methoden sind typischerweise Clusteralgorithmen, wie etwa der »K-Means«-Algorithmus, wie sie im Rahmen statistischer Analysen seit langem gebräuchlich sind (vgl. Berry & Linoff 2004, 349ff.). Liegt eine Mitarbeiterdatei mit mehreren, die Mitarbeiter beschreibenden Attributen vor, können mittels der Segmentierung verschiedene homogene Segmente von Mitarbeitern gebildet werden, die dann u.a. beispielsweise zur Bildung eines Personalportfolios verwendet werden können.

12.1 Architektur und Funktionalität von Data Mining-Systemen Abweichungsanalyse

Die Abweichungsanalyse zielt schließlich auf die Identifikation von »Ausreißer«-Datensätzen, die sich in einer oder mehreren Datenfeldausprägung(en) signifikant vom Rest der Datei unterscheiden. Das Ziel der Abweichungsanalyse besteht entsprechend darin, solche Abweichungen zunächst zu erkennen und anschließend – ggf. unter Verwendung weiterer Data Mining-Methoden – auf mögliche Ursachen hin zu analysieren. Neben der Identifikation von interessanten »Ausreißern« und deren weiterer Analyse, zielt die Abweichungsanalyse aber auch auf das Erkennen von fehlerhaften Datensätzen und deren Korrektur oder Elimination im Rahmen der Datenvorbereitung (vgl. Berry & Linoff 2004, 73f.). Hierzu werden Methoden wie etwa der »Partition Based Outlier Detection«-Algorithmus angeboten. Im Rahmen des Personalmanagements können so etwa Mitarbeiterdatensätze mit Auffälligkeiten wie besonders lange Arbeitszeiten, besonders umfangreicher Resturlaub o.ä. identifiziert werden.

12.1.5

Visualisierungskomponente I.d.R. weisen Data Mining-Systeme neben den eigentlichen Methoden auch Komponenten zur Veranschaulichung der methodenbasiert gefundenen Muster auf. Beispielsweise ermöglichen Systeme zur Klassifikation regelmäßig Visualisierungen der entsprechenden Klassifikationsbäume. Die Art der hierzu verwendeten Visualisierung hängt vom jeweiligen System und von der Methode ab. Neben Diagrammen der herkömmlichen Geschäftsgrafik wie etwa Histogrammen, weisen Data Mining-Systeme oft neuartige, methodenspezifische Visualisierungen auf.

12.1.6

Analyseprozesskomponente Die Analyseprozesskomponente stellt die zentrale Plattform für den Anwender dar. Unter Rückgriff auf die übrigen Komponenten können hier komplexe Analyseprozesse gestaltet und durchgeführt werden. Hierzu existieren zunächst Werkzeuge zum grafischen Entwurf von Analyseprozessen. Einzelne vom Anwender frei kombinierbare Prozessbestandteile sind dabei ƒ Datenquellen, ƒ Daten(-satz und -feld)operationen, ƒ Data Mining-Methoden, ƒ Ergebnisausgaben (inklusive Visualisierungen) sowie ƒ Datensenken. I.d.R. beginnt ein Analyseprozess mit der Angabe einer oder mehrerer Datenquellen, die die zu analysierenden Daten enthal163

12

Data Mining-Systeme ten. Die so eingebundenen Daten können im Folgenden unterschiedlichen Datensatz- und Datenfeldoperationen im Sinne der dargestellten Vorverarbeitung unterzogen werden. Die vorverarbeiteten Daten können anschließend mittels unterschiedlichen Data Mining-Methoden auf das Vorliegen von Mustern hin untersucht werden. Ergebnisausgaben zielen zum einen auf die (visuelle) Präsentation der gefundenen Muster. Gleichzeitig können aber auch beliebige Zwischenergebnisse, z.B. das Ergebnis eines Filters gezeigt werden. Datensenken ermöglichen dann den Datenexport an Fremdsysteme. Etwa können geclusterte Datensätze an ein Tabellenkalkulationssystem ausgegeben werden. I.d.R. sind die Werkzeuge zur Konzeption von Analyseprozessen grafisch orientiert. D.h. der Anwender wählt aus einem Angebot an Datenquellen, Datenoperationen, Methoden, Ausgaben und Senken passende Optionen aus, platziert diese per »Drag & Drop« im Analyseprozess, spezifiziert die einzelnen Positionen und stellt die gewünschten Datenflussverbindungen her, wie in Abb. 12.4 angedeutet. Datenquellen

SQLDatenbank

»flat-file«Datenbank

Datenoperationen

Mapping

Filter

Data Mining Methoden

k-Means

Apriori

C5.0

Ergebnisausgabe

Datensenken

Regeln

Tabellenkalkulation

Regeln

Tabelle

Histogramm

Abb. 12.4: Analyseprozess im Data Mining

164

12.2 Anwendung von Data Mining-Systemen Im Ergebnis werden beliebig komplexe, lineare wie verzweigte Analyseprozesse möglich, die auch mehrere Data Mining-Methoden parallel oder sukzessive umfassen können. Die Analyseprozess-Komponente bindet im Anschluss an das Design eines Analyseprozesses die korrespondierenden anderen Komponenten automatisiert an und ermöglicht dem Anwender im Anschluss unmittelbar die Durchführung der Analyse.

12.1.7

Datenhaltungskomponente Da die eigentlichen Dateien extern über die Zugriffskomponente zugänglich gemacht werden, dient die Datenbank eines Data Mining-Systems i.d.R. nicht der redundanten Abspeicherung aller zu analysierenden Dateien. Abgespeichert werden vielmehr komplette Analyseprozesse und deren (Zwischen-)Ergebnisse. Da solche Zwischenergebnisse aber auch in zusammengeführten, gefilterten, aggregierten usw. Datenbeständen bestehen können, können sich in der Datenbankkomponente allerdings zumindest gewisse Teilmengen der entsprechenden Quelldaten finden.

12.2

Anwendung von Data Mining-Systemen Die Anwendung von Data Mining im Personalmanagement hat als ein neuerer, sich noch entwickelnder Bereich zu gelten. Teils werden Datenschutzbedenken gegenüber einem personalwirtschaftlichen Data Mining geäußert, weil damit bislang unbekannte Zusammenhänge in Personaldaten entdeckt werden können. Sehr häufig kann Data Mining allerdings auf der Basis vollständig anonymisierter bzw. pseudonymisierter Daten stattfinden, so dass keine personenbezogenen Daten im Sinne des BDSG verwendet werden müssen (vgl. Kap. 3). Mögliche Anwendungsszenarien im Personalmanagement umfassen dabei die Varianten ƒ Data Mining, ƒ Web Mining und ƒ Text Mining.

Data Mining

Generelle Anwendungen des Data Mining beziehen sich auf solche Situationen bei der Planung, Steuerung und Kontrolle des Personalbereichs, in denen erklärende Hintergrundinformationen und/oder prognostische Informationen notwendig sind. Immer dann, wenn die deskriptiv-historischen kennzahlenbasierten Informationen eines personalwirtschaftlichen OLAP (vgl. Kap. 11) um explikative oder prognostische Informationen angereichert werden sollen, bieten sich entsprechende Data Mining-Analysen an. Liefern OLAP-Analysen beispielsweise Hinweise auf die ver165

12

Data Mining-Systeme mehrte Fluktuation von »Leistungsträgern«, ist es mit Data Mining möglich, eventuelle Hintergründe und künftige Entwicklungen des Phänomens zu analysieren. In diesem Sinne reichert Data Mining die historisch-deskriptive Information konventioneller Analysen mit prognostisch-explikativer Information an. Data Mining ist damit kein Ersatz, sondern eine sinnvolle Ergänzung konventioneller personalwirtschaftlicher Datenanalyse und dürfte das breiteste Anwendungsszenario im Personalmanagement darstellen (vgl. vertieft Strohmeier & Piazza 2005).

Web Mining

Mit der zunehmenden Verbreitung eines e-HRM (vgl. dazu Kap. 2) wird auch ein personalwirtschaftliches Web Mining zunehmend möglich und aufschlussreich. Web Mining bedeutet dabei grundsätzlich die Übertragung der Methoden des Data Mining auf Daten des World Wide Web. Im Rahmen eines »Web Usage Mining« wird nach Mustern im Anwenderverhalten bei der Anwendung webbasierter Systeme (vgl. Kap. 28) gesucht. Etwa können mittels einer Click Stream-Analyse typische Folgen von Webseitenaufrufen durch die Anwender erkannt werden und so Aufschlüsse über Anwenderverhalten – etwa im Kontext eines Self Service-Konzeptes für Bewerber (vgl. Kap. 2 und 16) – gewonnen werden. Mittels eines »Web Content Mining« kann weiter nach interessierenden Inhalten von Dokumenten des World Wide Web gesucht werden. Beispielsweise kann im Rahmen der Personalbeschaffung so nach für das Unternehmen interessanten Seiten von Bewerbern oder Experten gesucht werden.

Text Mining

Analog zum Web Content Mining können mittels eines Text Mining beliebige Textdokumente auf mögliche Muster und Inhalte hin untersucht werden. Anwendungsszenarien bestehen etwa in der Erkennung und automatisierten Weiterleitung von e-Mails im Rahmen von Service Center-Konzepten (vgl. Kap. 2 und 27) oder in der Vorstrukturierung und Vorselektion von elektronischen Bewerbungen im Rahmen eines e-Recruiting (vgl. auch Kap. 16).

Verbreitung

Derzeit sind keine empirischen Untersuchungen zur Verbreitung von Data Mining-Systemen im Personalmanagement bekannt. Die Anwendung von Data Mining-Systemen dürfte allerdings erst im Beginn begriffen sein. Die zunehmende Verbreitung von Data Warehouse-Systemen im Personalmanagement (vgl. Kap. 5) mit entsprechenden Data Mining-Funktionalitäten bietet das Potenzial einer künftig weiteren Verbreitung dieser Analyseverfahren.

166

13

Personalabrechnungssysteme Personalabrechnungssysteme (Lohn- und Gehaltsabrechnungssystem, »Payroll System«) sind Anwendungen zur automatisierten personen- und sachbezogenen Abrechnung von Löhnen und Gehältern sowie weiterer auszahlungsrelevanter Größen wie etwa Reisespesen.

13.1

Architektur und Funktionalität von Personalabrechnungssystemen Personalabrechnungssysteme umfassen in der Datenhaltungsschicht üblicherweise die (Mitarbeiter-)Stammdaten, Bewegungsdaten sowie Abrechnungsdaten, in der Anwendungsschicht eine Brutto- und Nettolohnkomponente und eine Auswertungs- und Übermittlungskomponente sowie die obligatorische Anwenderschnittstelle (vgl. Abb. 13.1). Personalabrechnungssystem Anwenderschnittstelle Bruttolohnkomponente

Nettolohnkomponente

Analyse & Übermittlung

Bewegungsdaten

(Mitarbeiter-) Stammdaten

Abrechnungsdaten

BDE/PZE/...

Datenhaltungssysteme

Banksysteme FiBu-/KoRe-Systeme DEÜV/Meldewesen Data Warehouse

Abb. 13.1: Idealtypische Architektur von Personalabrechnungssystemen Die (Mitarbeiter-)Stammdaten-Datei dient der Speicherung feststehender abrechnungsrelevanter Mitarbeiterattribute. In der Bewegungsdaten-Datei werden abrechnungsrelevante Inputdaten, 167

13

Personalabrechnungssysteme die im Zeitablauf immer wieder neu entstehen, gespeichert. Auf der Grundlage dieser Daten werden Brutto- und Nettolohn berechnet und in der Abrechnungsdatenbank gespeichert. Eine Auswertungs- und Übermittlungskomponente erstellt die notwendigen internen und externen Auswertungen, Bescheinigungen, Meldungen und Managementinformationen und übermittelt diese teilweise an weitere interne und externe Systeme.

Mandantenfähigkeit

Personalabrechnungssysteme sind dabei i.d.R. mandantenfähig. Mandantenfähigkeit impliziert, dass auf demselben System mehrere Unternehmen(sbereiche) parallel abgerechnet werden können, ohne dass die jeweils abgerechneten Einheiten gegenseitig Einblicke in Daten, Abrechnungsergebnisse etc. haben. Mandantenfähigkeit verhindert, dass bei der Notwendigkeit einer physisch getrennten Abrechung verschiedener Organisationen bzw. Organisationseinheiten Systemlizenzen mehrfach vergeben werden und Systeminstallationen mehrfach durchgeführt werden müssen.

13.1.1

(Mitarbeiter-)Stammdaten Abrechnungsrelevante Stammdaten beziehen sich vorwiegend auf feststehende Mitarbeiterattribute. Neben solchen Mitarbeiterstammdaten werden Stammdaten aber auch für weitere abrechnungsrelevante Objekte wie etwa Finanzämter, Krankenkassen oder Banken gehalten. Stammdatensätze von Mitarbeitern werden dabei entweder aus anderen personaldatenhaltenden Systemen importiert oder sind im Personalabrechnungssystem neu anzulegen. Als Minimalvariante sind hier die »Muss«-Daten eines Mitarbeiters zu halten, die aufgrund gesetzlicher Vorgaben (wie z.B. die Versicherungsnummer) oder abrechnungstechnischer Gegebenheiten (wie z.B. der Beitragsgruppenschlüssel) bekannt sein müssen. Persönliche Daten beziehen sich auf Aspekte wie Name, Vorname, Geburtsdatum, Anschrift, Bankverbindung, Familienstand, Kinderzahl, Nationalität oder Konfession. Steuerrechtliche Daten umfassen z.B. die Steuerklasse, die Anzahl der Freibeträge sowie zuständige Gemeinde und Finanzamt. Sozialversicherungsrechtliche Daten beinhalten z.B. die Versicherungsnummer, Angaben zur Tätigkeit und zur Ausbildung, die ausgeübte Tätigkeit, den Beitragsgruppenschlüssel, Namen und Daten der Krankenkasse sowie den Versicherungsbeginn. Betriebsnotwendige Daten sind das Eintritts- bzw. Austrittsdatum, die tarifliche oder übertarifliche Eingruppierung, Zuordnungsmerkmale zur Kostenrechnung sowie der arbeitsvertragliche Status des Mitarbeiters (vgl. Schmeisser & Clermont 1999, 79).

168

13.1 Architektur und Funktionalität von Personalabrechnungssystemen

13.1.2

Bewegungsdaten Neben Stammdaten werden auch Bewegungsdaten für die Berechnung des Bruttolohnes eines Mitarbeiters benötigt, die in einer entsprechenden Datenbank abgespeichert werden. Bewegungsdaten umfassen alle im Zeitablauf anfallenden Daten, die abrechnungsrelevant sind und in unterschiedlicher Häufigkeit und Anzahl anfallen können. Analog zu den Stammdaten können auch Bewegungsdaten entweder aus anderen Systemen importiert werden oder sind manuell in das Personalabrechnungssystem einzupflegen. Klassischerweise zählen Zeit- und Leistungsdaten wie etwa »geleistete Arbeitsstunden« oder »produzierte Stückzahl« zu den abrechnungsrelevanten Bewegungsdaten. Welche konkreten Bewegungsdaten zu erheben und abzuspeichern sind, hängt allerdings zentral von der meist tarifvertraglich geregelten Entgeltform bzw. mehreren verschiedenen Entgeltformen ab, die mittels des Systems abgerechnet werden sollen.

Zeit- und Leistungsentgelt

Mit dem Zeit- und dem Leistungsentgelt liegen zwei verbreitete Gruppen von Entgeltkategorien vor: Bei Varianten des Zeitentgelts bildet die geleistete Arbeitszeit in Stunden, Tagen, Wochen oder Monaten das zentrale Bewegungsdatum. Entsprechend stellen Arbeitszeitmanagementsysteme den zentralen Lieferanten solcher Bewegungsdaten dar (vgl. Kap. 14). Varianten des Leistungsentgelts wie beispielsweise das Akkord- oder das Prämienentgelt machen die Entgelthöhe von der Ausprägung gewisser qualitativer und/oder quantitativer Leistungskennzahlen wie etwa »Stück/h« oder »Umsatz/Monat« abhängig. Entsprechend bilden Betriebsdatenerfassungssysteme (»BDE«-Systeme) sowie weitere interne Systemen mögliche Quellsysteme für den Import solcher abrechnungsrelevanter Bewegungsdaten.

13.1.3

Bruttolohnkomponente Auf der Basis solcher Stamm- und Bewegungsdaten ermittelt die Bruttolohnkomponente das Bruttoentgelt eines Arbeitnehmers. Das Bruttoentgelt wird dabei als die Summe aller Beträge, die dem Arbeitnehmer aufgrund des Arbeitsverhältnisses für eine festgelegte Abrechnungsperiode zustehen, definiert. Abb. 13.2 zeigt den generellen schematischen Ablauf der Bruttoentgeltermittlung. Grundsätzlich müssen für die Bruttoentgeltermittlung der erforderliche Input an Zeit- und Leistungsdaten, Informationen über stunden- oder tageweise Abwesenheiten, ein zeit- und leistungsunabhängiges Grundgehalt sowie sonstige Entgelte und Sachbezüge aus der Bewegungsdatenbank bereitgestellt werden. 169

13

Personalabrechnungssysteme Dateninput Bewertung

Umsetzung

Leistungsdaten

Zeitdaten

Bewertungsfaktoren

Abwesenheitsdaten

Grundgehaltsdaten

Bewertung

Sachbezugsdaten Bewertung

Sachbezugswerte

Entgeltfindung

Bruttoentgelt

Bruttoaufriss

Lohnsteueranteile

Sozialvers.anteile

Pfändungsanteile

Vermögensbildungsanteile

Abb. 13.2: Schema der Bruttoentgeltermittlung (nach Hentschel & Kolzter 2002, 57) Dies hat »abrechnungsperiodengerecht« zu erfolgen, da Verspätungen rückwirkende Korrekturen nach sich ziehen können. Darauf folgend werden diese Inputdaten einer Bewertung unterzogen. So sind zunächst Arbeitsleistung und -zeit nach den jeweils gültigen gesetzlichen, tariflichen und betrieblichen Vergütungsregeln zu bewerten. Weit verbreitet wird beispielsweise in der Nacht abgeleistete Arbeitszeit höher bewertet als Tagarbeit. Weiter wird überprüft, ob dem Arbeitnehmer eventuelle Abwesenheiten zu vergüten sind oder nicht. Zu bezahlende Abwesenheiten wie Urlaub oder (die ersten Wochen einer) Krankheit können dabei nach dem Durchschnittsprinzip oder dem Ausfallprinzip bewertet werden. Beim Durchschnittsprinzip werden Lohn und Gehalt nach dem durchschnittlichen arbeitstäglichen Verdienst in einem festgelegten Zeitraum bestimmt. Beim Ausfallprinzip wird dagegen festgestellt, was dem Arbeitnehmer für die Abwesenheit zu zahlen gewesen wäre, wenn er gearbeitet hätte. Hat der Mitarbeiter darüber hinaus nicht-monetäre Sachleistungen erhalten, wie beispielsweise das Überlassen einer Werkswohnung, sind auch diese zu erfassen und in ihrer Höhe zu bewerten (vgl. Hager 1995, 11). So bewertete Größen werden dann in einem weiteren Schritt in konkrete Entgelthöhen umgesetzt. Z.B. wird geleistete Arbeitszeit mit einem bestimmten »Geldfaktor« multipliziert, um die Entgelthöhe zu bestimmen. Zusammen mit den Sachwertbezügen kann so ein Bruttoentgelt be170

13.1 Architektur und Funktionalität von Personalabrechnungssystemen rechnet werden. Die Bruttoentgeltberechnung mündet meist in einen »Bruttoaufriss«, der lohnsteuerpflichtige, sozialversicherungspflichtige, pfändbare und vermögensbildungsrelevante Bestandteile aufteilt. Auch die so generell dargestellte Bruttolohnermittlung variiert allerdings je nach Entgeltform. Beispielsweise würden die Leistungskomponenten bei der Abrechnung eines reinen Zeitentgelts notwendigerweise entfallen.

13.1.4

Nettolohnkomponente Basierend auf ermittelten Bruttoentgelten berechnet die Nettolohnkomponente in einem zweiten Schritt die tatsächlich auszuzahlenden Bezüge. Die Nettolohnermittlung erfolgt dabei in zwei Schritten: In einem ersten Schritt werden die steuerlichen Abzüge (Lohn- und Kirchensteuer, Solidaritätszuschlag) des Mitarbeiters sowie die Arbeitnehmeranteile zur Sozialversicherung (Kranken-, Pflege-, Renten- und Arbeitslosenversicherung) berechnet. Die Kürzung des Bruttoentgelts um diese Abzüge ergibt eine Zwischensumme, die als »Nettoergebnis 1« bezeichnet wird. In einem zweiten Schritt werden weitere Abzüge wie etwa Pfändungen, aber auch zusätzliche, nicht zum Bruttoentgelt gehörende Zahlungen, wie beispielsweise freiwillige vermögensbildende Leistungen berechnet. Dieser zweite Verrechnungsschritt mündet im konkreten Auszahlungs- bzw. Überweisungsbetrag, dem »Nettoergebnis 2« (vgl. Oppermann 1989, 418ff.).

Steuerliche Abzüge

Das Einkommenssteuergesetz (EStG) bildet in Verbindung mit dem Kirchensteuergesetz (KiStG) und dem Solidaritätszuschlagsgesetz (SolZG) die gesetzliche Grundlage für die vom System zu berechnenden steuerlichen Abzüge. Vor der Berechnung der steuerlichen Abzüge muss geprüft werden, in welchem Umfang das ermittelte Bruttoentgelt steuerpflichtig ist. Der steuerlich relevante Arbeitslohn umfasst alle Einnahmen, die einem Arbeitnehmer aus einem gegenwärtigen oder früheren Dienstverhältnis zufließen. Dem Lohnsteuerabzug unterliegen alle Einkünfte aus nichtselbstständiger Arbeit, unabhängig davon, ob es sich um Geldbeträge oder Sachzuwendungen wie z.B. freie Verpflegung handelt. Dabei ist es bedeutungslos, ob es sich um einmalige oder laufende Einkünfte handelt, ob ein Rechtsanspruch auf sie besteht oder unter welcher Bezeichnung und in welcher Form sie gewährt werden (vgl. Hentschel & Kolzter 2002, 58). Die Summe der lohnsteuerpflichtigen Bezüge bildet die Bemessungsgrundlage für die Errechnung der Lohn- und Kirchensteuer sowie des Solidaritätszuschlages.

171

13

Personalabrechnungssysteme

Sozialversicherungsbeiträge

Eine zweite Gruppe gesetzlicher Abzüge vom Bruttoentgelt stellen die Beiträge zur Sozialversicherung dar. Basis für die Berechnung der Sozialversicherungsbeiträge sind die beitragspflichtigen Einnahmen, die Beitragssätze der einzelnen Versicherungszweige und der Zeitraum (Beitragszeit). Das Bruttoentgelt wird dabei nicht in unbeschränkter Höhe, sondern nur bis zu bestimmten Höchstgrenzen, den so genannten Beitragsbemessungsgrenzen, für die Beitragsberechnung herangezogen. Bei der Bestimmung der Beitragssätze ergeben sich nach Art der Sozialversicherung Unterschiede: Die Beitragssätze der Krankenkassen werden kassenindividuell festgelegt. Bei der Renten- und Arbeitslosenversicherung bestimmt der Gesetzgeber die einzelnen Beitragssätze (vgl. Berning 1995, 69f.). Die Gesamtsumme der Beiträge zur Kranken-, Pflege-, Renten- und Arbeitslosenversicherung wird als Gesamtsozialversicherungsbeitrag bezeichnet. Er spaltet sich in Arbeitnehmer- und Arbeitgeberanteil auf. Bei den o.a. Versicherungen tragen Arbeitgeber und Arbeitnehmer jeweils die Hälfte des Beitrags. Die Beiträge werden i.d.R. prozentual aus den beitragspflichtigen Einnahmen des Arbeitnehmers ermittelt: Zunächst wird der auf den Arbeitnehmer entfallende Teil des Beitrages errechnet. Der Gesamtsozialversicherungsbeitrag ergibt sich dann durch die Verdopplung des gerundeten Arbeitnehmeranteils. Für die ebenfalls zu berechnende Unfallversicherung gelten besondere Bestimmungen. Versicherungspflichtig ist hier das Unternehmen, nicht der einzelne Arbeitnehmer. Versicherungsträger sind die Berufsgenossenschaften. An diese sind die Beiträge abzuführen, wobei der Arbeitgeber ohne Beteiligung des Arbeitnehmers dafür aufzukommen hat. Die Höhe der Beiträge ergibt sich aus der Gefahrenklasse der Branche sowie aus der an die Arbeitnehmer ausgezahlten Lohnsumme (vgl. Hager 1995, 34).

Pfändungsabzüge

Ein Pfändungsabzug bildet eine dritte mögliche Größe der Nettoentgeltermittlung. Hat ein Mitarbeiter finanzielle Verpflichtungen z.B. gegenüber Unterhaltsberechtigten oder anderen Gläubigern und erfüllt diese nicht, können die Gläubiger mit Hilfe eines Gerichtsurteils die Lohnforderung des Mitarbeiters pfänden lassen. Durch einen Pfändungs- und Überweisungsbeschluss eines Gerichtes ist der Arbeitgeber verpflichtet, einen Teil des Arbeitsentgelts nicht an den Mitarbeiter, sondern direkt an den Gläubiger auszuzahlen. Unter Beachtung der unterschiedlichen Existenzminima für Sach- und Unterhaltspfändungen muss der Arbeitgeber das pfändbare Arbeitseinkommen feststellen. Bei mehreren Pfändungsbeschlüssen ist der zeitliche Eingang des Be-

172

13.1 Architektur und Funktionalität von Personalabrechnungssystemen schlusses beim Arbeitgeber für die Berücksichtigung entscheidend (vgl. Schmeisser & Clermont 1999, 94). Weitere Abzüge

Im Rahmen der weiteren Berechnung sind oft eine Reihe von weiteren Abzügen und Auszahlungen als einmalige oder laufende Beträge zu berücksichtigen: tarifliche Vermögensbildung und Eigenleistung, Kindergeld, Kurzarbeitergeld, Winterbauhilfe, Reisekostenvergütungen, innerbetriebliche Forderungen wie Mieten, Vorschüsse, Arbeitgeberdarlehen, Mittagessen, Lohn- und Gehaltsabtretungen, Sammelinkassoverfahren wie Lebensversicherungsbeiträge, Gewerkschaftsbeiträge, Beiträge zu Zusatzversorgungskassen etc. Bezüglich dieser Positionen ist die prioritätengerechte Verrechnung nach Rang und Wirksamkeitsdatum unter Berücksichtigung des gesetzlich festgelegten Existenzminimums zu berücksichtigen.

Simulation und Rückrechnung

Diese (mögliche) Vielfalt an zu berücksichtigenden Einzelpositionen führt zu einer oft unterschätzten Komplexität von Nettoabrechnungsvorgängen. Als eine Folge hiervon weisen viele Abrechnungssysteme die Möglichkeit auf, vor der eigentlichen Abrechnung Simulationsläufe der Abrechnung zu fahren, um mögliche Abrechnungsfehler zu entdecken und zu korrigieren. Ebenso verfügen die Systeme regelmäßig über Rückrechnungsmöglichkeiten, die eine nachträgliche Korrektur der Abrechnung zulassen, wenn Inputdaten zum Abrechnungszeitpunkt nicht verfügbar oder nicht korrekt waren. Aufgetretene Über- oder Unterbezahlungen werden dann im Folgemonat ausgeglichen.

13.1.5

Abrechnungsdatei Die Abrechnungsdatei speichert im Anschluss an die Brutto- und Nettoabrechnung die Abrechnungspositionen und -ergebnisse für Zwecke der Auswertung, Dokumentation und Übermittlung. Speziell das Steuer- und das Sozialversicherungsrecht verpflichten den Arbeitgeber zur Führung von Lohnunterlagen für jeden Beschäftigten und jedes Kalenderjahr. Zu den Lohnunterlagen gehören alle Dokumente, die Aufschluss geben über individuelle Abrechnungsdaten des Arbeitnehmers, die Zusammensetzung des monatlichen Arbeitsentgelts, die ordnungsgemäße Erstattung der Meldungen, die Versicherungspflicht bzw. -freiheit und die Kassenzugehörigkeit des Arbeitnehmers (vgl. Hentschel & Kolzter 2002, 89f.). Zwischenzeitlich werden solche Lohnunterlagen kaum mehr papierbasiert geführt, sondern exklusiv in elektronischer Form in der Abrechnungsdatenbank gehalten. Weiter erfordert auch das Melderecht, das Bundesstatistikgesetz, das Ge173

13

Personalabrechnungssysteme setz über Lohnstatistik oder die Verordnung zur Durchführung einer Arbeitskostenerhebung das Halten vielschichtiger Abrechnungsdaten in der Abrechnungsdatenbank.

13.1.6

Analyse- und Übermittlungskomponente Die Analysekomponente dient der gezielten Auswertung von Daten der Abrechnungsdatenbank und deren Übermittlung an weitere interne und externe Systeme. Zentrale Varianten dienen ƒ der Zahlung von Entgelten, ƒ der Verbuchung der Abrechnungsergebnisse, ƒ der Durchführung des Meldewesens, ƒ dem Abführen gesetzlicher Abzüge, ƒ dem Erstellen von Ausdrucken und Bescheinigungen sowie ƒ der internen Managementinformation.

Entgeltzahlung

Grundlegender Zweck der Personalabrechnung ist die Zahlung von Entgelten an die Mitarbeiter. Auf Basis entsprechender Auswertungen erfolgen Zahlungen i.d.R. bargeldlos durch eine Überweisung auf das Lohn- oder Gehaltskonto des Mitarbeiters. Hierbei können zwei Varianten unterschieden werden. Eine erste Variante besteht im Ausdruck von Überweisungsvordrucken, die mit entsprechenden Begleitlisten an die Kreditinstitute gehen, die mit der Abwicklung der Zahlung beauftragt sind. Eine zweite Variante stellt der beleglose Zahlungsverkehr dar (»Data Clearing«), bei dem die auszuzahlenden Beträge auf Datenträger überspielt werden, die vom Unternehmen an die entsprechenden Kreditinstitute weitergeleitet, oder bei dem die Daten direkt online übermittelt werden. Diese nehmen dann die Überweisung auf die entsprechenden Konten vor. Dabei sind die Vorgaben der Kreditinstitute bezüglich Form und Inhalt des Datenträgers zu beachten.

Verbuchung

Weiterhin bilden die Ergebnisse der Personalabrechnung auch Eingangsgrößen für die Kostenrechnung und Finanzbuchhaltung. Entsprechende Auswertungen dienen dann der Verbuchung der Abrechnungsergebnisse. Die Finanzbuchhaltung zeichnet Zahlungen und Verbindlichkeiten einer Abrechnungsperiode auf, wobei nicht die einzelnen Lohn- und Gehaltsbestandteile individueller Mitarbeiter interessieren, sondern nach bestimmten Kriterien aggregierte Werte. Dabei findet eine Orientierung an dem Kontenplan des Unternehmens statt, bei der den jeweiligen Lohnarten (z.B. Gesamtlohn, Mehrarbeitsvergütungen, Urlaubsvergütungen) bestimmte Konten zugeordnet werden. In der Kos-

174

13.1 Architektur und Funktionalität von Personalabrechnungssystemen tenrechnung findet eine Erfassung und Verteilung der im betrieblichen Leistungsprozess angefallenen Kosten statt. Für die Kostenrechnung ist von Interesse, wo und wofür die einzelnen Kosten angefallen sind. Anhand der in den Stammdaten erfassten Kostenstellen können die angefallenen Personalkosten vom System entsprechend zugeordnet werden. Meldewesen

Die Notwendigkeit eines Meldewesens resultiert aus der »Verordnung über die Erfassung und Übermittlung von Daten für die Träger der Sozialversicherung (DEÜV)« (vgl. Kap. 3). Diese Verordnung verpflichtet den Arbeitgeber zu konkret definierten Meldungen an die Sozialversicherungsträger. Meldungen können dabei einmalig anfallen, wie etwa die An- oder Abmeldung von Mitarbeitern und die Meldung von einmalig gezahltem Arbeitsentgelt, oder aber regelmäßig wie etwa umfassende Jahresmeldungen oder Meldungen von Arbeitsentgelt. Die Verordnung normiert, dass Meldungen auf dem Wege elektronischer Datenübertragung stattzufinden haben und entsprechende Maßnahmen zu Datensicherheit und Datenschutz zu treffen sind. Da Personalabrechnungssysteme die meist verbreitete Systemkategorie sind und waren, werden solche Meldungen historisch bedingt regelmäßig von Personalabrechnungssystemen übernommen. Entsprechend sind die für die jeweiligen Meldungen nötigen Daten von der Analysekomponente bereitzustellen und in den vorgegebenen Datenformaten zu übermitteln. Zur Sicherstellung der korrekten Durchführung der Abrechnung, der Erstellung der geforderten Meldungen und der technischen Sicherheit haben sich die Spitzenverbände der gesetzlichen Krankenversicherungen auf ein Prüfverfahren entsprechender Personalabrechnungssysteme geeinigt, das nach erfolgreicher Absolvierung zu einer Zertifizierung des Systems (»GKV Zertifikat« bzw. »ITSG-Zertifikat«) führt (www.gkv-ag.de).

Gesetzliche Abzüge

Auch das Abführen der gesetzlichen Abzüge ist eine gesetzlich geregelte Aufgabe. Die bei der Abrechnung ermittelten Abzüge sind daher per Analysekomponente zu ermitteln und an die entsprechenden Stellen abzuführen. Dies gilt für die Arbeitnehmerund Arbeitgeberanteile wie für die Beiträge, die der Arbeitgeber allein zu tragen hat. Der Gesamtsozialversicherungsbeitrag wird in einem Umlageverfahren zunächst an die (Kreditinstitute der) jeweiligen Krankenkassen der Mitarbeiter abgeführt. Diese leitet den Renten- und Arbeitslosenversicherungsbeitrag an die Rentenversicherungsträger und die Bundesagentur für Arbeit weiter. Weiterhin ist ein Beitragsnachweis mit den einzelnen Beschäftigten und den vom Arbeitgeber einbehaltenen Beiträgen zu erstel175

13

Personalabrechnungssysteme len (vgl. Schmeisser & Clermont 1999, 97). Weitere Auswertungen betreffen die Summe der einbehaltenen Lohnsteuer, der Kirchensteuer und des Solidaritätszuschlags, die der Arbeitgeber der Finanzverwaltung mitzuteilen und einen entsprechenden Betrag an das zuständige Finanzamt abzuführen hat.

Bescheinigungen

Ebenso ist die Erstellung von Ausdrucken und Bescheinigungen eine Aufgabe der Analysekomponente. Entsprechend können Verdienstabrechnungen für die Mitarbeiter ausgegeben werden. Ebenso werden zahlreiche Bescheinigungen wie Lohnsteuerbescheinigungen, allgemeine Entgeltbescheinigungen, Arbeitsbescheinigungen, Verdienstbescheinigungen für Angehörige oder Verdienstbescheinigungen zum Antrag auf Wohngeld auf der Basis der Analysekomponente erstellt.

Informationen

Schließlich bietet die Analysekomponente zentrale Informationen für das Management. Mit den dargestellten Auswertungsanforderungen verfügen Personalabrechnungssysteme regelmäßig über umfangreiche personalwirtschaftliche Datenbestände zu Personalbeständen, Personalveränderungen oder Personalkosten. Zusätzlich zählen diese Datenbestände aufgrund der Wichtigkeit einer korrekten und zeitgenauen Abrechnung zu den vollständigsten und aktuellsten im gesamten Unternehmen. Dies prädestiniert Personalabrechnungssysteme als Quelle für Managementinformationen (vgl. Ulmer 2004, 202). Entsprechend bieten Analysekomponenten datenbanktypische Auswertungsfunktionen der Erstellung von Abfragen (»Queries«) und Berichten (»Reports«) (vgl. auch Kap. 4). Aus denselben Gründen eignen sich Personalabrechnungssysteme i.d.R. gut als Quellsysteme für ein personalwirtschaftliches Data Warehouse-System (vgl. Kap. 5).

13.2

Anwendung von Personalabrechnungssystemen Die Durchführung einer Personalabrechnung ist für jedes Unternehmen ab einem abhängig beschäftigten Mitarbeiter in funktionaler und gesetzlicher Hinsicht zwingend. Entsprechend wird – intern oder extern – für jedes Unternehmen mit abhängig beschäftigten Mitarbeitern eine Abrechnung durchgeführt. Der hohe Grad an Strukturierbarkeit, der quantitative Umfang und das zyklische Auftreten der Abrechnungsaufgabe machen sie zu einem idealen Kandidaten für eine informationstechnische Unterstützung. Entsprechend dürften Personalabrechnungssysteme sowohl die älteste als auch die am weitesten verbreitete personalwirtschaftliche Systemkategorie darstellen. Da die Abrechnung regelmäßig nicht zu den strategisch bedeutenden Kernaktivitäten

176

13.2 Anwendung von Personalabrechnungssystemen des Personalmanagement gezählt wird, eignet sie sich allerdings auch besonders für Varianten des Application Service Providing und Outsourcing. Entsprechend besteht ein klassischer Dienstleistungsbereich der Personalarbeit seit langem in der Durchführung von Abrechnungen. Neben Rechenzentren sind klassischerweise auch Steuerberater verbreitete Anbieter von systemgestützten Personalabrechnungsdienstleistungen insbesondere für Kleinund Mittelbetriebe. Internetbasierte Lösungen ermöglichen inzwischen die nahezu beliebige Aufteilung der im Rahmen der Abrechnung anfallenden Aufgaben zwischen HR-Mitarbeitern und Mitarbeitern des Dienstleistungsunternehmens. Für Aufgaben wie Stammdatenpflege oder Ausdruck von Verdienstbescheinigungen lassen sich mittlerweile auch browserbasierte Self Service-Varianten nachweisen (vgl. Kap. 2 und 28). Die Potenziale von Personalabrechnungssystemen für die Personalarbeit liegen im Wesentlichen in der Rationalisierung des Abrechnungsvorganges. Der zentrale Vorteil liegt entsprechend darin, die Abrechnung grundsätzlich deutlich schneller, kostengünstiger und wohl auch fehlerfreier durchführen zu können. Allerdings dürften chronische tarifvertragliche Änderungen und die zunehmende Komplexität von Abrechnungsprozeduren, die gerade weil es Unterstützung durch Personalabrechnungssysteme gibt, erst möglich werden, die generellen Rationalisierungsfolgen zumindest teilweise konterkarieren. So dürften Personalabrechnungssysteme die Systemkategorie mit den vermutlich häufigsten Versionswechseln (»Releasewechsel«) sein und damit zu entsprechenden Kosten führen. Insbesondere im Rahmen integrierter Anwendungen wie etwa ERP-Systemen (vgl. Kap. 23) ziehen tarifvertragsbedingte Versionswechsel der Personalabrechnungsmodule nicht selten auch neue Versionen weiterer Module nach sich. Auch dürfte die mittlerweile erreichte Komplexität von Abrechnungsvorgängen nur deswegen tragbar sein, weil sie durch entsprechende Systeme bewältigt werden kann. Verbreitung

Empirische Untersuchungen zeigen für Deutschland entsprechend Diffusionsgrade interner Abrechnungssysteme nahe 90% (vgl. Kabst & Giradinni 2005, 41). Damit korrespondierend existiert auch ein breites Angebot an Abrechnungssystemen, das inzwischen nahezu jedes Entgeltmodell, jede Branche und jeden Entgelttarifvertrag abdeckt. Die Personalabrechnung ist und bleibt damit die »klassische« Anwendung der Informationstechnik im Personalmanagement.

177

14

Arbeitszeitmanagementsysteme Arbeitszeitmanagementsysteme ([Personal-]Zeiterfassungssysteme [PZE], Arbeitszeitmanagementsysteme, Personaldatenerfassungssysteme, »[Time and] Attendance [Management] Systems«) sind Anwendungen zur elektronischen Erfassung, Bewertung, Planung und Kontrolle von personenbezogenen An- und Abwesenheitszeiten (vgl. Mülder 1993, 25).

14.1

Architektur und Funktionalität von Arbeitszeitmanagementsystemen Der idealtypische Aufbau eines Arbeitszeitmanagementsystems besteht im Kern aus Datenbankkomponenten für Personalstamm, Zeitmodelle und Zeitkonten, Komponenten Authentifizierung, Zeiterfassung, Zeitplanung, Zeitauswertung und Zeitbewertung sowie einer Anwenderschnittstelle. Arbeitszeitmanagementsystem Anwenderschnittstelle

Sperrelement/ Alarmsystem Terminal Browser Telefonie

Zutrittsmanagement

Planung

Bewertung

Authentifizierung

Erfassung

Analyse

Personalstamm

Zeitmodelle

Zeitkonten

Personalabrechnung

Personaleinsatzplanung

Abb. 14.1: Idealtypische Architektur von Arbeitszeitmanagementsystemen Diese Grundkomponenten werden teils um Zusatzkomponenten wie eine Zutrittskontrollkomponente ergänzt (vgl. Abb. 14.1). 179

14

Arbeitszeitmanagementsysteme

Komponenten

Zunächst ermöglicht die Planungskomponente die Generierung betriebsindividueller Arbeitszeitmodelle, die in einer entsprechenden Datei abgelegt werden. Die Authentifizierungskomponente dient in Interaktion mit der Mitarbeiterstammdatei der eindeutigen Identifikation von Mitarbeitern. Die Erfassungskomponente erfasst die Arbeitszeiten, die auf korrespondierenden Zeitkonten abgelegt werden. Die Analysekomponente erlaubt die Erstellung arbeitszeitbezogener Abfragen und Berichte. Die Bewertungskomponente klassifiziert im Vorfeld der Personalabrechnung verschiedene Kategorien von Arbeitszeiten. Eine fakultative Zutrittskomponente dient der Steuerung, Protokollierung und Auswertung von Zutritten zu bestimmten Unternehmensbereichen. Weitere fakultative Zusatzmodule können der Erfassung, Verwaltung und Abrechnung von Betriebsdaten, Projektzeiten sowie Tank- und Kantinendaten dienen.

Verteilte Systeme

Arbeitszeitmanagementsysteme können dabei als verteilte Systeme organisiert sein. Die Anwendung wird dabei auf mehrere Hardwarekomponenten aufgeteilt. Insbesondere für die Authentifizierung der Mitarbeiter und die Erfassung der Buchungen kommen zusätzliche, meist proprietäre Hardwarekomponenten an den Ein- und Ausgängen des Unternehmens zum Einsatz. Solche Lese- und Erfassungsgeräte werden i.d.R. als (Zeiterfassungs)-»Terminals« bezeichnet. Bei verteilten Anwendungen können Teile der dargestellten Systemkomponenten, insbesondere der Authentifizierungskomponente, der Erfassungskomponente sowie der Zeitkonten, dem Terminal zugeordnet sein. Die einzelnen Hardund Softwarekomponenten wirken dann in integrierter Weise wie ein einheitliches System zusammen.

14.1.1

Datenbankkomponente Die Datengrundlage eines Arbeitszeitmanagementsystems bildet eine Datenbankkomponente, die regelmäßig Personalstamm-, Zeitmodell- und Zeitkontendateien umfasst.

Personalstamm

Für alle Mitarbeiter, die ihre Arbeitszeit über das Arbeitszeitmanagementsystem erfassen, ist zunächst ein Personalstammdatensatz gespeichert. Dieser beinhaltet Informationen wie Personalnummer, Name, Abteilung, Kostenstelle, Mitarbeiterausweisnummer, etc., das zugeordnete Arbeitszeitmodell, sowie ggf. identifizierende Mitarbeitermerkmale wie Fingerabdrücke, Netzhautstrukturen o.ä.

Arbeitszeitmodelle Als Soll-Vorgabe für die Anwesenheit von Mitarbeitern dienen Arbeitszeitmodelle wie etwa »Gleitzeit«, »Vollzeit«, »Teilzeit« oder 180

14.1 Architektur und Funktionalität von Arbeitszeitmanagementsystemen »Flexible Schichtarbeit«. Solche betriebsindividuellen Arbeitszeitmodelle werden als Zeitstammdaten in einer Datei abgelegt und mit entsprechenden Personalstammdatensätzen verknüpft. Zeitkonten

Die eigentlichen zeitwirtschaftlichen (Bewegungs-)Daten wie »Kommt«-Zeiten oder »Geht«-Zeiten, die daraus zu berechenden An- und Abwesenheitszeiten sowie nachträglich manuell vorgenommene Korrekturen der Buchungen werden auf verschiedenen Zeitkontendateien abgelegt. Die Buchung auf ein spezielles Zeitkonto erfolgt dabei in Abhängigkeit von der Art der vorgenommenen Zeitbuchung. So werden im Fall von Gleitzeit bspw. Unterbrechungszeiten auf das Konto »Nicht verrechnete Zeiten« gebucht, während die reguläre Arbeitszeit auf das Zeitkonto »Gleitzeit« und die Mehrarbeitszeit auf das Konto »Zuschläge« gebucht wird. Weiterhin wird ein Zeitkonto für den Fehlzeitanspruch »Urlaub« sowie für sonstige Fehlzeiten geführt (vgl. Mülder & Störmer 2002, 242ff.).

14.1.2

Authentifizierungskomponente Über die Authentifizierungskomponente werden Mitarbeiter identifiziert und auf ihre Berechtigung zur Zeiterfassung hin überprüft. Zur Identifikation und Authentifizierung existieren unterschiedliche Vorgehensweisen. Insbesondere können ƒ die Authentifizierung über Datenträger, ƒ die biometrische Authentifizierung und ƒ PIN- oder Passwort-Authentifizierung unterschieden werden (vgl. Mülder & Störmer 2002).

Authentifizierung Bei der Authentifizierung über Datenträger werden die Identifiüber Datenträger kationsdaten eines Mitarbeiters über einen physischen Datenträger der Authentifizierungskomponente übergeben. Unter die physischen Datenträger zur Authentifizierung fallen z.B. Mitarbeiterausweis, Datenspeicherschlüssel, »Transponder«- oder »Touch Memory«-Techniken. Sie können neben der Authentifizierung zur Zeiterfassung auch zur bargeldlosen Bezahlung, Erfassung von Tank- und Kantinendaten, zur Betriebsdatenerfassung oder zur Zutrittskontrolle verwendet werden. Entsprechend der unterschiedlichen Anwendungen sind auch unterschiedliche Daten auf dem Datenträger gespeichert (Mülder & Störmer 2002, 128ff.). Zur Durchführung der Authentifizierung mittels Datenträger werden zusätzliche Hardware-Komponenten zur Erfassung benötigt. Zur Identifikation eines Mitarbeiters werden die IdentifikationsDaten auf dem Datenträger am Terminal eingelesen und mit den im Personalstamm des Arbeitszeitmanagementsystems gespei181

14

Arbeitszeitmanagementsysteme cherten Daten abgeglichen und auf Berechtigung zur Zeiterfassung geprüft. Nach erfolgreichem Abgleich kann der Mitarbeiter zur Zeiterfassung übergehen. Im Falle des Mitarbeiterausweises erfolgt etwa der Abgleich der Ausweisnummer auf dem Ausweis mit der im Personalstamm des Zeitwirtschaftsystems hinterlegten Ausweisnummer. Zur Ausgestaltung physischer Datenträger bieten sich zahlreiche Methoden an. Generell kann zwischen der kontaktlosen und kontaktbehafteten Authentifizierung unterschieden werden. In ersterem Fall werden die Identifikationsdaten über verschiedene Techniken der berührungslosen Datenübertragung an das Lesegerät des Arbeitszeitmanagementsystems übermittelt. Eine Technik ist die Übertragung über elektromagnetische Felder, die so genannte Radio Frequency Identification (»RFID«). Aber auch die Codierung der Identifikationsdaten mittels Barcode auf einem Mitarbeiterausweis ermöglicht eine kontaktlose Identifikation über einen Scanner. Zur kontaktbehafteten Identifikation zählt dagegen z.B. die Ausweiscodierung mittels Magnetstreifen oder aber die Speicherung der Identifikationsdaten mittels eines kontaktbehafteten Chips, wobei die Daten über einen Einsteck- oder Durchzugsleser am Terminal an das Arbeitszeitmanagementsystem übermittelt werden.

Biometrische Authentifizierung

182

Die biometrische Authentifizierung erfolgt über physiologische Attribute von Mitarbeitern wie den Fingerabdruck, die Netzhaut des Auges, das Gesicht, die Hand, die Stimme oder auch verhaltensabhängige Merkmale wie den Schreibrhythmus oder die Unterschrift einer Person (vgl. Krause 2005). Auch hier sind zur Authentifizierung zusätzliche proprietäre Hardwarekomponenten notwendig. Je nach Identifikationstechnik werden technische Geräte eingesetzt, die z.B. über optische Sensoren die Fingerabdrücke oder über Infrarot mittels einer Kamera das von der Netzhaut reflektierte Muster aufnehmen können. Aufgrund der Aufwändigkeit des Verfahrens stellen biometrische Authentifizierungsgeräte die kostenträchtigste Variante dar. Der sich anschließende Abgleich mit den Referenzdaten kann auf zwei Wegen erfolgen. Zum einen können die Daten mit den im Personalstamm des Arbeitszeitmanagementsystems gespeicherten Referenzdaten verglichen und auf Berechtigung überprüft werden. Dies kann jedoch zu langen Abfragezeiten führen, da sich zur Zeiterfassung viele Mitarbeiter zur gleichen Zeit am System authentifizieren wollen. Um dieses Problem zu umgehen, können die Referenzdaten als Variante auch per Datenkompression auf einem Datenträger gespeichert werden, und der gemeinsame Einsatz von biometri-

14.1 Architektur und Funktionalität von Arbeitszeitmanagementsystemen scher Erkennung und Datenträger ermöglicht die Authentifizierung am Arbeitszeitmanagementsystem. Schließlich kann die Authentifizierung auch über die Persönliche PIN / PasswortAuthentifizierung Identifikationsnummer (»PIN«) oder Passwort erfolgen. Dieses Verfahren ermöglicht die Identifikation sowohl über Buchungsterminals als auch über Self Service-Systeme am Arbeitsplatz oder mittels mobiler Endgeräte. Der Mitarbeiter identifiziert sich am Arbeitszeitmanagementsystem durch Eingabe der PIN oder des Passwortes. Bei der Verwendung von (Mobil-)Telefonen zur Zeitbuchung ist teilweise auch eine Spracheingabe von PIN oder Passwort möglich (vgl. auch Kap. 26). Sicherheit

Die vorgestellten Verfahren der Authentifizierung unterscheiden sich u.a. in Sicherheitsaspekten. So gilt die Datenträgeridentifikation als relativ unsicher, da ein verloren gegangener Datenträger von beliebigen nicht berechtigten Personen verwendet werden kann. Auch Passwörter oder »PIN« können von unberechtigten Personen nach einer Ausspähung verwendet werden und erlauben demnach keine sichere Authentifizierung eines Mitarbeiters. Entsprechend gilt das biometrische Verfahren mit direkter Erkennung der individuellen physiologischen oder verhaltensabhängigen Merkmale als relativ sicheres Verfahren zur Authentifizierung einer Person, das allerdings teilweise Akzeptanzprobleme bei den Mitarbeitern aufweist.

14.1.3

Zeiterfassungskomponente Nach erfolgreicher Authentifizierung übernimmt die Zeiterfassungskomponente die Speicherung der durch die Mitarbeiter oder andere Personen veranlassten Zeitbuchungen. Weiterhin werden hier auch Fehlzeiten aufgrund von Krankheiten, Abwesenheit aufgrund von Urlaub oder Weiterbildung erfasst (vgl. Scherf 2005b, 27ff.).

Arten

Die konkrete Buchung der Zeit erfolgt in Abhängigkeit von den eingesetzten Verfahren zur Authentifizierung unterschiedlich. Bei Verwendung von Datenträgern oder biometrischen Verfahren erfolgt die Buchung in einem Schritt mit der Authentifizierung. D.h. dass mit dem einmaligen Einstecken einer Chipkarte in einen Belegleser in unmittelbarem Anschluss an die Authentifizierung auch die entsprechende Zeit-Buchung erfolgt. Teilweise existieren auch Kontaktbildschirme (»Touch-Screens«). Werden Arbeitsplatzrechner oder (Mobil-)Telefone verwendet, ist auch die Eingabe über Tastatur weit verbreitet. Für die telefonische Zeiter-

183

14

Arbeitszeitmanagementsysteme fassung finden sich darüber hinaus auch Systeme, die Buchungen per Spracheingabe ermöglichen.

Träger

Die Zeiterfassung kann dabei durch unterschiedliche Personen durchgeführt werden. Generell wird unterschieden, ob der betreffende Mitarbeiter selbst seine Zeiten erfasst (Selbsterfassung) oder aber der Vorgesetzte oder ein Zeitbeauftragter diese Aufgabe übernimmt (Fremderfassung).

Speicherung

Darüber hinaus ist eine Unterscheidung der Zeiterfassung in Online- oder Offline-Erfassung möglich. Beide Varianten hängen von der Realisierung des Zeitwirtschaftsystems als verteiltes System ab. Bei der Online-Variante werden die Benutzereingaben direkt auf die korrespondierenden Zeitkonten gebucht. Bei der Offline-Variante hingegen erfolgt die Zwischenspeicherung der Zeitbuchung auf einer separaten Datenbank des Terminals, und ein periodischer Upload der Zeitbuchungsdaten vom Terminal übergibt die Buchungsdaten an die Datenbankkomponente.

Umfang

Hinsichtlich der Erfassungsform kann zwischen der Positiv- und der Negativerfassung unterschieden werden. Bei der Negativerfassung werden lediglich die Abweichungen von den SollArbeitszeiten bspw. durch Abwesenheit oder Überstunden erfasst. Diese Erfassungsform bietet sich insbesondere bei feststehenden Arbeitszeitregelungen mit nur wenig Abweichung zwischen Soll- und Ist-Anwesenheit an. Die Positivzeiterfassung hingegen erfordert die explizite Erfassung der An- und Abwesenheit des Mitarbeiters. Sie gestaltet sich daher aufwändiger, bietet aber auch deutlich umfassendere Möglichkeiten der Auswertung und Weiterleitung der erfassten Daten (vgl. Adamski 1995, 122ff.).

14.1.4

Zeitplanungskomponente Die Zeitplanungskomponente unterstützt die Definition von SollArbeitszeiten, den Arbeitszeitmodellen, was im Anschluss einen Soll-Ist-Vergleich von Zeitdaten ermöglicht. Grundsätzlich sind hierzu die Lage, die Verteilung, die Schwankungsbreite, die Dauer, die Bezugsebene und der Rhythmus von Arbeitszeitmodellen festzulegen. Die Lage der Arbeitszeit betrifft den variablen oder fixen Beginn und die Endzeit der Arbeitszeit pro Tag. Die Verteilung bezieht sich auf Möglichkeiten, durch ungleiche Verteilung der Arbeitszeit auf verschiedene Tage Arbeitsspitzen an arbeitsreichen Tagen durch Freizeit an arbeitsschwachen Tagen zu kompensieren. Die Schwankungsbreite legt Ober- und Untergrenzen fest, zwischen denen sich die Arbeitszeit bewegen kann (z.B. wöchentliche Schwankung zwischen 32h und 40h). Die

184

14.1 Architektur und Funktionalität von Arbeitszeitmanagementsystemen Dauer bezieht sich auf die Länge der Arbeitszeit. Dabei kann die Dauer zwischen Mitarbeitergruppen variieren, z.B. können für verschiedene Mitarbeitergruppen verschiedene Monatsarbeitszeiten im Unternehmen existieren. Als Bezugsebene dient normalerweise der Tag oder die Woche (z.B. 35h/Woche). Der Rhythmus eines Arbeitszeitmodells legt Folgen einzelner Schichten oder Anwesenheiten fest (z.B. die Schichtfolge »Früh-Früh-FrühSpät-Spät-Spät-Frei-Frei«). Auf diese Weise können verschiedene Arbeitszeitmodelle festgelegt werden, um betriebliche Bedarfe wie mitarbeiterseitige Bedürfnisse zu decken (vgl. Dingler 1997, 11ff.). Existieren Schnittstellen zu Personaleinsatzplanungssystemen, können die Ergebnisse einer langfristigen Personaleinsatzplanung als Vorgaben für die Definition von Soll-Arbeitszeit verwendet werden. Die abgelegten Arbeitszeitmodelle entsprechen in diesem Fall den für einzelne Mitarbeiter individuell geplanten Schicht- bzw. Dienstfolgen (vgl. Kap. 8). Eine Generierung von Arbeitszeitmodellen in der Planungskomponente des Arbeitszeitmanagementsystems ist dann entsprechend nicht mehr notwendig. Generell dienen solche intern generierten oder extern importierten Arbeitszeitmodelle als Grundlage von Soll-Ist-Vergleichen. Ebenso eignen sich Arbeitszeitmodelle als Grundlage für die Bewertung der Ist-Arbeitszeit eines Mitarbeiters in der Bewertungskomponente. In der Planungskomponente findet darüber hinaus die Definition und Verwaltung des Betriebskalenders statt, der die Arbeits-, Feier- und Brückentage oder Werksurlaub festlegt.

14.1.5

Bewertungskomponente In der Bewertungskomponente werden die erfassten Ist-Zeiten ausschließlich für Zwecke der Lohn- und Gehaltsabrechnung vorverarbeitet. Generell sollen hierbei unterschiedlich zu bezahlende Arbeitszeiten identifiziert werden wie bspw. die Unterscheidung von »Normalarbeit« und »Mehrarbeit«. Um die Arbeitszeit adäquat zu bewerten, erfolgt ein Abgleich der tatsächlichen Arbeitszeit mit der vorgegebenen Sollzeit. Dabei werden verschiedene bewertungsrelevante Zeitvarianten zunächst identifiziert und anschließend regelbasiert bewertet. Mehrarbeitszeit, die über die Soll-Arbeitszeit hinaus geht und mit einem Zuschlagssatz vergütet wird, wird oft auf einem speziellen Mehrarbeitszeitkonto des Mitarbeiters gutgeschrieben. Zeiten, die außerhalb des Soll-Arbeitszeitrahmens liegen, sowie Pausen und Arbeitsunter185

14

Arbeitszeitmanagementsysteme brechungen werden als nicht verrechenbare Zeiten bewertet. Die Anwesenheitszeit innerhalb der Soll-Arbeitszeit und der Dienstgang werden als Arbeitszeit gewertet und dem Zeitkonto des Mitarbeiters gutgeschrieben (vgl. Mülder & Störmer 2002, 253ff.).

Korrekturen

Bei der Erfassung der Arbeitszeit durch den Mitarbeiter selbst oder seinen Vorgesetzten bzw. den Zeitbeauftragten sind vereinzelt nachträgliche Korrekturen der Zeitbuchungen notwendig. Vergisst bspw. ein Mitarbeiter seinen Mitarbeiterausweis oder müssen die erfassten Zeiten auf unterschiedliche Kostenstellen aufgeschlüsselt werden, werden die Zeiten nachträglich im System korrigiert. Insbesondere im Hinblick auf eine exakte Zeiterfassung sind solche Korrekturfunktionalitäten unabdinglich. Dazu ist zunächst ein ordnungsgemäßer Monatsabschluss der Zeiterfassung vorzunehmen, welcher die korrekt bewertete MonatsArbeitszeit der Mitarbeiter enthält.

Personalabrechnung

Über Schnittstellen ist es i.d.R. möglich, die bewerteten Ist-Arbeitszeiten an Personalabrechnungssysteme zu übergeben, wo sie dann zur Berechnung zeitbezogener Entgelte zur Verfügung stehen (vgl. Kap. 13). Häufig werden die Daten dabei als ASCIIDatei dem Abrechnungssystem zur Verfügung gestellt und über ein regelmäßiges Upload in das Abrechnungssystem eingelesen (vgl. Mülder & Störmer 2002, 259ff.). Fehlen entsprechende Schnittstellen, so ist zum Monatsabschluss eine Liste mit der Aufschlüsselung der bewerteten Arbeitszeiten pro Mitarbeiter zu erstellen, die manuell in das Personalabrechnungssystem eingegeben werden muss.

14.1.6

Analysekomponente Die Analysekomponente unterstützt den Anwender in der Erstellung beliebiger arbeitszeitbezogenen Abfragen und Berichte. Neben Anwendern in der Personalabteilung können auch Mitarbeitern individuelle Auswertungen ihrer Arbeitszeit zur Verfügung gestellt werden. Typische Auswertungen sind bspw. ƒ Auswertungen von Mehrarbeitszeiten, ƒ Auswertung aktuell an- und abwesender Mitarbeiter, ƒ Auswertungen von Absentismusgründen oder ƒ Zeitsaldenauswertungen (auf Mitarbeiterebene, im Vorjahresvergleich etc.). Außerdem können Informationen aus der Zeitwirtschaft Inputgrößen für die Personalbedarfs- (vgl. Kap. 7) und Personaleinsatzplanungssysteme (vgl. Kap. 8) bilden. So sind für die Personaleinsatzplanung insbesondere Informationen zur An- bzw. Ab-

186

14.1 Architektur und Funktionalität von Arbeitszeitmanagementsystemen wesenheit sowie zu den Kosten eines Einsatzplanes von Bedeutung. Das Arbeitszeitmanagementsystem gibt Informationen bzgl. der Anwesenheit bzw. Abwesenheit von Mitarbeitern an die Personaleinsatzplanung weiter, so dass kurzfristig Ausfälle von Mitarbeitern durch Ersatz aufgefangen werden und die planmäßige Besetzung der Arbeitsplätze gesichert werden kann. Neben der reinen Erfassung von An- bzw. Abwesenheiten eines Mitarbeiters dienen die Zeitkonten als wichtige Größe in der Personaleinsatzplanung. Unter dem Gesichtspunkt ausgeglichener Zeitkonten werden von der Personaleinsatzplanung entsprechend Mitarbeiter mit freier Kapazität als Ersatz geplant. Durch die Bereitstellung der im Arbeitszeitmanagementsystem hinterlegten Arbeitszeitmodelle wird dabei der Personaleinsatzplanung eine Prognose der Kosten für die jeweiligen Einsatzpläne inklusive Zuschläge für Überstunden, Sonn- und Feiertage und Nachtarbeit ermöglicht (vgl. Scherf 2005b).

14.1.7

Zutrittskomponente Die Zutrittskomponente dient der Steuerung, Protokollierung und Auswertung von Zutritten zu bestimmten Bereichen des Unternehmens. Neben der integrierten Realisierung der Zutrittskontrolle als Zusatzmodul eines Arbeitszeitmanagementsystems ist auch die separate Implementierung als Zutrittsmanagementsystem möglich (vgl. detailliert Kap. 15). Für eine Integration der Systeme spricht die Nutzung gleicher Stammdaten, der gleichen Authentifizierungskomponente und -hardware sowie der damit einhergehende geringere Verwaltungsaufwand. Dennoch ist eine Trennung beider Systemkategorien möglich und wird zum Teil auch von Anwendern und Betriebsräten gefordert. Insbesondere aufgrund der Möglichkeit der kombinierten Auswertungen von Zutritts- und Zeiterfassungsdaten wird eine Integration teilweise als kritisch erachtet (vgl. Mülder & Störmer 2002, 283ff.).

14.1.8

Zusatzkomponenten Aufgrund der grundsätzlich vorhandenen Erfassungsinfrastruktur von Arbeitszeitmanagementsystemen sind teilweise weitere datenerfassende Komponenten in solche Systeme integriert. Die Integration mit dem Arbeitszeitmanagementsystem resultiert vor allem aus der gemeinsamen Verwendung der Authentifizierungskomponente sowie der gemeinsamen Personalstammdaten. Dennoch ist die Verwendung solcher Komponenten oft lediglich in Verbindung mit weiterführenden Systemen wie z.B. Produktionsplanungs- und Steuerungssystemen sinnvoll. Dabei sind insbe187

14

Arbeitszeitmanagementsysteme sondere die Betriebsdatenerfassung, die Projektzeiterfassung sowie die Tank- und Kantinendatenerfassung verbreitete Zusatzkomponenten von Arbeitszeitmanagementsystemen (vgl. Mülder & Störmer 2002, 268ff.).

Betriebsdatenerfassung

Mittels der Betriebsdatenerfassung (»BDE«) werden aktuelle Daten aus dem Produktionsprozess wie Arbeitsgänge, Stückzahlen Auftragszeiten etc. erfasst. Diese Informationen werden i.d.R. an das Produktionsplanungs- und Steuerungssystem rückgemeldet. Je nach Entgeltsystem dienen Daten der Betriebsdatenerfassung aber auch als Input für die Personalabrechnung. So werden etwa erfasste Stückzahlen direkt zur Berechnung von Akkordlöhnen zur Verfügung gestellt (vgl. Kap. 13). Im Kontext der Zeitwirtschaft sind weiter insbesondere die Auftragszeitdaten relevant. Durch die »Kommen«- bzw. »Gehen«-Buchung in der Zeiterfassungskomponente ist ein äußerer Rahmen für die Auftragszeiterfassung gegeben. Aufgrund des zugrunde liegenden Arbeitszeitmodells werden die Pausen automatisch erkannt und von der gemeldeten Auftragszeit abgezogen, so dass eine Netto-Auftragszeit gebildet werden kann. Entsprechend bildet die Auftragszeit eine Teilmenge der bezahlten Anwesenheitszeit (vgl. Adamski 1995, 152f.).

Projektzeiterfassung

Über die Projektzeiterfassung werden Arbeitsstunden für einzelne Projekte oder Aufträge erfasst und zur Kalkulation von abzurechnenden Zeiten verwendet. So dienen bspw. bei Softwareentwicklungsprojekten die erfassten Arbeitszeiten als Grundlage für die Rechnungsstellung an den Kunden. Dazu wird ein Projekt im System mit Projektnummer, Start- und Endtermin, Projektleiter etc. angelegt, und über die Meldung der Arbeitsstunden für das Projekt können jederzeit die Projektkosten kalkuliert werden.

Tank-/Kantinendatenerfassung

Tank- und Kantinendaten werden bei betrieblichem Angebot von Kantinenverpflegung und Verkauf von Kraftstoffen an Mitarbeiter meist direkt am Ort der Ausgabe erfasst. Entsprechende, pro Abrechnungsperiode aufsummierte Daten können dann direkt zur Verrechnung an ein Personalabrechnungssystem weitergegeben werden, wo die entsprechenden Beträge von der auszuzahlenden Summe abgezogen werden.

14.2

Anwendung von Arbeitszeitmanagementsystemen Das primäre Ziel von Arbeitszeitmanagementsystemen besteht in der Abstimmung individueller Arbeitszeiten mit den betrieblichen Anforderungen. Weiterhin unterstützt das Arbeitszeitmanage-

188

14.2 Anwendung von Arbeitszeitmanagementsystemen mentsystem die gemäß dem Arbeitszeitgesetz erforderliche Dokumentations- und Nachweispflicht der Arbeitszeit. Die grundsätzliche Anwendung von Arbeitszeitmanagementsystemen wird allerdings durchaus ambivalent gesehen. So werden im Rahmen der Diskussion um die »Vertrauensarbeitszeit« die Notwendigkeit und der Sinn einer minutiösen Registrierung von Anwesenheiten zu Recht hinterfragt. Zum einen wird darauf hingewiesen, dass Anwesenheit und Leistung nur bedingt korrespondieren und Mitarbeiter durch Zeiterfassung und nachfolgender Zeitentlohnung zu langen Anwesenheiten und der Anhäufung von (durch Freizeit oder Geld vergüteten) »Überstunden« verleitet werden. Zum anderen wird ebenfalls auf die teils erheblichen Kosten einer elektronischen Zeiterfassung hingewiesen. Neben einer gewissen »Tradition« der Zeiterfassung und -entlohnung sind es insbesondere tarifvertragliche und gesetzliche Gründe, die Arbeitgeber in der elektronischen Zeiterfassung halten. Sehen die Entgelttarifverträge Varianten des Zeitentgelts vor, die auf Zeiterfassung beruhen, kann ein entsprechendes Entgelt nur auf Basis der Inputdaten eines Arbeitszeitmanagementsystems ermittelt werden. Ebenso unterliegen die Unternehmen teilweise weitgehenden Auskunftspflichten (bspw. sind Nacht- und Sonntagsarbeit den Gewerbeaufsichtsämtern detailliert zu melden), die erneut nur auf der Basis einer Erfassung von An- und Abwesenheiten zu leisten sind. Ist in diesem Sinne ein Arbeitszeitmanagement notwendig, bieten entsprechende Informationssysteme natürlich Vorteile gegenüber einer manuellen Erfassung etwa mittels Stechuhren. Zunächst werden der notwendige Prozess der Erfassung und die Dokumentation der geleisteten Arbeitszeit wesentlich vereinfacht. Insbesondere vor dem Hintergrund der Verwaltung und Integration multipler flexibler Arbeitszeitmodelle und den daraus resultierenden Bewertungen der entsprechenden Arbeitszeiten reduziert die Anwendung von Arbeitszeitmanagementsystemen den Aufwand gegenüber der manuellen Erfassung und Verwaltung dieser Daten. Die vorbereitenden Bewertungsfunktionen unterstützen darüber hinaus eine anwesenheitsgerechte Entlohnung. Diese administrativen Aufgaben der Personalabteilung entfallen damit zum großen Teil, was entsprechende Rationalisierungspotenziale für die Personalabteilung birgt (Lederer & Ganter 1999, 41f.). Weiter unterstützt die Transparenz von An- und Abwesenheitszeit von Mitarbeitern auch die Personaleinsatzplanung (vgl. Kap. 8).

189

14

Arbeitszeitmanagementsysteme

Verbreitung und Perspektiven

190

Entsprechend wenden ca. 85% der Unternehmen in Deutschland Informationssysteme zum Arbeitszeitmanagement an (vgl. Kabst & Giradinni 2005, 41). Arbeitszeitmanagementsysteme gehören damit zu den besonders verbreiteten Systemkategorien. Unter dem (eigentlich zu weit gefassten) Begriff »Workforce Management« wird derzeit insbesondere die Integration des Arbeitszeitmanagements mit der Personalbedarfs- (vgl. Kap. 7), der Personaleinsatzplanung (vgl. Kap. 8) sowie teilweise des Zutrittsmanagements (vgl. Kap. 15) als zukunftsweisendes Konzept diskutiert (vgl. z.B. Brill 2005). Eine klare und einheitliche Konzeption eines Workforce Management hat sich derzeit allerdings (noch) nicht herausgebildet, und teilweise wird der Begriff auch lediglich als Aufmerksamkeit heischender Neologismus verwendet. Aufgrund der engen Verzahnung dieser Bereiche ist deren integrative Abbildung in Informationssystemen durchaus sinnvoll, wird aber auch von verschiedenen Herstellern im Sinne modularer Architekturen durchaus schon seit längerem angeboten.

15

Zutrittsmanagementsysteme Zutrittsmanagementsysteme (Zutrittskontrollsysteme, Zutrittssteuerungssysteme) sind Anwendungen zur Planung, Steuerung, Protokollierung und Kontrolle von Zutritten von Mitarbeitern und dritten Personen zu einzelnen Unternehmensbereichen (vgl. Mülder & Störmer 2002, 287).

15.1

Architektur und Funktionalität von Zutrittsmanagementsystemen Der idealtypische Aufbau eines Zutrittsmanagementsystems besteht aus den Personalstammdaten, den Zutrittsdaten und den Berechtigungsprofilen, Komponenten zur Authentifizierung, Steuerung und Analyse sowie einer Anwenderschnittstelle (vgl. Abb. 15.1). Zutrittsmanagementsystem Anwenderschnittstelle Terminal

Personaleinsatzplanung

Authentifizierung

Steuerung

Analyse Alarmsystem Sperrelement

Berechtigungsprofile

Personalstamm

ZutrittsDaten

Abb. 15.1: Idealtypische Architektur von Zutrittsmanagementsystemen In einer Datenbankkomponente werden üblicherweise »Personalstammdaten«, Zutritts(berechtigungs)-Profile« sowie die eigentlichen »Zutrittsdaten« abgelegt. Mittels einer Authentifizierungskomponente wird über verschiedene Authentifizierungsverfahren die Berechtigung von Personen auf Zutritt geprüft. Die Steuerungskomponente hält alle Bewegungsdaten fest, protokolliert Zu- und Austrittsversuche sowie Alarmauslösungen. Weiterhin erfolgt aus der Steuerungskomponente heraus die Ansteuerung der 191

15

Zutrittsmanagementsysteme Alarmanlage sowie der Sperrelemente. Eine Analysekomponente ermöglicht die Auswertung der Zutrittsdaten.

Verteilte Systeme

Zutrittsmanagementsysteme sind i.d.R. als verteilte Systeme organisiert. Die Anwendung wird dabei auf mehrere Hardwarekomponenten aufgeteilt. Für die Authentifizierung der Mitarbeiter und die Erfassung der Buchungen kommen zusätzliche, meist proprietäre Hardwarekomponenten an den Ein- und Ausgängen des Unternehmens zum Einsatz. Solche Lese- und Erfassungsgeräte werden i.d.R. als (Zutrittsmanagement-)»Terminals« bezeichnet. Wird das Zutrittsmanagementsystem parallel zu einem Arbeitszeitmanagementsystem (vgl. Kap. 14) betrieben, werden Terminals i.d.R. gemeinsam für beide Anwendungen verwendet. Bei verteilten Anwendungen können Teile der dargestellten Systemkomponenten, insbesondere die Authentifizierungskomponente, die Steuerungskomponente sowie die Datenbankkomponente, dem Terminal zugeordnet sein. Die einzelnen Hard- und Softwarekomponenten wirken dann in integrierter Weise wie ein einheitliches System zusammen. Terminals können in der Folge im Online- und im Offline-Modus betrieben werden. Im OnlineModus wird die Zutrittsanforderung vom zentralen System bestätigt. Im Offline-Modus, der auch bei Unterbrechung der Verbindung zum Zentralsystem greifen kann, wird die Zutrittsanforderung direkt vom Terminal aus geprüft. In letzterem Fall erfolgt die Authentifizierung und Steuerung des Zutrittspunktes ausschließlich vom Terminal aus. Nur die Verwaltung und Auswertung der Daten wird über das zentrale Zutrittsmanagementsystem vorgenommen.

Eingebettete Systeme

Bei sehr einfachen Systemen finden sich auch Varianten, bei denen sich alle notwendigen Softwarekomponenten auf dem Terminal an der Zutrittsstelle befinden. Auf solche eingebetteten Softwaresysteme (»Embedded Systems«) haben personalwirtschaftliche Anwender dann i.d.R. keinen Zugriff, weswegen solche Lösungen auch meist keine Analysekomponente aufweisen. Diese Realisierungsvariante bietet sich insbesondere bei wenigen, einzeln zu sichernden Zutrittspunkten an. Eine konsolidierte Auswertung von Anwesenheiten und Bewegungen in den Raumzonen wie bspw. die Raumbilanzierung ist damit nicht möglich.

Normierungen

Die Ausgestaltung von Zutrittsmanagementsystemen ist in der Normenreihe EN 50133 geregelt. Durch diese Normen wird sichergestellt, dass ein Zutrittsmanagementsystem funktionell, d.h. in der Authentifizierung, Steuerung und Auswertung geeignet ist

192

15.1 Architektur und Funktionalität von Zutrittsmanagementsystemen und der gültige Stand der Technik eingehalten wird (vgl. BHE 2001).

15.1.1

Datenbankkomponente Die Datenbankkomponente eines Zutrittsmanagementsystems umfasst i.d.R. Dateien zum Personalstamm, zu den Berechtigungsprofilen und zu den Bewegungsdaten der einzelnen Zutritte.

Personalstamm

Die Personalstammdaten beinhalten die persönlichen Daten eines Mitarbeiters, wie Name, Kostenstelle, Abteilung, Ausweisnummer sowie ein zugeordnetes Zutrittsberechtigungsprofil. Daneben sind ggf. zusätzlich weitere zutrittsberechtigte Personen gespeichert.

Berechtigungsprofile

Die Berechtigungsprofile einzelner Mitarbeiter werden separat verwaltet und legen hinsichtlich Raum- und Zeitzonen die Einschränkungen eines möglichen Zutritts fest. Der Begriff Raumzone bezeichnet dabei einen abgeschlossenen Bereich, wie z.B. einzelne Gebäude, Abteilungen, Parkplätze etc., der über einen oder mehrere Zutrittspunkte betreten werden kann. Über das Berechtigungsprofil wird festgelegt, welche Raumzonen betreten werden dürfen. Weiterhin kann innerhalb des Berechtigungsprofils eine Einschränkung der Zutrittsrechte nach zeitlichen Gesichtspunkten erfolgen. So können Zeitintervalle festgelegt werden, innerhalb derer der Zutritt zu definierten Raumzonen möglich ist (vgl. Mülder & Störmer, 291f.). Weiterhin ist auch die Integration der zeitlichen Aspekte der Zutrittsbeschränkung variabel über die Integration der Personaleinsatzpläne möglich. Darüber hinaus ergibt sich eine Einschränkung der Zutrittsberechtigung aus der Personenkategorie, wie z.B. Mitarbeiter, Kunde, Besucher. Mit Hilfe dieses Merkmals wird festgelegt, ob der Zutritt bspw. nur unter Aufsicht bzw. Begleitung einer weiteren Person gewährt wird. Aus der Kombination der räumlichen und zeitlichen Einschränkungen sowie der Personenkategorie ergibt sich eine Vielzahl möglicher Berechtigungsprofile. Diese Berechtigungsprofile werden einzelnen Mitarbeitern und/oder verschiedenen Mitarbeitergruppen zugeordnet.

Zutrittsdaten

Die Speicherung der Zutrittsbuchungen erfolgt in den Bewegungsdaten der Datenbank. Hier wird festgehalten, wann welche Person einen bestimmten Bereich betreten und verlassen hat. Aber auch fehlgeschlagene Zutrittsversuche, Alarmauslösungen, sowie stornierte Ein- und Austritte werden gespeichert.

193

15

Zutrittsmanagementsysteme

15.1.2

Authentifizierungskomponente Insbesondere aufgrund der Authentifizierungskomponente und der gemeinsam zu nutzenden Stammdaten werden Arbeitszeitmanagement- und Zutrittsmanagementsysteme häufig integriert eingesetzt. Derselbe Datenträger kann dabei sowohl zur Zeiterfassung als auch zur Zutrittsbuchung verwendet werden, so dass der einzelne Mitarbeiter nicht mehrere Datenträger mit sich führen muss. Die Authentifizierungskomponente verfügt im Rahmen der Zutrittskontrolle im weitesten Sinne über die gleichen Möglichkeiten und Funktionalitäten wie im Kontext des Arbeitszeitmanagements. Dabei erfolgt die Authentifizierung zur Zutrittsgewährung über Verfahren der Authentifizierung über Datenträger, über PIN oder Passwort oder über biometrische Merkmale (vgl. detailliert Kap. 14). Zur Zutrittskontrolle ist im Gegensatz zur Zeitwirtschaft jedoch die Verwendung eines Terminals bzw. einer Leseeinheit erforderlich, welche(r) baulich direkt am Zutrittspunkt installiert ist (vgl. Mülder & Störmer 2002, 179ff.).

15.1.3

Steuerungskomponente Nach erfolgreicher Authentifizierung wird im Zutrittsmanagementsystem automatisch der Zutritt zu einer bestimmten Raumzone gebucht. Eine Zutrittsbuchung beinhaltet dabei Informationen zur Person, zum Ort und zum Zeitpunkt des Zutritts. Die Austrittsbuchung kann zum einen bei Wechsel der Raumzone automatisch über die Zutrittsbuchung in die nächste Raumzone gebucht werden oder aber, z.B. bei Verlassen des Parkplatzgeländes, über eine separate Austrittsbuchung erfolgen. Die Steuerungskomponente übernimmt damit die Speicherung der Einund Austritte in der Zutrittsdatei. Daneben werden auch Zutrittsversuche von unberechtigten Personen gespeichert. Die Ausgestaltung der Protokollierungsmöglichkeiten hängt dabei insbesondere von den Sicherheitsanforderungen und den entsprechend eingesetzten Sperrelementen ab. Sperrelemente sind Schließanlagen, die den faktischen Zutritt zu bzw. den Austritt aus den Raumzonen regeln. Dies sind z.B. elektronische Türöffnungssysteme, Drehkreuze, Drehsperren, Schranken, Personenschleusen etc. So ist es bspw. bei Einsatz einer elektronisch öffnenden Tür möglich, dass mehrere Personen gleichzeitig die Raumzone betreten, wobei sich nur eine Person authentifiziert hat. Damit ist in dieser Raumzone die Protokollierung der Bewegungen jeder einzelnen Person nicht möglich. Im Fall von Drehkreuzen hingegen ist die Möglichkeit zu Authentifizierung und

194

15.1 Architektur und Funktionalität von Zutrittsmanagementsystemen Zutrittsbuchung der einzelnen Person gegeben. Bestehen hohe Sicherheitsanforderungen wie bspw. bei einem Rechenzentrum oder einem Labor, sind die Zutrittspunkte so auszugestalten, dass ausschließlich der Zutritt einer einzelnen Person möglich ist. Dies kann bspw. durch die Verwendung eines Drehkreuzes oder einer Personenschleuse erreicht werden. Bereiche mit relativ niedrigeren Sicherheitsanforderungen können durch elektronische Türöffnungen gesichert werden, die bei Authentifizierung einer einzelnen Person durchaus auch mehreren Personen gleichzeitig Zutritt gewähren können. Abb. 15.2 zeigt schematisch die Interaktion des Zutrittsmanagementsystems mit einer Tür als Sperrelement und einer Hupe als Alarmsignalgeber.

Türrahmenkontakt

Zutrittsmanagementsystem

Alarm

Türöffner mit Rückmeldekontakt Terminal / Leseeinheit

Abb. 15.2: Ausgestaltung einer Zutrittsstelle (in Anlehnung an Mülder & Störmer 2002, 180) Über die Leseeinheit authentifiziert sich der Mitarbeiter an der Tür, um Zutritt zu der gesicherten Raumzone zu erhalten. Bei erfolgreicher Authentifizierung öffnet sich die Tür automatisch und der Zutritt wird gewährt. Dies geschieht über den Türöffner, ein elektromechanisches Gerät zur Freigabe der Tür. Über den Rückmeldekontakt am Türöffner wird das Schließen der Tür an das System gemeldet. Wird hierbei ein im Zutrittsmanagementsystem festgelegtes Zeitintervall überschritten, so wird ein Alarm 195

15

Zutrittsmanagementsysteme ausgelöst. D.h. in diesem Fall ertönt eine Hupe, die das Überschreiten der Öffnungszeit der Tür signalisiert. In der Steuerungskomponente wird im Rahmen der Implementierung festgelegt, durch welche Aktionen ein Alarm ausgelöst werden kann. Hierunter fällt neben dem genanten Beispiel der überschrittenen Türöffnungszeit auch der Fall, ƒ dass eine unberechtigte Person mehrfach einen Zutrittsversuch unternimmt, ƒ dass ein Zutritt durch gewaltsames Öffnen der Sperranlage oder durch Manipulation an der Hardware wie z.B. der Terminals erfolgt, ƒ dass ein Terminal ausfällt, ƒ dass die Übertragung im Online-Modus unterbrochen wird oder ƒ dass die maximale Aufenthaltsdauer einer berechtigten Person in einem Raum überschritten wird (vgl. Adamski 1995, 173f.). Solche Aktionen werden vom Zutrittsmanagementsystem erkannt und aktivieren den Alarm. Der Alarm kann direkt an eine zentrale Bearbeitungsstelle weitergeleitet oder lediglich protokolliert werden. Im Falle hoher Sicherheitsanforderungen können Zutrittsmanagementsysteme an generelle Alarmsysteme angeschlossen werden (vgl. Störmer 1999, 40). Diese verfügen bspw. über Überwachungskameras an den jeweiligen Zutrittstellen, die bei Alarm aktiviert werden und die auslösende Person aufnehmen.

Steuerungsarten

196

Darüber hinaus ermöglicht die Steuerungskomponente die Steuerung der Frequentierung von Raumzonen und die damit verbundene Steuerung der Sperrelemente (vgl. Adamski 1995, 169ff.; Mülder & Störmer 2002, 302). Die Funktionalität einer Raumzonenwechselkontrolle verhindert den Wechsel einer Raumzone, wenn zuvor keine ordnungsgemäße Austritts- bzw. Zutrittsbuchung vorgenommen wurde und sich diese Person entsprechend unberechtigt in der gegenwärtigen Raumzone aufhält. Damit wird sichergestellt, dass der Zugang zu einer bestimmten Raumzone lediglich über den vorgesehenen Weg möglich ist. Die Mehr-Personen-Anwesenheitskontrolle dient der Sicherstellung, dass in bestimmten Raumzonen wie bspw. dem Rechenzentrum immer mehr als eine Person anwesend ist. Befinden sich zwei Personen in einer Raumzone, so müssen entweder beide Personen die Raumzone verlassen oder aber zwischenzeitlich eine dritte Person hinzukommen, so dass eine der beiden bereits anwesenden Personen die Raumzone verlassen kann. Die Zwei-

15.2 Anwendung von Zutrittsmanagementsystemen Personen-Zutrittskontrolle stellt sicher, dass der Zutritt zu dieser Raumzone erst erlaubt wird, wenn mindestens zwei Personen innerhalb eines bestimmten Zeitintervalls ihre Berechtigung zum Zutritt nachgewiesen haben. Das Zwei-Kategorien-Prinzip stellt sicher, dass eine Person einer Kategorie (z.B. »Aushilfe«) erst dann der Zutritt zu einer Raumzone gewährt wird, wenn bereits eine Person einer anderen Kategorie (z.B. »Facharbeiter«) anwesend ist. Durch die Zutrittswiederholkontrolle (»Anti-Passback«) wird verhindert, dass derselbe Datenträger von mehreren Personen nacheinander zum Zutritt verwendet wird. Erst bei gültiger Austrittsbuchung kann der Datenträger wieder zur Zutrittsbuchung verwendet werden. Hat eine Person einen Datenträger bspw. zur Zufahrt zum Betriebsgelände an der Schranke verwendet, so muss über diesen Datenträger erst wieder das Verlassen des Betriebsgeländes gebucht werden, bevor er wieder für die Zufahrt verwendet werden kann. Weiterhin dient die Steuerungskomponente auch zur Überwachung von vorgegebenen Aufenthaltsdauern. Die Vorgabe von maximalen Aufenthaltsdauern in gefährdeten Raumzonen dient dem Schutz der Mitarbeiter. Ist bspw. in einem Labor die Anwesenheit aus gesundheitlichen Gründen auf einen bestimmten Zeitraum beschränkt, so kann die Einhaltung über das Zutrittsmanagementsystem kontrolliert und bei Überschreitung der maximalen Aufenthaltsdauer eventuell ein Alarm ausgelöst werden.

15.1.4

Analysekomponente Neben der Authentifizierungs- und der Steuerungskomponente beinhaltet das Zutrittsmanagementsystem eine Analysekomponente. Diese Komponente ermöglicht die Analyse der gespeicherten Zutrittsdaten zur Information über die faktische Anwesenheit sowie die Anwesenheitsdauer und den -zeitpunkt von Personen in bestimmten Raumzonen. Ein Beispiel ist die so genannte Raumbilanzierung. Die Raumbilanzierung liefert Informationen, welche und wie viele Personen sich zu einem bestimmten Zeitpunkt in einer Raumzone befinden. Weiterhin ermöglicht die Analysekomponente die Auswertung unberechtigter Zutrittsversuche, Alarmauslösungen etc.

15.2

Anwendung von Zutrittsmanagementsystemen Gemessen an ihrer Funktionalität sind Zutrittsmanagementsysteme keine »rein« personalwirtschaftlichen Systeme, sondern weisen einen hybriden Charakter auf und bedienen zusätzlich auch 197

15

Zutrittsmanagementsysteme die Bereiche Arbeitssicherheit und -schutz, Werkschutz, Katastrophenschutz und Besucheradministration. Im Blick auf einen geregelten Betriebsablauf stellen Zutrittsmanagementsysteme aus Sicht des Personalmanagements zunächst sicher, dass zutrittsberechtigte Mitarbeiter auch in Stoßzeiten reibungslos das Unternehmen betreten und verlassen können. Ebenso wird die Bewegung im Unternehmen während der Anwesenheit ermöglicht. Unberechtigte Mitarbeiter und andere unbefugte Personen werden simultan am Zutritt gehindert. Zutrittsmanagementsysteme stellen in diesem Sinne eine Variante »struktureller Personalführung« dar. Aus Perspektive von Arbeitssicherheit und Arbeitsschutz existieren in Unternehmen teilweise Raumzonen – wie etwa Kühlräume oder Labore – die wegen unterschiedlichen Belastungen oder Gefährdungen von Mitarbeitern – wie etwa Kälte oder Röntgenstrahlen – nur für eine gewisse Zeit und/oder nur mit gewissen zeitlichen Abständen betreten werden dürfen. Ebenso dient das System auch dem Schutz der Mitarbeiter vor Bereichen, in denen mit Gefahrstoffen gearbeitet wird und die daher lediglich für einen eingeschränkten Personenkreis zugänglich sind. Zutrittsmanagementsysteme gewährleisten entsprechend auch, dass Vorschriften der Arbeitssicherheit und des Arbeitsschutzes eingehalten werden können. Zutrittsmanagementsysteme sind weiter meist zentraler Teil eines umfassenderen Sicherheitskonzeptes. So dient das Zutrittsmanagementsystem im Sinne des allgemeinen Werkschutzes auch zentral der Sicherung von Unternehmensbereichen gegenüber fremden und unberechtigten Personen, um etwa Einbruch, Spionage und Diebstahl zu verhindern. Teilweise gebieten auch gesetzliche Bestimmungen die Implementierung von Zutrittsmanagementsystemen. Beispielsweise erfordern die Bestimmungen des § 9 Bundesdatenschutzgesetz sicherzustellen, dass Unbefugte keinen Zugang zu Räumen mit technischen Anlagen haben, auf denen personenbezogene Daten verarbeitet werden (vgl. Kap. 3). Ebenso unterstützen Zutrittsmanagementsysteme Maßnahmen im Rahmen des Brand- und Katastrophenschutzes, wie etwa Definition von Fluchtwegen, Auskunft über Raumbelegungen für Feuerwehr und Rettungskräfte etc. Herrscht im Unternehmen Publikumsverkehr, d.h. sollen sich in einzelnen Bereichen zusätzlich zu Mitarbeitern auch Besucher, Gäste und/oder Lieferanten bewegen können, so werden über das Zutrittsmanagementsystem die Berechtigungen der Besucher

198

15.2 Anwendung von Zutrittsmanagementsystemen verwaltet und entsprechend zeitlich und räumlich begrenzte Zutrittsrechte vergeben. Integration

Aufgrund dieser Multifunktionalität ist jede Anwendung von Zutrittsmanagementsystemen daher unter dem Aspekt der Integration mit weiteren Systemen zu betrachten. Die Entscheidung für ein Authentifizierungsverfahren und der damit anzuschaffenden Hardware wie Terminals und Leseeinrichtungen bietet ein Synergiepotenzial hinsichtlich der Anwendung von Arbeitzeitsystemen, aber auch der Betriebsdatenerfassung sowie eventuell Kantinenund Tankdatenerfassung (vgl. Störmer 1999, 40 und Kap. 14). Oft werden Zutrittsmanagement-Funktionen daher auch als Module bzw. Zusatzkomponenten von Arbeitszeitmanagementsystemen angeboten. Darüber hinaus verfügen Zutrittsmanagementsysteme oft auch über Schnittstellen zu Einbruch- und Brandmeldesystemen, zu Fluchtleitsystemen, zu Videoüberwachungssystemen u.a.m. Die Implementierung eines umfassenden Zutrittsmanagementsystems erfordert dann die abgestimmte Installation technischer Komponenten wie Terminals, Sperrelemente sowie Alarmsystemkomponenten wie Videoüberwachung, Alarmanlagen und Einbruchmeldeanlagen.

Verbreitung

Derzeit sind keine aktuellen empirischen Studien zur Verbreitung von Zutrittsmanagementsystemen bekannt. In mittleren und größeren Unternehmen dürften Zutrittsmanagementsysteme jedoch weit verbreitet Anwendung finden.

199

16

Beschaffungsmanagementsysteme Beschaffungsmanagementsysteme (Bewerberverwaltungssysteme, Bewerbungsmanagementsysteme, e-[Re]cruiting-Systeme, »Applicant Tracking Systems [ATS]«, »Talent Relationship ManagementSystems«) sind Anwendungen zur umfassenden Unterstützung der Personalbeschaffung.

16.1

Architektur und Funktionalität von Beschaffungsmanagementsystemen Beschaffungsmanagementsysteme umfassen üblicherweise eine Datenhaltungskomponente mit Dateien zu Bewerbern, Bewerbungen, Kontakten, Vakanzen und Ausschreibungen, auf die eine Administrations-, Analyse- und Kommunikations- sowie eine fakultative Assessmentkomponente zugreifen können (vgl. Abb. 16.1). Beschaffungsmanagementsystem Anwenderschnittstelle Assessment

RecruitingMedien Vorsysteme

Administration

Analyse

Ausschreibungen

Bewerbungen

Vakanzen

Kontakte

Kommunikation

BewerberEndgeräte

Bewerber

Personaldatenhaltung Dokumentenmanagement

Abb. 16.1: Idealtypische Architektur von Beschaffungsmanagementsystemen Die Datenhaltungskomponente hält entsprechende Daten zu Bewerbern, Bewerbungen, Kontakten, Ausschreibungen und Va201

16

Beschaffungsmanagementsysteme kanzen vor. Eine Administrationskomponente unterstützt die Verwaltung der Abläufe der Personalbeschaffung. Eine Analysekomponente ermöglicht Auswertungen über die Daten der Datenhaltungskomponente. Teilweise existiert zusätzlich eine Komponente zum Online-Assessment, die auf der Basis verschiedener eignungsdiagnostischer Verfahren insbesondere die Vorauswahl von Bewerbern unterstützen soll. Eine Kommunikationskomponente unterstützt die Kommunikation mit dem Bewerber über konventionelle und elektronische Kanäle.

16.1.1

Datenhaltungskomponente

Vakanzdatei

In einer Vakanzdatei werden Daten zu offenen Stellen abgespeichert. Diese Daten dienen zunächst der Erstellung von Ausschreibungen und auch einem späteren Abgleich mit den Bewerberdaten, um möglichst geeignete Bewerber selektieren zu können. Die Vakanzdatei enthält dabei generelle Angaben zur zu besetzenden Stelle, wie Bezeichnung, organisatorische Einordnung und Vergütung der Stelle. Die Vakanzdatenbank enthält weiterhin Informationen über den für die Vakanz verantwortlichen Mitarbeiter in der Personalabteilung und/oder der Fachabteilung, den Besetzungsgrad der Stelle (Vollzeit vs. Teilzeit), mögliche Befristungen sowie den geplanten Besetzungszeitraum. Häufig können auch die fachlichen, sozialen und physischen Anforderungen an einen Stelleninhaber mit aufgenommen werden, wobei meist auch Ausprägungsgrade der geforderten Fähigkeiten hinterlegt werden können. Zu diesem Zweck existieren teilweise auch Schnittstellen zu Stellendateien anderer personalwirtschaftlicher Anwendungssysteme. Teilweise können auch textbasierte Arbeitsplatzbeschreibungen hinterlegt werden.

Ausschreibungsdatei

Eine Ausschreibungsdatei erfasst alle Daten, die zur Erstellung, Übermittlung und Kontrolle der Stellenausschreibungen erforderlich sind. Diese Daten bilden die Grundlage für die Ausschreibung der Stelle in unterschiedlichen Beschaffungsmedien. Oft umfassen Ausschreibungsdateien standardisierte Textbausteine und Formatvorlagen, die eine Ausschreibung in unterschiedlichen Formaten, z.B. als HTML-Seite, PDF-Datei oder e-Mail ermöglichen. Zur Erstellung einer Ausschreibung wird i.d.R. auf Daten der Vakanzdatei zurückgegriffen. Um wiederkehrende Ausschreibungen zu ermöglichen, können fertig gestellte Ausschreibungsinhalte dann auch für einen Wiederabruf hinterlegt werden. Konkret erfolgte Ausschreibungen werden dann mit Attributen wie Art des Mediums, Informationen zur Übermittlung der Ausschreibung (Größe, Layout, Übertragungsart) oder Publi-

202

16.1 Architektur und Funktionalität von Beschaffungsmanagementsystemen kationszeitraum bzw. -zeitpunkt festgehalten. Zur Kontrolle des Beschaffungsgeschehens werden regelmäßig auch Statusinformationen zur Ausschreibung wie »Ausschreibung in Vorbereitung«, »Ausschreibung durchgeführt« oder »Besetzung abgeschlossen« abgelegt. Optional enthält die Ausschreibungsdatei auch generelle Daten zu den Ausschreibungsmedien, wie Kosten, Anschrift, Ansprechpartner etc. Bewerbungsdatei

Eine Bewerbungsdatei erfasst alle relevanten Attribute einer konkreten Bewerbung. Hierzu zählen das Eingangsdatum, die Art (Spontan- oder ausschreibungsspezifische Bewerbung mit Angabe des entsprechenden Mediums, interne oder externe Bewerbung) sowie die Zuordnung zu einer vakanten Stelle. Gewöhnlich wird auch der Status einer Bewerbung im Personalbeschaffungsprozess (bspw. »in Bearbeitung«, »zum Vorstellungsgespräch eingeladen« oder »Bewerber eingestellt«) hier abgelegt. In Interaktion mit Bewerberdaten wird es möglich, Mehrfachbewerbung desselben Bewerbers zu erkennen (»Doubletten-Check«). Eine unternehmensweite Haltung von Bewerbungsdaten ermöglicht es weiter, alle laufenden und abgeschlossenen Bewerbungen eines Bewerbers zu identifizieren. Zunehmend verfügbare Schnittstellen zu Dokumentenmanagementsystemen (vgl. Kap. 6) erlauben eine digitale Ablage und Wiederabruf beliebiger Bewerbungsdokumente wie etwa des Anschreibens. Handelt es sich um ein webbasiertes Beschaffungsmanagementsystem, dann können Bewerbungsdaten direkt vom Bewerber selbst eingegeben werden. Angefügte digitale Dokumente wie Anschreiben etc. können so direkt in die digitale Bewerbungsakte aufgenommen werden.

Bewerberdatei

Zur Vermeidung redundanter Datenerfassung bei Mehrfachbewerbungen werden Bewerberdaten meist in eine Bewerberdatei ausgelagert. In der Regel existieren hier zunächst Mechanismen zur Vermeidung von Doppelerfassungen derselben Bewerber. In der Bewerberdatei werden alle generellen, d.h. nicht auf eine konkrete Bewerbung bezogenen Daten eines Bewerbers erfasst. Kontaktdaten des Bewerbers (Name, Adresse, ...) ermöglichen die Kommunikation mit dem Bewerber im Bewerbungsverlauf. Zusätzlich wurden bisher auch zahlreiche personenbezogene Daten wie Alter, Familienstand, Herkunft, Behinderung etc. eines Bewerbers erfasst. Nach Maßgabe des »Allgemeinen Gleichbehandlungsgesetzes (AGG)« ist inzwischen allerdings eine »diskriminierungsfreie« Datenerhebung und -verarbeitung notwendig. Als diskriminierungsrelevant werden u.a. Geschlecht, Geburtsdatum bzw. Alter, Behinderung, ethnische Herkunft, Nationalität, sexuelle Identität sowie Religion des Bewerbers gesehen. Selbst 203

16

Beschaffungsmanagementsysteme Lichtbilder, die etwa Schlüsse auf die ethnische Herkunft oder das Geschlecht zulassen, werden als problematisch erachtet. Entsprechend sind auch unmittelbar beschaffungsrelevante Daten nur noch eingeschränkt erhebbar. Soweit solche »diskriminierungsrelevanten« personenbezogenen Daten in einem sich ggf. ergebenden Beschäftigungsverhältnis notwendig bzw. gesetzlich erforderlich sind, sind diese in aufwändiger Weise getrennt vom Beschaffungsprozess zu erheben (vgl. Jaspers 2006). Die Daten zur Qualifikation des Bewerbers dienen der Bewerberselektion, welche durch den Abgleich mit den Anforderungen der in Frage kommenden Stelle erfolgt. Optional kann das Bewerberprofil im Bewerbungsverlauf durch Potenziale und Abneigungen des Bewerbers ergänzt werden, wenn diese sich aus der weiteren Kommunikation und/oder Assessments ergeben. Mit der Bewerberdatei verfügen Unternehmen über einen generellen »Bewerberpool«. Auch hier ist es möglich, in Ergänzung strukturierter Bewerberdaten zusätzliche Dokumente, wie etwa Zeugnisse, in einer digitalen Bewerberakte abzulegen (vgl. Kap. 6). Kommt es zur Einstellung eines Bewerbers, so können vorhandene Bewerberdaten über Schnittstellen automatisiert in eine Mitarbeiterdatei bzw. -datenbank übernommen werden.

Kontaktedatei

Neben tatsächlichen Bewerbungen werden zur Unterstützung eines aktiven Beziehungsmanagements zunehmend auch Kontakthistorien geführt. In dieser Datei werden alle medialen (z.B. Telefonate) und direkten (z.B. Gespräche auf Bewerbermessen) Kontakte einschließlich ggf. getroffener Vereinbarungen abgelegt. Dies bildet eine Informationsgrundlage für alle weiteren, unternehmens- wie bewerberseitig initiierten Kontakt. Bei arbeitsteiliger Organisation der Beschaffung dienen hier abgespeicherte Informationen auch der abgestimmten Aktion verschiedener Akteure des Unternehmens.

16.1.2

Administrationskomponente In Interaktion mit weiteren Komponenten dient die Administrationskomponente der Realisierung einzelner Prozessschritte der Beschaffung.

Workflow

204

Die Administrationskomponente dient zunächst der Realisierung der einzelnen Teilaufgaben der Personalbeschaffung. I.d.R. weisen Administrationskomponenten eine Unterstützung des Workflows der Personalbeschaffung auf. Die zeitlich und sachlogisch zusammenhängende Bearbeitung von Aufgaben durch mehrere interne Bearbeiter (sowie durch die Bewerber selbst) wird dann

16.1 Architektur und Funktionalität von Beschaffungsmanagementsystemen vom System gesteuert und überwacht. Dies schließt die Steuerung der Reihenfolge einzelner Arbeitsschritte sowie den notwendigen Daten- und Dokumentenfluss zwischen den einzelnen Teilschritten ein. Hierzu sind i.d.R. Terminverwaltungen mit automatisierten Wiedervorlagefunktionen implementiert (vgl. Mülder 2003a). Aufgaben

Entsprechend wird über die Administrationskomponente zunächst die Verwaltung und Pflege von Vakanzen ermöglicht. Neue Vakanzen müssen in die Vakanzdatei aufgenommen und im weiteren Ablauf ein- oder mehrfach in einem oder mehreren Beschaffungsmedien ausgeschrieben werden. In Interaktion mit der Kommunikationskomponente können die im Zeitablauf anfallenden Kontakte verwaltet werden. Speziell sind natürlich eingehende Bewerbungen aufzunehmen und in Interaktion mit den übrigen Komponenten zu bearbeiten: Bei geeigneten Bewerbern sind Vorstellungsgespräche und ggf. Assessments vorzubereiten und zu realisieren. Für ungeeignete Bewerber können in Interaktion mit der Kommunikationskomponente Absagen realisiert werden. Schließlich unterstützt die Administrationskomponente auch die Durchführung beschaffungsrelevanter Abrechnungen. Dies zielt zentral auf die Abrechnung von Bewerberspesen, die im Rahmen von Vorstellungsgesprächen und weiteren Assessment-Aktivitäten entstehen. Hier können Fahrt-, Übernachtungsund Verpflegungskosten erfasst, berechnet und erstattet werden. Ebenso werden Kosten und Bezahlung der Ausschreibung von Vakanzen in unterschiedlichen Beschaffungsmedien verwaltet. Seltener können auch Personalmarketingaktivitäten, wie etwa die Durchführung einer Bewerbermesse, abgerechnet werden.

16.1.3

Kommunikationskomponente Die Kommunikationskomponente dient der Gestaltung des Kommunikationsprozesses zwischen Unternehmen und Bewerbern (vgl. Staufenbiel et al. 2002). Inzwischen können sämtliche notwendigen Kommunikationsvorgänge, beginnend mit dem Bereitstellen von Informationen, über das Einsenden von Bewerbungsunterlagen bis zur Benachrichtigung über Einstellung oder Ablehnung des Bewerbers über verschiedene Kommunikationskanäle abgewickelt werden. Die Gesamtheit der unterstützten Kanäle bestimmt dabei den grundsätzlich möglichen »Medienmix« der Personalbeschaffung. Zentral unterstützte Kanäle sind hierbei ƒ (papierbasierter) Schriftverkehr, ƒ Web (»Online-Formulare«), ƒ e-Mail, 205

16

Beschaffungsmanagementsysteme ƒ ƒ

Short Message Service sowie neuerdings auch Chat, Weblog und Podcast.

Allerdings zeigen sich in gegenwärtigen Beschaffungsmanagementsystemen zwei gegenläufige Entwicklungen: Insbesondere im Zuge der Entwicklungen zu einem Bewerberbeziehungsmanagement (»Talent Relationship Management«) werden zum einen zusätzliche, digitalisierte und interaktive Kanäle angeboten. Zum anderen beschränken sich viele Systeme aus Kosten- und Aufwandsgründen, insbesondere wegen der dann notwendigen systematischen Koordination verschiedener Kommunikationskanäle (»Multi Channel Management«), auf einen oder wenige Kanäle. Schriftverkehr

Einen ersten konventionellen Kommunikationskanal stellt der papierbasierte Schriftverkehr dar. Während frühere Beschaffungsmanagementsysteme teils über integrierte Textverarbeitungskomponenten verfügten, wird der konventionelle Schriftverkehr heute regelmäßig über die Anbindung eines externen Textverarbeitungssystems ermöglicht. Über standardisierte Schnittstellen ermöglichen Beschaffungsmanagementsysteme die Ausgabe von Individual- und speziell von Serienbriefen. Für letztere werden des Öfteren auch vorgefertigte Textbausteine angeboten. Die für den Versand notwendigen Kontakt- und Statusdaten werden dabei von den entsprechenden Datenbankkomponenten geliefert. Üblicherweise beizulegende Dokumente wie etwa Personalfragebogen, Verschwiegenheitserklärung, Arbeitsvertrag u.a.m. können i.d.R. ebenfalls automatisiert zur Verfügung gestellt und mit übersandt werden. Bewerberseitig ist hierzu kein Kommunikations-Endgerät notwendig.

e-Mail

Mit durchaus analoger Funktionalität und Vorgehensweise wird teils auch eine digitale Kommunikation per e-Mail unterstützt. Auch hier wird grundsätzlich der Austausch von Informationen (Textnachrichten) und Dokumenten (Anhänge) ermöglicht. Entsprechend kann sowohl das Einreichen der Bewerbungsunterlagen seitens der Bewerber, als auch das Versenden von Benachrichtigungen seitens des Unternehmens per e-Mail erfolgen. Als vollständig automatisierte Variante sorgen so genannte Jobagenten dafür, dass Bewerber automatisch per e-Mail über neue Ausschreibungen informiert werden, soweit diese auf ihr zuvor spezifiziertes Bewerberprofil passen. Darüber hinaus kann der Bewerber per e-Mail auch Rückfragen an das Unternehmen richten. Solche e-Mail-Funktionen werden meist unter Anbindung entsprechender externer e-Mail-Systeme oder Browsersysteme (vgl.

206

16.1 Architektur und Funktionalität von Beschaffungsmanagementsystemen Kap. 28) ermöglicht. Bewerberseitig sind hierzu ein entsprechender e-Mail-Zugang und ein e-mail-fähiges Endgerät notwendig. Onlineformulare

Auf der Basis webbasierter Beschaffungsmanagementsysteme können Online-Bewerbungsformulare auf speziellen Beschaffungsseiten oder aber im Rahmen der generellen Unternehmenshomepage angeboten werden (vgl. Stone et al. 2005; grundsätzlich auch Kap. 28). Teilweise bieten Beschaffungsmanagementsysteme bereits vorgefertigte Formulare an, teilweise können die Formulare mit externen HTML- bzw. XML-Editoren erstellt oder modifiziert werden. Je nach Zielgruppe (z.B. interne und externe Bewerber oder bestimmte Fachgruppen) kann die Online-Bewerbung im Hinblick auf das Layout, die Sprache und den Umfang individuell gestaltet werden. Bewerber können dann mittels des Bewerbungsformulars in einzelnen Schritten ihre Daten einpflegen und zusätzliche digitale Dokumente anhängen. Diese Möglichkeit, die kosten- und zeitintensive Dateneingabe zu externalisieren, stellt einen zentralen Vorteil gegenüber konventionellem Schriftverkehr und e-Mails dar. Inzwischen ist es zunehmend üblich, feste Bewerber-»Accounts« einzurichten, die über einen Benutzernamen und Kennwort permanent zugänglich sind und eine laufende Aktualisierung einer oder mehrerer Bewerbungen des Bewerbers ermöglichen. Die mittels Online-Formular übermittelten Daten werden automatisch in die Bewerber- und Bewerbungsdatei übernommen. Über solche Accounts können sich Bewerber auch jederzeit über den aktuellen Stand ihrer Bewerbung(en) im Rahmen des Personalbeschaffungsprozesses informieren (»Tracking«) sowie weitere Informationen, wie etwa eine Einladung zum Vorstellungsgespräch, abrufen. Werden solche Funktionalitäten angeboten, spricht man von Bewerber-Self Service-Systemen (»Applicant Self Service«). Bewerberseitig sind ein Internetzugang und ein Browsersystem notwendige technische Voraussetzungen.

SMS

Der Short Message Service (»SMS«, Kurznachrichtendienst) ist eine neuere Form der mobilfunk-basierten Kommunikation mit dem Bewerber, die von einigen Beschaffungsmanagementsystemen unterstützt wird. Die SMS-Funktion ist eine i.d.R. einseitig vom Unternehmen genutzte Funktion und kommt vor allem zur Benachrichtigung des Bewerbers über den Bewerbungseingang und -ablauf zum Einsatz. Bewerberseitig ist hierzu ein entsprechendes SMS-fähiges Mobil-Telefon notwendig. Eine weitergehende Einbindung der Telefonie jenseits von SMS – (»Computer Telephony Integration [CTI]«) in Beschaffungsmanagementsysteme ist derzeit nicht üblich. 207

16

Beschaffungsmanagementsysteme

Chat / Weblog / Podcast

Insbesondere für Zwecke eines Bewerberbeziehungsmanagements werden derzeit von wenigen Systemen weitere interaktive webbasierte Möglichkeiten zur Kommunikation insbesondere mit jüngeren, internetaffinen Bewerbern angeboten. I.d.R. werden diese Kanäle additiv auf der entsprechenden Beschaffungswebseite angeboten. Beim Chat erfolgt der Austausch kurzer Textnachrichten in synchroner, interaktiver Form. Interessenten haben hier die Möglichkeit, direkt karriererelevante Themen mit Vertretern des Unternehmens zu diskutieren und Fragen zu stellen (vgl. auch Kap. 28). Ein Weblog (»Blog«, Corporate [We]Blog«, »Employee [We]Blog«) ist eine themenspezifische Webseite, die periodisch mit entsprechenden Inhalten gefüllt wird. Im Fall des Bewerbermanagements werden karriererelevante Inhalte (Vergütung, Unternehmenskultur etc.) von Führungskräften und/oder Mitarbeitern verfasst. Regelmäßig vorhandene Kommentarfunktionen ermöglichen es Interessenten auch hier, sich direkt an die Unternehmensvertreter zu wenden. Ein Podcast bietet die Möglichkeit, Video- und Audiodateien zum Zwecke der Information des Bewerbers und des generellen Personalmarketing zu übermitteln.

16.1.4

Assessmentkomponente Insbesondere bei größeren Bewerberzahlen stellt sich die Frage nach einer Unterstützung bei der Vorauswahl geeigneter Bewerber. Insbesondere webbasierte Beschaffungsmanagementsysteme verfügen daher teils zusätzlich über Möglichkeiten eines OnlineAssessment (»e-Assessment«). Generelles Ziel der Assessmentkomponente ist es, wichtige Zusatzinformationen zur Bewerberqualifikation, z.B. hinsichtlich Belastbarkeit, Kreativität, Wissen und Einsatzbereitschaft zu generieren, die in eine Vorauswahl einfließen können. Zusätzlich dienen Online-Assessments im Vorfeld einer Bewerbung teilweise auch der realistische(re)n Selbsteinschätzung eines Bewerbers und dem Feedback, ob eine Bewerbung grundsätzlich sinnvoll ist. Methodisch unterscheidet sich ein Online-Assessment nicht grundsätzlich von einem konventionellen »Offline«-Assessment. Allerdings ergeben sich gewisse zusätzliche Problemstellungen, wie etwa das Ausschließen von Trainingseffekten aufgrund wiederholter (anonymer) Durchführung des Verfahrens oder die Sicherstellung der Bewerberidentität. Die Bandbreite implementierter Verfahren reicht dabei von Onlinespielen über Selbsteinschätzungs-Fragebögen und Testverfahren (vgl. auch Kap. 17) bis zu Problemlöseszenarien (vgl. auch Kap. 18) (vgl. Konradt et al. 2003). I.d.R. beschränken

208

16.1 Architektur und Funktionalität von Beschaffungsmanagementsystemen sich Assessmentkomponenten allerdings meist auf ein spezifisches Verfahren.

16.1.5

Analysekomponente Die Analysekomponente zielt auf die Bereitstellung relevanter Informationen zur gesamten Personalbeschaffung. Neben individuellen (ad hoc-) Abfragen können dabei auch standardisierte periodische Berichte ausgegeben werden. Damit wird grundsätzlich die Generierung beliebiger Kennzahlen aus den Daten der Datenbankkomponente möglich, wie etwa »mittlere Besetzungsdauer einer Vakanz«, »Bewerbungen je Ausschreibung«, »Einstellungen je Beschaffungskanal«, »Beschaffungskosten je Vakanz« etc. Umfangreichere »vorgefertigte« Auswertungsmöglichkeiten beziehen sich i.d.R. insbesondere auf ƒ die Bewerberanalyse, ƒ die Prozessanalyse und ƒ die Medienanalyse.

Bewerberanalyse

Aufbauend auf Angaben aus der Bewerbung sowie einem eventuellen zusätzlichen Online-Assessment, zielen Bewerberanalysen auf die Vorauswahl grundsätzlich geeigneter Kandidaten bzw. die Aussonderung grundsätzlich nicht geeigneter Kandidaten. Hierzu werden regelmäßig Ranglisten-, Filter- und Abgleichfunktionen angeboten. Die Ranglisten-Funktion (»Ranking«) sortiert die Bewerber B1 - Bn nach einem oder mehreren vom Anwender festzulegenden (ordinalen oder metrischen) Kriterien. Dabei bestimmt die Ausprägung des Kriteriums, wie z.B. die Schulabschlussnote, über den Rangplatz, der einem Bewerber zuzusprechen ist. Die Sortierung kann dabei aufsteigend oder absteigend stattfinden. Die Filter-Funktionen (»Filtering«) beziehen sich auf die Möglichkeit von Auswahlabfragen, mittels derer die Bewerber bzw. Bewerbungen nach bestimmten Stichworten und Kriterien, wie z.B. nach dem Vorliegen bestimmter Qualifikationen, selektiert werden kann. So kann der Kreis der für eine Vakanz in Frage kommenden Bewerber eingeschränkt werden. Mittels Filtering besteht umgekehrt auch die Möglichkeit, für bestimmte Kandidaten in der Vakanzdatei nach einer passenden Stelle zu suchen. Als Variante des Filterings werden häufig auch so genannte »ABC-Analysen« angeboten, die Bewerber nach ihrer Eignung in drei Klassen A (»einladen«), B (»abwarten«) und C (»absagen«) einteilt. Die Abgleichs-Funktion (»Matching«) zielt auf eine Zuordnung der Bewerber B1 - Bn zu den Vakanzen V1 - Vm im Sinne eines Abgleichs zwischen Bewerberqualifikationen und Vakanzanforderungen. Konventionell wird dies generell auf der Basis von 209

16

Beschaffungsmanagementsysteme Profilvergleichen realisiert. Bewerber werden dann den Vakanzen zugeordnet, für die sie die insgesamt geringste Über- und Unterdeckung aufweisen. Inzwischen existieren allerdings auch spezifische Matchingalgorithmen, die ein Matching über beliebige, auch »unscharfe Kriterien« zulassen (vgl. O.V. 2007). Abb. 16.2 deutet die einzelnen Analysearten an.

>

B4

»Ranking«

B6

B4 B1

»Filtering«

B3

V5

B5

B6

...

Š

B6

B2 Bn

>

B2 B3

B4 B1

B2

B5 B2

Bn

»Matching«

>

B3

V1

V2 V5

V3

Vn

Abb. 16.2: Zentrale Funktionen der Bewerberanalyse Prozessanalyse

210

Prozessanalysen (»Tracking«) dienen der Nachverfolgung des gesamten Bewerbungsprozesses. Das Tracking dient zunächst internen Belangen und gibt den Verlauf und Stand eines konkreten Bewerbungsprozesses wieder. Hierzu zählen sämtliche Arbeitsschritte bzw. Positionen, die eine Bewerbung innerhalb des Unternehmens durchläuft, insbesondere auch die Genehmigungsstufen. Als Datenlieferant für das Tracking dient die Bewerbungsdatei, die alle Vorgänge innerhalb des Bewerberprozesses protokolliert und anschließend für Auswertungen bereitstellt. Eine daraus abgeleitete Statusanzeige gibt Auskunft über den aktuellen Stand der Bewerbung. Auswertungen können z.B. hinsichtlich der Prozessgeschwindigkeit oder Anzahl der pro Bearbeiter bearbeiteten Bewerbungen erfolgen. Zusätzlich zum internen Tracking wird bei webbasierten Anwendungen häufig auch ein externes Tracking für Bewerber angeboten. Bewerber können dann

16.2 Anwendung von Beschaffungsmanagementsystemen den jeweils aktuellen Stand ihrer Bewerbung(en) abfragen und ggf. zielgerichtete Nachfragen an einzelne Bearbeiter starten. Medienanalyse

Als dritter Bereich werden auch für die verwendeten Ausschreibungsmedien umfangreichere Analysen angeboten. Im Einzelnen können etwa die Häufigkeit (Ausschreibungen pro Medium), die Kosten (Kostenvergleich zwischen den Medien), die Nutzung hinsichtlich bestimmter Vakanzen (Abhängigkeit der Mediennutzung von einem bestimmten Fachbereich) sowie der Erfolg (Zahl und Qualität der generierten Bewerbungen) analysiert werden. Dies ermöglicht eine qualifizierte Einschätzung einzelner Beschaffungsmedien und eine Justierung der Personalbeschaffungspolitik.

16.2

Anwendung von Beschaffungsmanagementsystemen Konventionell sprechen zunächst operative Rationalisierungsund Verbesserungspotenziale für die Anwendung von Beschaffungsmanagementsystemen. Zunehmend dürften Beschaffungsmanagementsysteme aber auch als Systemkategorie mit strategischem Potenzial zu gelten haben. Mögliche Rationalisierungspotenziale beziehen sich zunächst auf die Verringerung der Gesamtbearbeitungszeiten durch entsprechende Workflows. Von der Vakanz über Ausschreibung und Assessment bis zur Einstellung werden Teilaktivitäten (teil-)automatisiert und systematisch miteinander verknüpft (vgl. Mülder 2003a). Die lückenlose Dokumentation von Aktivitäten und Entscheidungen sowie deren eindeutige Zuordnung zu Akteuren erbringt eine hohe Prozesstransparenz mit entsprechenden Möglichkeiten eines umfassenden Beschaffungs(prozess)controllings. In Kombination mit der systematischen Verlagerung des notorisch aufwändigen Pflegens und Aktualisierens von Bewerberdaten auf die Bewerber ergeben sich erhebliche Einsparungspotenziale. Allerdings ist das nur bei Verwendung der formularbasierten Online-Bewerbung der Fall. Andere Kanäle können eine solche Rationalisierung nicht gewährleisten oder führen sogar – wie etwa die rein e-mail-basierte Bewerbung – zu einem deutlich erhöhten Bewerbungsaufkommen und damit zu zusätzlichem administrativem Aufwand (vgl. Strohmeier & Diederichsen 2006). Häufig sind Unternehmen daher bemüht, die Zahl papier- und email-basierter Bewerbungen zu minimieren bzw. vollkommen auszuschließen. Auch die Möglichkeit, die eigene Bewerbung zu »tracken«, kann Rückfragen bei der Personalabteilung seitens der Bewerber wesentlich reduzieren. Generell dürfte die Anwendung 211

16

Beschaffungsmanagementsysteme von Beschaffungsmanagementsystemen bereits bei mittlerem Bewerberaufkommen wirtschaftlich sinnvoll sein. Beschaffungsmanagementsysteme eignen sich damit zur rationellen Abwicklung mittlerer und größerer Bewerbungszahlen. Neben einer »bloßen« Rationalisierung lassen sich auch qualitative Verbesserungen der Personalbeschaffung erwarten. Zentrale Erwartungen werden hierbei an die Erhöhung der zeitlichen und räumlichen Reichweite von Ausschreibungen, verbesserte Möglichkeiten, das Unternehmen und die jeweiligen Vakanzen zu präsentieren, die systematische Unterstützung bei Bewerberanalysen und die Ausweitung bewerberbezogener Informationen durch Online-Assessment geknüpft. Allerdings zeigt sich insbesondere mit Blick auf e-Mail-Bewerbungen, dass die Zahl grundsätzlich geeigneter Bewerbungen nicht zwangsweise mit gestiegenen Bewerbungszahlen korrespondiert (vgl. Strohmeier & Diederichsen 2006). Weiter dürfte durch webbasierte Systeme auch die Zusammenarbeit und Koordination von einstellender Fachabteilung und Personalabteilung, Bewerbern und potenziellen »Beschaffungsdienstleistern« (Jobbörsen, Printmedien, Personalberatungen etc.) erheblich erleichtert werden.

Perspektiven

212

Insbesondere der in Anlehnung an das Kundenbeziehungsmanagement (»Customer Relationship Management [CRM]«) derzeit diskutierte Übergang zu Talent Relationship Management (TRM)Systemen könnte in Zukunft strategische Aspekte der Personalbeschaffung stärker in den Vordergrund rücken (vgl. etwa Richter & Stähler 2003). Im Kern stellt TRM eine IT-gestützte Strategie zur mittelfristig erfolgreichen Gestaltung der Arbeitsmarktbeziehungen dar. Zentraler Ansatzpunkt ist damit die Schaffung und Erhaltung guter Beziehungen zu der Personengruppe, die man als Interessenten oder Bewerber anstrebt. Dazu sollen bisherige Aktivitäten zusammengefasst und in integrierter Weise bearbeitet werden. Zentral sollen Personalmarketing, -beschaffung und -assessment zusammengefasst werden, wobei für jede dieser Funktionen kollaborative, operative und analytische Aspekte unterschieden werden. Abb. 16.3 deutet mögliche einzelne Aktivitäten im Rahmen eines so verstandenen TRM an. Als strategisches Konzept zielt TRM damit auf die Entwicklung längerfristiger unternehmensindividueller Beschaffungsstrategien, die mittels umfassender technischer Unterstützung durch TRM-Systeme realisiert werden. Gegenwärtige Systeme entwickeln sich langsam in Richtung eines TRM. Das Anbieten mehrer Kommunikationskanäle oder das Vorhalten einer integrierten Kontaktdatei bilden zentrale Beispiele aus dem kollaborativen Bereich.

16.2 Anwendung von Beschaffungsmanagementsystemen Marketing

Beschaffung

Assessment

Interessenten-Chat Corporate-Podcast Employer-Weblog ...

»Cold Calling« Jobagent Jobbörse ...

Telefoninterview Online-Fragebogen Auswahl-Chat ...

operativ

Ausdruck Direktmail Kampagnenorganisation ...

Ausschreibung Datenerfassung Spesenabrechnung ...

Test-Auswertungen Einladung Vorstellungsgespräch ...

analytisch

Kampagnenanalyse Responseanalyse Imageanalyse ...

Medienanalyse Prozessanalyse (»Tracking«) ...

Bewerberanalyse (»Ranking«, »Filtering«, »Matching«) ...

kollaborativ

Abb. 16.3: Funktionen und Ausprägungen des TRM Ausgereifte TRM-Systeme fehlen derzeit allerdings. Mit Blick auf die TRM-Konzeption gilt, dass operative Funktionen von derzeitigen Systemen am besten unterstützt werden, während im kollaborativen wie im analytischen Bereich noch Lücken bestehen. Verbreitung

Empirische Studien machen allerdings unterschiedliche Angaben zur Verbreitung von Beschaffungsmanagementsystemen. Während Studien zum »e-Recruiting« immer wieder die inzwischen weit fortgeschrittene, in größeren Unternehmen nahezu flächendeckende Verbreitung belegen (was die Anwendung von Beschaffungsmanagementsystemen impliziert) (vgl. etwa König et al. 2006), finden sich auch aktuelle Studien mit bemerkenswert niedrigen Verbreitungsgraden von 34% (vgl. Kabst & Girardini 2005, 41).

213

17

Testsysteme Testsysteme sind Anwendungen zur Eignungsdiagnostik im Rahmen der Personalauswahl und -entwicklung. Sie ermöglichen die Durchführung und Auswertung eines oder mehrerer standardisierter Verfahren zur Messung der Ausprägung verschiedener Leistungs- und Persönlichkeitsmerkmale.

17.1

Architektur und Funktionalität von Testsystemen Der idealtypische Aufbau eines Testsystems besteht aus einer Datenbasis mit Anforderungsdatei, Probandendatei, Testdatei und Durchführungsdatei, aus Komponenten zur Instruktion, Durchführung und Analyse und gegebenenfalls zur Profilerstellung, Testentwicklung und Testdisposition sowie der obligatorischen Anwenderschnittstelle (vgl. Abb. 17.1). Testsystem Anwenderschnittstelle Entwicklung Disposition Profilerstellung

Instruktion

Durchführung

Analyse

Anforderungen

Tests

Probanden

Durchführungen

Abb. 17.1: Idealtypische Architektur von Testsystemen Die Instruktionskomponente stellt Informationen für den Probanden zur Bearbeitung des Tests sowie teilweise auch Informationen für den Diagnostiker zur Auswertung und Bedienung des Systems bereit. Eine Probandendatei speichert personenbezogene Daten von Probanden. Die Durchführungskomponente er215

17

Testsysteme möglicht den Probanden das Durchführen von Tests. Hierbei erzielte Testergebnisse werden in einer Durchführungsdatei gespeichert. Die Auswertung und Interpretation von Testergebnissen erfolgt über eine Analysekomponente. Über eine Profilerstellungskomponente ist es teilweise möglich, Soll- bzw. Anforderungsprofile zu erstellen. Diese werden in einer Anforderungsdatei abgelegt. Teilweise vorhandene Dispositionskomponenten ermöglichen die Zusammenstellung diverser Test-Items sowie Testbatterien.

DIN 33430

Zur Qualitätssicherung berufsbezogener Eignungsbeurteilungen, Einstellungsverfahren und Einstellungstests wurde 2002 die DIN 33430 »Anforderungen an Verfahren und deren Einsatz bei berufsbezogenen Eignungsbeurteilungen« auf Initiative des Bundesverbandes deutscher Psychologen (BDP) erarbeitet. Sie beschreibt, wie Eignungsbeurteilungen zu planen und durchzuführen sind, welche Qualifikationsanforderungen die beteiligten Personen besitzen sollen und welche formalen Voraussetzungen geeignete Beurteilungsverfahren erfüllen müssen. Die Norm gilt dabei nicht nur für computergestützte Testsysteme, sondern für alle Verfahren der Eignungsdiagnostik, also bspw. auch für Assessment Center und Interviews (vgl. Deutsches Institut für Normung 2002). Es handelt sich hierbei um eine freiwillige Norm, d.h. die Anbieter von Testsystemen sind frei in der Entscheidung, ob sie nach der Norm arbeiten oder nicht. Vorhandene Anbieter befolgen die Norm jedoch zunehmend (vgl. Hänsgen 2003).

17.1.1

Datenhaltungskomponenten

Testdatei

Verfügbare Tests werden in einer Testdatei bzw. einer umfassenden Testdatenbank abgelegt. Bezogen auf die grundsätzlichen Testarten sind gegenwärtigen Systemen im Wesentlichen psychometrische Testverfahren implementiert. Die ohnehin in der Kritik stehenden projektiven Testverfahren eignen sich weniger zur Implementierung und werden kaum angeboten. Nach der Anzahl implementierter Tests kann zwischen Einzel-Systemen und »Test-Suiten« mit mehreren Tests unterschieden werden. Üblicherweise werden jedoch mehrere Tests angeboten. Inzwischen existieren mehrere umfangreiche Testsuiten, die zahlreiche Leistungs- und Persönlichkeitstests umfassen (vgl. Sarges & Wottawa 2005). Unter Rückgriff auf die Dispositionskomponente sind je nach Bedarf auch unternehmensindividuelle Zusammenstellungen von Testbatterien möglich. Elaborierte Systeme ermöglichen darüber hinaus die Ablage mittels einer Entwicklungskomponente erstellter, unternehmensindividueller Tests.

216

17.1 Architektur und Funktionalität von Testsystemen Um eine bessere Interpretation des Ergebnisses zu ermöglichen, werden Testergebnisse häufig in Bezug zu den Ergebnissen von Normgruppen gesetzt. Soweit solche Normierungen der implementierten Tests vorliegen, werden daher auch diese in der Testdatenbank abgelegt. Sind allgemeine testspezifischen Normen nicht vorhanden oder nicht ausreichend, ist teilweise auch die Abspeicherung unternehmensspezifischer Normierungen möglich (vgl. Kanning 2002, 78ff.). Anforderungsdatei

In einer teilweise vorhandenen Anforderungsdatei können unterschiedliche Anforderungsprofile zu Stellen oder Stellenkategorien der Organisation hinterlegt werden. Diese Anforderungsarten und -ausprägungen korrespondieren mit den durch die jeweiligen Tests erhobenen Merkmale und Merkmalsausprägungen. Solche Anforderungsprofile können nach der Durchführung von Tests auf Basis der Analysekomponente zum Abgleich mit den Probandenprofilen verwendet werden. So können weitergehende Informationen zur internen Eignung und Verwendbarkeit der Probanden geschaffen werden.

Probandendatei

Eine Probandendatei speichert persönliche Daten der Probanden wie Name, Alter, Geschlecht u.a.m. In der Probandendatei können zusätzlich auch Ergebnisse eines Abgleichs von (Stellen-)Anforderungen und Testergebnissen abgelegt werden.

Durchführungsdatei

In einer Durchführungsdatei werden die jeweiligen Testergebnisse der Probanden gespeichert. Dabei ist eine strukturierte Ablage nach Proband, Test, Durchführungszeitpunkt etc. möglich. Um Veränderungen im Zeitablauf erkennen zu können, werden Testergebnisse auch historisiert.

17.1.2

Profilerstellungskomponente Über eine teilweise vorhandene Profilerstellungskomponente kann die Festlegung eines Anforderungsprofils für einzelne Probanden oder Probandenkategorien erfolgen. Basierend auf dem Test zugrunde liegenden Merkmalen wird festgelegt, welches Niveau bzw. welches Intervall an Merkmalsausprägungen ein Proband für eine bestimmte Position erreichen soll. Teils kann hierzu auch auf Vorsysteme des Organisationsbereichs zurückgegriffen werden.

17.1.3

Entwicklungskomponente Eine teilweise vorhandene Entwicklungskomponente ermöglicht die Erstellung unternehmensindividueller Tests. Genügen die bereitgestellten Standardtestverfahren den Anforderungen des Un217

17

Testsysteme ternehmens nicht, können so über die Entwicklungskomponente individuelle Test-Items erstellt und Fragebögen gestaltet werden. Entwicklungskomponenten lassen sich auch verwenden, um Qualifikationen und Fachkenntnisse von Probanden zu überprüfen. Einmal entwickelte Individual-Tests können in das Repertoire des Testsystems aufgenommen werden und stehen dann allen anderen Komponenten des Systems zur Verfügung.

17.1.4

Dispositionskomponente Um Testabläufe individuell gestalten zu können, bieten Testsysteme zunehmend Dispositionskomponenten an. Die Dispositionskomponente kann zunächst von einem Diagnostiker verwendet werden, um individuelle Testabläufe zu gestalten. Darüber hinaus können adaptive Testverläufe, bei denen der weitere Verlauf des Tests von den erzielten Ergebnissen abhängt, auch in automatisierter Weise von der Dispositionskomponente zur Laufzeit der Testdurchführung gestaltet werden. Entsprechend können mittels der Dispositionskomponente zunächst nicht-adaptive Einzeltests oder nicht-adaptive Kombinationen mehrerer nacheinander auszuführender Tests (»Testbatterien«) zusammengestellt werden. In mikroadaptiver Weise bieten einige Tests auch die Möglichkeit, interne Itemfolgen nach den Ergebnissen der jeweils vorangegangenen Items auszuwählen. Solche, meist automatisiert von der Dispositionskomponente durchgeführte, mikroadaptiven Anpassungen weisen insbesondere bei so genannten Power- und Speed-Tests Vorteile auf. Power-Tests zielen darauf ab, die maximale Leistungsfähigkeit von Probanden zu ermitteln. Entsprechend können mikroadaptive Systeme basierend auf gerade erzielten Ergebnissen ohne Verzögerungen die jeweils geeigneten nächsten Items selektieren, um eine probandenspezifische Zusammenstellung zu finden, die die Leistungsfähigkeit des Probanden optimal austestet. Gewisse Vorteile bieten sich auch bei Speed-Tests, die darauf abzielen, dass Probanden in einem vorgegeben Zeitraum möglichst viele Aufgaben bearbeiten. Hier werden dem Probanden nur die Items vorgelegt, die er aktuell auch bearbeiten kann. Dies vermeidet Frustrationen wenig leistungsfähiger Probanden und kann insgesamt verdecken, dass es sich um einen Speed-Test handelt, wo dies gewünscht ist (vgl. Hänsgen 1999, 24ff.). In makroadaptiver Weise kann auch die Auswahl und Reihenfolge der nacheinander zu bearbeitenden Tests von den Ergebnissen vorangegangener Tests bestimmt werden (vgl. Abb. 17.2).

218

17.1 Architektur und Funktionalität von Testsystemen nicht-adaptiver Einzeltest

(mikro-)adaptiver Einzeltest

nicht-adaptive Testbatterie

(makro-)adaptive Testbatterie

Test1

Test1

Test1

Test1

Item1

Item1 XOR

Test2

XOR

Item2 Item3

Item2

...

XOR

Test3

XOR

...

Item3 ...

Test2

...

Test3 ...

...

Abb. 17.2: Mögliche Testkonfigurationen

17.1.5

Instruktionskomponente Die Instruktionskomponente führt die Probanden in die Bearbeitung und Durchführung des Tests ein. Probanden erhalten Informationen zur Benutzung der Eingabemedien sowie testspezifische Hinweise, die häufig in Form von HTML-Seiten präsentiert werden. Darüber hinaus werden in einigen Systemen Beispielaufgaben und -fragen angeboten, damit sich der Proband mit der Handhabung des Systems und des Tests vertraut machen kann.

17.1.6

Durchführungskomponente Die Durchführungskomponente ermöglicht die Antworteingabe der Probanden zu den Testfragen bzw. -aufgaben. Je nach Ausgestaltung des Tests sind Korrekturen sowie ein Vor- und Zurückblättern zwischen den Fragen möglich. Die Antworten des Probanden werden in der Durchführungsdatenbank gespeichert und stehen damit für die Analysekomponente zur Verfügung. Die Durchführungskomponente übernimmt dabei die gesamte Ablaufsteuerung des Tests. Sie reagiert damit auf Steuerungsanweisungen des Probanden wie etwa Vor- und Zurückblättern. Ebenso übernimmt sie automatisierte Aufgaben wie beispielsweise die Zeitsteuerung bei zeitlich begrenzten Bearbeitungsvorgaben für einzelne Tests oder Testfolgen. Bei adaptiven Tests bzw. adaptiven Testbatterien interagiert die Durchführungskomponen-

219

17

Testsysteme te auch mit der Dispositionskomponente, um entsprechend mikro- und/oder makroadaptive Abläufe sicherzustellen.

17.1.7

Analysekomponente Eine Analysekomponente ermöglicht es dem Diagnostiker, die durchgeführten Tests strukturiert zu analysieren. Zu diesem Zweck werden verschiedene Auswertungsfunktionen zur Verfügung gestellt, die auch grafische Aufbereitungen umfassen.

Auswertungen

Allgemein lassen sich Einzeltestauswertungen und Multitestauswertungen generieren. Bei der Einzelauswertung erfolgt die Analyse einer bestimmten Messung, bei der Multitestauswertung werden verschiedene Testergebnisse verglichen. Im Sinne von Vergleichsauswertungen können dann ƒ mehrere Testergebnisse verschiedener Testpersonen, ƒ mehrere Testergebnisse derselben Person (Wiederholungsmessungen), ƒ eine Gegenüberstellung von Selbst- und Fremdbild oder ƒ eine Gegenüberstellung des Ergebnisprofils mit dem Anforderungsprofil generiert werden (vgl. Sarges & Wottawa 2005, 587f.). Stressresistenz 10 8 6 4

...

Intelligenz

2 0

Extraversion

Leistungsmotivation

Anforderungsprofil Ergebnisprofil

Abb. 17.3: Vergleich von Ergebnis- und Anforderungsprofil 220

17.1 Architektur und Funktionalität von Testsystemen Abb. 17.3 zeigt die Gegenüberstellung des Ergebnisprofils eines Probanden und das zugehörige Anforderungsprofil bezüglich der getesteten Merkmale. Das Aufzeigen von Über- und Unterdeckungen ermöglicht hier genauere Aufschlüsse über mögliche Eignungen oder Entwicklungsdefizite des Probanden. Um generelle Aussagen treffen zu können, werden die Ergebnisse einzelner getesteter Merkmale oft gewichtet. Als wichtiger erachtete Merkmale können so besonders berücksichtigt werden. Können sich die einzelnen Merkmalsausprägungen gegenseitig kompensieren, d.h. kann ein niedriger Wert des Merkmals Intelligenz durch einen hohen Wert bzgl. der Berufserfahrung ausgeglichen werden, so ist auch die Mittelwertbildung über die einzelnen Merkmale eine Möglichkeit zur Erreichung eines vergleichbaren Einzelwertes (vgl. Kanning 2002, 57f.). Über solche Einzelwerte können summarische Vergleiche von Probanden erfolgen. Durch ein sukzessives Abtesten unterschiedlicher Anforderungsprofile kann weiter herausgefunden werden, welche Stelle(nkategorie) am besten auf das Ergebnisprofil »passt«. Teilweise existieren auch »Matching«-Funktionen, die für Stellen oder Personen automatisiert nach dem jeweils besten Pendant suchen (vgl. auch Kap. 16). Normvergleich

Liegen entsprechende Normierungen der auszuwertenden Tests vor, liefern auch Vergleiche von Testergebnissen mit den Normergebnissen regelmäßig weitere Aufschlüsse: Das Ergebnis eines Probanden kann so in Relation zu den Ergebnissen seiner Alters-, Bildungs- und Geschlechtskategorie betrachtet werden, also etwa Rechenfähigkeit eines 43-jährigen männlichen Probanden mit Hochschulabschluss im Vergleich zur mittleren Rechenfähigkeit 40-45 jähriger Männer mit Hochschulabschluss.

Interpretation

Neben der bloßen Wiedergabe erzielter Testergebnisse existieren teilweise auch »Interpretations- und Befundungshilfen«, die eine inhaltliche Auslegung von Testergebnissen ermöglichen. So wird es etwa möglich, Testergebnisse wie »110 Punkte im Intelligenzstrukturtest« besser einschätzen zu können. Obwohl solche Ergebniserläuterungskomponenten einer klassischen Forderung der Wirtschaftsinformatik nachkommen, werden diese im Rahmen des latenten Disputs über die Zulässigkeit der Anwendung psychologischer Tests durch »Nicht-Psychologen« seitens psychologischer Diagnostiker durchaus auch kritisch gesehen.

Berichte

Neben individuellen Auswertungen bestehen zusätzlich Möglichkeiten, vorgefertigte Berichte zu generieren und auszudrucken. Eine Standardauswertung ist etwa die Ausgabe eines generellen 221

17

Testsysteme Stärken-Schwächen-Profils, das etwa im Rahmen der Personalentwicklung Verwendung finden kann (vgl. Sarges & Wottawa 2005, 596). Unter Rückgriff auf Textbausteine können Ergebnisse oft auch in ausformuliertem Fließtext ausgegeben werden. Hierbei besteht jedoch die Gefahr einer unzulässigen Vergröberung der Ergebnisse. Derartige automatisierte Ausgaben bedürfen daher i.d.R. einer Nachbearbeitung bzw. Prüfung und Absicherung durch einen kompetenten menschlichen Bearbeiter (vgl. Hänsgen 1999, 31). Entsprechend sind auch Freitexteingaben möglich. In diese können neben Interpretationen der Testergebnisse auch weitere Beobachtungen, etwa eines während des Tests anwesenden Testleiters, einfließen.

Längsschnittanalysen

Die Ergebnisse der Tests werden in der Durchführungsdatei historisiert, wodurch zusätzlich auch eine Analyse der Entwicklung im Zeitablauf ermöglicht wird. Insbesondere im Rahmen der Personalentwicklung ist es von Interesse, die Entwicklung von Mitarbeitern über die Zeit zu beobachten und zu dokumentieren. Die auf den Testergebnissen aufbauenden Entwicklungsmaßnahmen sowie die Fähigkeit des Mitarbeiters sich weiterzuentwickeln und seine Potenziale auszuschöpfen sowie seine Schwächen zu eliminieren, können über die Auswertungen im Zeitablauf beobachtet und kontrolliert werden.

17.1.8

(Probanden-)Anwenderschnittstelle Für Testsysteme ist eine ergonomische Gestaltung der probandenseitigen Anwenderschnittstelle von großer Bedeutung (vgl. Booth 1998). So hat bspw. ein Proband, der in der Benutzung einer Tastatur sehr geübt ist und diese blind bedienen kann, einen Vorteil bei der Bearbeitung von (Speed-)Tests. Die Tastatur beeinflusst in diesem Fall insofern das Testergebnis, als dass dieser Proband u.U. besser abschneidet, da ihm eine schnellere Reaktion möglich ist. Um an dieser Stelle Bedienvorteile zu eliminieren, werden bspw. spezielle Testtastaturen mit wenigen relevanten Tasten, Maus, Kontaktbildschirm (»Touchscreen«) oder Lichtgriffel (»Lightpen«) verwendet. Die Koordinationsanforderung bei Touchscreen und Lichtgriffel kommt dabei »natürlichen« Bewegungsabläufen am nächsten. Die Orientierung erfolgt über den Bildschirm, und die motorische Bewegung wird über die Wahrnehmung gesteuert (vgl. Hänsgen 1999, 23). Eine weitere Möglichkeit ist die Bereitstellung von Spracheingabemöglichkeiten, was derzeit allerdings keine große Verbreitung gefunden hat.

222

17.2 Anwendung von Testsystemen Immer häufiger werden auch Browsersysteme als Anwenderschnittstelle von Testsystemen verwendet, was insbesondere im Rahmen der Personalbeschaffung ein webbasiertes Testen ermöglicht (vgl. auch Kap. 16 und 28). Die damit möglich werdende räumliche Trennung von Test-Leiter bzw. Diagnostiker und Proband eröffnet neue Möglichkeiten des raum-zeitlich getrennten Testens, ist aber ebenso mit einigen zu klärenden Aspekten verbunden, wie etwa zentral mit der offenen Fragen der Durchführungsobjektivität, unerwünschten Trainingseffekten sowie fraglicher Probandenidentität (vgl. Konradt et al. 2003).

17.2

Anwendung von Testsystemen Generell werden Tests als klassische eignungsdiagnostische Verfahrgruppe zur Generierung von Informationen im Rahmen der (externen oder internen) Personalauswahl, teils aber auch der Personalentwicklung eingesetzt (vgl. Sarges & Wottawa 2005, VII). Studien zur Übertragbarkeit konventioneller Tests auf generelle wie webbasierte Systeme zeigen im Hinblick auf die methodische Güte wie auf die Akzeptanz bei Probanden generell eher ermutigende Ergebnisse (vgl. Konradt et al. 2003 sowie Potowski & Bobko 2004). Wegen verschiedener Vorteile im Vergleich zu konventionellen »Papier-und-Bleistift«-Anwendungen ist eine Anwendung daher nicht nur möglich, sondern auch vorteilhaft. Zunächst kann das Testen über räumliche Distanzen hinweg erfolgen. Bei webbasierten Systemen können so beispielsweise auch Informationen über bislang unbekannte Bewerber gewonnen werden, ohne dass diese aufwändig zu einem Test eingeladen (und entsprechende Spesen bezahlt) werden müssen. Weiter können sehr große Probandenzahlen (wenn nötig auch gleichzeitig) getestet werden. Die Kosten für die Testdurchführung können dabei erheblich gesenkt werden. Auch können vorgegebene Bearbeitungszeiten, etwa bei Speed-Tests, besser kontrolliert und eingehalten werden. Einmal abgespeicherte Testergebnisse können unmittelbar automatisiert ausgewertet und visualisiert werden, was weitere Zeit- und Kostenersparnisse bringt. Werden Tests in einem Unternehmen als diagnostische Verfahren eingesetzt, dürften daher insbesondere Wirtschaftlichkeitsgründe nachdrücklich für die Anwendung von Testsystemen sprechen.

Verbreitung

Es sind derzeit keine empirischen Studien zur Verbreitung von Testsystemen bekannt. Angesichts der zu erwartenden ökonomischen Vorteile dürften wohl neben den breiter eingesetzten Leis223

17

Testsysteme tungstests zunehmend auch Persönlichkeitstests in elektronischer Form durchgeführt werden (Sarges & Wottawa 2005, VIII).

224

18

Szenariosysteme Szenariosysteme (Computersimulierte Szenarien, Problemlöseszenarien, »Scenarios«) sind Anwendungen, die für Zwecke der Eignungsdiagnose und/oder des Trainings ein komplexes (Steuerungs-)Problem simulieren, welches von einem Probanden bearbeitet und hinsichtlich vorgegebener Zielsetzungen möglichst gut gelöst werden soll (vgl. Funke 1995 und Wagener 2001).

18.1

Architektur und Funktionalität von Szenariosystemen Der idealtypische Aufbau eines Szenariosystems besteht aus einer Datenhaltungskomponente mit Dateien zu Probanden und den einzelnen Durchführungen des Szenarios, einer InstruktionsDiagnose- und Durchführungskomponente sowie der obligatorischen Anwenderschnittstelle (vgl. Abb. 18.1). Szenariosystem Anwenderschnittstelle Durchführungskomponente Instruktionskomponente

Analyse

Entscheidung

Diagnosekomponente

Ablaufsteuerung

Probanden

Durchführungen

Abb. 18.1: Idealtypische Architektur von Szenariosystemen Die Instruktionskomponente unterstützt die fachliche und systembezogene Einführung des Probanden in das zu bearbeitende Szenario. Über die Durchführungskomponente agiert der Proband im Szenario. Hier stehen ihm Funktionalitäten zur Analyse des Problems und zur Eingabe seiner jeweiligen Entscheidungen zur Verfügung. Eine Ablaufsteuerung, in der die Struktur des entsprechenden Szenarios hinterlegt ist, dient der Regelung des ge225

18

Szenariosysteme samten Szenarioablaufs. Die Probandendatei enthält Daten zu denjenigen Personen, die das Szenario bearbeiten. Die Durchführungsdatei protokolliert alle Aktionen des Probanden sowie die daraus resultierenden Ergebnisse. Über die Diagnosekomponente erfolgt schließlich die automatisierte Auswertung der durchgeführten Problemlösung.

18.1.1

Datenhaltungskomponenten Üblicherweise werden Probanden und Szenariodurchführungen getrennt voneinander gespeichert, um auch Mehrfachdurchführungen eines Szenarios durch denselben Probanden effizient erfassen zu können.

Probandendatei

Als Probanden werden die Personen bezeichnet, die das entsprechende Szenario durchführen. Zentrale Probandengruppen sind daher i.d.R. Mitarbeiter und Bewerber. In einer Probandendatei werden personenbezogene Daten zum Probanden wie Name, Alter, Geschlecht etc. abgespeichert. Sollen erzielte Szenarioergebnisse mit anderen Informationen zur Qualifikation des Probanden kontrastiert werden, können in die Probandendatei auch Qualifikationsdaten und Ergebnisse weiterer eignungsdiagnostischer Verfahren wie etwa von Intelligenztests (vgl. Kap. 17) eingestellt werden.

Durchführungsdatei

Eine weitere Datei erfasst die einzelnen Durchführungen. Neben allgemeinen klassifizierenden Daten wie durchführender Proband, Datum der Durchführung, Art der Durchführung (Erst- vs. Wiederholungsdurchführung), eingesetzte Szenariovariante etc. wird hier sowohl der Prozess der Szenariobearbeitung als auch dessen Ergebnisse detailliert protokolliert. Unter die Prozessdaten fallen insbesondere die vom Probanden durchgeführten Informationsbeschaffungsaktivitäten sowie die letztendlich getroffenen Entscheidungen des Probanden. Ergebnisdaten beziehen sich dann auf die jeweilig realisierten Outputgrößen des Szenarios. Daten der Durchführungsdatei bilden die Grundlage für detaillierte Auswertungen der Diagnosekomponente.

18.1.2

Durchführungskomponente Die Durchführungskomponente beinhaltet die zentralen Inhalte und Funktionalitäten des Szenariosystems. Die formale und semantische Struktur eines Szenarios sind dabei in der Ablaufsteuerungskomponente hinterlegt. Eine Analysekomponente erlaubt es dem Probanden, sich notwendige entscheidungsunterstützende Informationen zu beschaffen. Mittels einer weiteren Komponente

226

18.1 Architektur und Funktionalität von Szenariosystemen können dann getroffene Entscheidungen im System umgesetzt werden. Ablaufsteuerung

Die Ablaufsteuerung enthält zunächst die formale und die semantische Struktur des zugrunde liegenden Szenarios. Szenarien sind artifizielle komplexe Probleme, die einen mehr oder weniger engen Bezug zu realen Problemsituationen aufweisen. Sie verlangen vom Probanden das Kontrollieren und Steuern komplexer dynamischer Systeme wie z.B. die Leitung eines Unternehmens (vgl. Funke 1995, 145). Formal betrachtet stellen Szenarien Systeme dar, bei denen gewisse Inputvariablen über gewisse interne Variable mit gewissen Outputvariablen verbunden sind. Abb. 18.2 deutet die formale Struktur eines Szenarios an.

Input1

Variable1

Input2

Output1 Variable4

Output2

Variable2 Input3

Variable3

Input...

Output3 Variable...

Output...

verdeckt

Abb. 18.2: Formale Szenariostruktur (nach Wagener 2001, 87ff.) Diese rein formale Struktur erfährt zur besseren Verständlichkeit eine so genannte »semantische Einkleidung«, d.h. im Rahmen eines Gesamtkontextes werden die Variablen näher bestimmt. Grundsätzlich ist man bemüht, eine möglichst realitätsnahe semantische Einkleidung zu finden. Entsprechend finden sich Szenarien, die sich etwa auf das Management eines Flughafens, die Steuerung eines Entwicklungshilfeprojektes oder die Bekämpfung von Waldbränden beziehen. Um jedoch den Einfluss unterschiedlicher Vorkenntnisse der Probanden auf die Problemlösegüte zu eliminieren, wählt man teils auch dezidiert realitätsferne Szenarien. Beispielsweise sollen auf einem fiktiven Planeten verschieden fiktive Lebewesen in einen gewissen Zielzustand gebracht werden. Ebenso sind auch Szenarien bekannt, die mehrere unterschiedliche semantische Einkleidungen derselben formalen Struktur erlauben.

227

18

Szenariosysteme Probanden sollen nun generell über die Manipulation der Inputvariablen erwünschte Zustände der Outputvariablen herbeiführen. Dies erfolgt in der Interaktion der Ablaufsteuerung mit den Analyse- und Entscheidungsfunktionen. Hat der Proband ein gewisses Set an Inputs spezifiziert, dann berechnet die Ablaufsteuerung auf Basis der formalen Szenariostruktur die sich daraus ergebenden Outputs. Die interne Struktur des Szenarios und der korrespondierende Algorithmus sind dem Probanden dabei allerdings i.d.R. unbekannt, da ihm nur Input- und Outputvariablen offen gelegt werden. Mit den Outputvariablen erhält der Proband Rückmeldungen über die Konsequenzen seiner Entscheidungen im Szenario. Um Zeitverzögerungen und Lernen des Probanden berücksichtigen zu können, beschränken sich Szenarien nicht auf eine Durchführung, sondern koppeln mehrere Durchführungen periodisch hintereinander (vgl. Abb. 18.3).

Proband

Input t1

Input t2

Input t3

...

System

Output t1

Output t2

Output t3

...

t1

t2

t3

...

Abb. 18.3: Zeitlicher Szenarioablauf Der durch das System erzeugte Output einer Periode bildet dann die veränderte Ausgangssituation für die Nachfolgeperiode. Ein derartiger Durchlauf von der Eingabe des Probanden bis zur Ausgabe über die Outputvariablen wird als (Simulations-)Takt bezeichnet. Dabei kann ein Takt zeitlich begrenzt sein, oder aber dem Probanden wird unbegrenzt Zeit zur Eingabe gelassen. Über die Taktfolgen wird die Dynamik eines Szenarios realisiert (vgl. Strauß & Kleinmann 1995, 108f.). Generell weisen Szenarien damit die Merkmale der ƒ Polytelie, ƒ Vernetztheit, ƒ (Eigen-)Dynamik, ƒ Intransparenz und ƒ Komplexität auf (vgl. Funke 1995, 145f. und Wagener 2001, 27ff.). Polytelie (»Vielzieligkeit«) ist bei Szenarien gegeben, weil i.d.R. stets mehrere Outputgrößen O1 - On vorliegen, die als Zielgrößen gemein228

18.1 Architektur und Funktionalität von Szenariosystemen sam zu optimieren sind. Regelmäßig werden dabei auch ausdrücklich konkurrierende Zielgrößen, wie etwa Kosten und Qualität, verwendet, die vom Probanden ein Ausbalancieren verlangen. Im systemtheoretischen Sinne handelt es sich bei Szenarien um vernetzte Systeme, denn Input-, Intern- und Outputvariablen sind vielfach miteinander verbunden. Dabei können auch Rückkopplungsschleifen existieren, bei denen Veränderungen einer Variablen über mehrere andere Variablen wieder auf die Ursprungsvariable zurückwirken. Entsprechend kann der Einfluss einer Variablen nicht isoliert betrachtet werden. Szenarien sind weiter (eigen-)dynamisch. Sie verändern sich im Zeitablauf entweder durch die steuernden Eingriffe des Probanden oder – zumindest teilweise – auch intern durch die Ablaufsteuerung initiiert. Entsprechend ist die Ausprägung einer Zustandsvariablen zum Zeitpunkt t0 abhängig von den Eingaben des Probanden, den Einflüssen anderer Variablen zum Zeitpunkt t-1 und/oder von den Aktivitäten der Ablaufsteuerung. Beinhaltet die Szenariostruktur zusätzlich Zeitverzögerungen, so können auch weiter zurückliegende Werte zu den Zeitpunkten t-2, t-3 etc. die Zustandsvariable zum Zeitpunkt t0 beeinflussen. Teilweise sehen Szenarien auch eigendynamisch erzeugte »Katastrophen« vor (etwa »Explosion im Hangar«, »Ausfall der Regenzeit« oder »mehrfache Brandstiftung im Wald«), um die Reaktionen von Probanden unter speziellen Belastungssituationen beobachten zu können. Intransparenz spiegelt die mangelnde Information über die Zustände und Verknüpfung der Variablen sowie die Konsequenz der Eingriffe des Probanden wider. I.d.R. werden den Probanden nur die Input- und Outputvariablen offen gelegt, während Anzahl, Art und Verknüpfungen der internen Variablen V1 bis Vn unbekannt bleiben. Die eigentliche Szenariostruktur, die Inputund Outputvariablen miteinander verbindet, bleibt ihm zunächst verschlossen. Sie muss im Laufe der Szenariobearbeitung vom Probanden entsprechend (re-)konstruiert werden. Als Ergebnis dieser Einzelmerkmale repräsentieren Szenarios komplexe Probleme. Als Maß für die Komplexität wird meist die Anzahl der Variablen und ihrer Verknüpfungen genannt. Je größer die Anzahl der Variablen und/oder ihrer Verknüpfungen, umso komplexer ist das Szenario. Sehr komplexe Szenarien umfassen bis zu 2.000 multipel vernetzte Variable (vgl. Funke 1998, 91). Aber auch die Ausprägung der oben erwähnten Merkmale Polytelie, Vernetztheit, Dynamik und Intransparenz werden zur Bestimmung der Komplexität herangezogen (vgl. zu einem Überblick Strauß & Kleinmann 1995, 110ff.) 229

18

Szenariosysteme

Analysefunktion

Über Funktionen zur Informationsbeschaffung kann der Proband sich über den Zustand und den Verlauf der einzelnen Systemvariablen informieren. Hierbei wird sichergestellt, dass die Intransparenz des Szenarios bestehen bleibt, d.h. die beschaffbaren Informationen geben keinen vollkommenen Aufschluss über die Struktur des Szenarios. Weiterhin ist es bei einigen Systemen möglich, die Festlegung der Inputgrößen und deren Auswirkungen auf die Outputgrößen zu simulieren (vgl. Funke 1995, 160ff.). Der Proband kann dann eine »What If-Analyse« durchführen, die Aufschluss über die Konsequenzen möglicher Entscheidungen gibt. Damit ist ihm die Möglichkeit gegeben, vermutete Systemzusammenhänge zu überprüfen. Diese Informationen kann der Proband zur Findung seiner endgültigen Entscheidung verwenden.

Entscheidungsfunktion

Wie erwähnt legt der Proband über die Entscheidungsfunktionalität die jeweiligen Inputgrößen fest. Diese sind nicht mehr reversibel und führen zu entsprechenden Konsequenzen im Szenario, welche als Grundlage für die nachfolgenden Entscheidungen dienen. I.d.R. werden hierzu einfach Werte für die gewünschten Ausprägungen der Inputvariablen angegeben und bestätigt.

18.1.3

Instruktionskomponente Zur Einführung der Probanden in die Hintergründe, Ziele und Bedienung des Szenarios werden zunehmend eigenständige Komponenten angeboten. Ziel der Instruktionskomponente ist damit, eine automatisierte system- und fachbezogene Einführung des Probanden in das Szenario zu gewährleisten. Die systembezogene Einführung dient der Erläuterung konkreter Bedienvorgänge, wie Eingabe von Inputparametern, Ausführen von Analysen, fakultative Hilfefunktionen etc. Die fachbezogene Einführung dient der Erläuterung des Problemkontextes und der konkreten Aufgabenstellung des Szenarios. Fehlt eine Instruktionskomponente, muss die Einführung durch einen entsprechenden Versuchsleiter erfolgen. Nach der Ausgestaltung der Instruktionskomponente können grob zwei Varianten unterschieden werden. Eine einfachere Variante präsentiert dem Probanden die Einführung in Texte, häufig in Form von HTML-Seiten, die Auskunft über Bedienung und fachlichen Hintergrund des Szenarios geben. Eine zweite, anspruchsvollere Variante ermöglicht zusätzlich die Durchführung eines Testlaufes des Szenarios. Um hierbei nicht bereits unerwünschte, weil das Ergebnis verzerrende Lerneffekte zu erzielen,

230

18.1 Architektur und Funktionalität von Szenariosystemen bleiben solche Durchführung oft auf wenige Takte beschränkt. Zusätzlich wird die Zahl der Handlungsmöglichkeiten und Ereignisse bei solchen Probedurchläufen oft eingeschränkt.

18.1.4

Diagnosekomponente Die Beurteilung eines Probanden erfolgt mittels der Diagnosekomponente. Diese ermöglicht grundsätzlich automatisierte Auswertungen hinsichtlich der Steuerungs- und der Verhaltensleistung des Probanden (vgl. Wagener 2001, 77ff. und Funke 1995, 149ff.). Die Diagnosekomponente verfügt dazu über Algorithmen, die verschiedene Maße der Steuerungs- und Verhaltensleistung berechnen. Diese automatisierte Auswertung des Szenarios gestaltet sich damit schnell und kostengünstig. Es existieren allerdings keine allgemein gültigen Maße für die Auswertung von Szenarien. Entsprechend weisen verschiedene Szenariosysteme unterschiedliche Maße auf. Die Maße für die Steuerungsleistung sind an die semantische Einkleidung gekoppelt und variieren damit von Szenario zu Szenario (vgl. Hasselmann 1993, 47). Die Maße für die Verhaltensleistung ergeben sich aus der zugrunde liegenden psychologischen Theorie zum Problemlöseverhalten. Additiv oder alternativ zur Berechnung von Maßen kann auch ein Ausdruck der protokollierten Aktivitäten zur manuellen Auswertung durch einen Beurteiler erfolgen.

Steuerungsleistung

Die Steuerungsleistung wird über die Erreichung der Steuerungsziele anhand der die Zielvorgaben repräsentierenden Outputvariablen ermittelt. Der erreichte Wert des Probanden wird dazu i.d.R. mit einem möglichen Optimum verglichen. Bspw. wird das von einem Probanden erwirtschaftete Gesamtvermögen mit dem im Rahmen des Szenarios maximal erwirtschaftbaren Vermögen verglichen. Neben absoluten Größen werden hier teils auch Trendentwicklungen der letzten Takte (Aufwärts- vs. Abwärtstrend) berücksichtigt (vgl. Funke 1995, 49ff.). Da Szenarien aufgrund ihrer Polytelie oft keine eindeutigen Zielvorgaben machen, besteht allerdings oft keine »Ideallösung«, und eine eindimensionale Bewertung der Lösungsgüte ist nicht adäquat. Darüber hinaus ist eine Vergleichbarkeit des Steuerungsergebnisses zwischen verschiedenen Probanden nur sehr eingeschränkt gegeben. Dies ist zunächst in den unterschiedlichen Eingriffen der jeweiligen Probanden begründet, die dementsprechend das Szenario individuell beeinflussen. So wird sich ein Szenario zu einem bestimmten Zeitpunkt bei unterschiedlichen Probanden in einem andern Zustand befinden. Die Vergleichbarkeit der Ergebnisse leidet

231

18

Szenariosysteme noch stärker, wenn eigendynamische Systeme dem Szenariogeschehen unterschiedliche interne Ereignisse hinzufügen.

Verhaltensleistung

Die Verhaltensleistung wird über das in der Durchführungsdatenbank protokollierte Informations- und Entscheidungsverhalten des Probanden ermittelt, das die faktische Steuerungsleistung erbracht hat. Der komplette Problemlöseprozess wird protokolliert. Damit kann eine lückenlose Auswertung über den gesamten Prozess der Lösungsfindung stattfinden. Maße, die das Verhalten im Umgang mit der Aufgabe erheben, werden teils aus psychologischen Theorien abgeleitet, teils werden zahlreiche Einzelaspekte erhoben. Im Bereich des Informationsverhaltens werden etwa Häufigkeit und Intensität der Informationsnachfrage, Art und Häufigkeit des Tests von Zusammenhängen, Eingriffs- und Effektkontrollen automatisiert erfasst. Im Bereich des Entscheidungsverhaltens werden etwa Maße wie Häufigkeit und Ausmaß von Entscheidungen, Variation der Variablen, Einfach- und Mehrfacheingriffe, Breite der Entscheidungsbereiche, Entscheidungszeitpunkte, Absicherung durch Tests etc.) erhoben. Erkenntnisse zur Verhaltensleistung vertiefen und ergänzen daher die Erkenntnisse um den reinen Steuerungserfolg und können weitere Aufschlüsse über die Problemlösefähigkeit von Probanden geben. Aufgrund der oft umfangreichen Detailergebnisse erfolgt teilweise auch eine Zusammenfassung der Maße für die Steuerungsund die Verhaltensleistung zu einem Gesamtwert, der die Problemlösefähigkeit von Probanden widerspiegelt (vgl. Funke 1995, 163).

18.1.5

(Probanden-)Anwenderschnittstelle Während bei früheren Szenariosystemen durchaus eine Bedienung durch einen Versuchsleiter üblich war, ist heute die direkte Bedienung durch den Probanden gängige Praxis (vgl. Wagener 2001, 51ff.). Da insbesondere für die Eignungsdiagnostik eine möglichst intuitive Bedienung des Szenarios notwendig ist, wird der Ausgestaltung der Probanden-Anwenderschnittstelle besondere Bedeutung zugemessen. Komplizierte Schnittstellen können zu einer kognitiven Belastung von Probanden und damit möglicherweise zu einer Verzerrung des Messergebnisses der Problemlösekompetenz führen. Entsprechend wird auf Motivationswirkung und Ergonomie der Anwenderschnittstelle großen Wert gelegt. Neben konventionellen grafischen Anwenderschnittstellen, die über Maus und Tastatur zu steuern sind, existieren auch Systeme, die über berührungsempfindliche Kontaktbildschirme

232

18.2 Anwendung von Szenariosystemen (»Touchscreen«) oder über Spracheingabe gesteuert werden, was eine Benachteiligung ungeübter Anwender verhindern soll.

18.2

Anwendung von Szenariosystemen Szenariosysteme dienen im Personalmanagement zwei zentralen Zwecken: der Eignungsdiagnostik im Rahmen der Personalauswahl und -platzierung sowie dem Training im Rahmen der Personalentwicklung.

Diagnostik

Ziel des Einsatzes von Szenariosystemen in der Eignungsdiagnostik ist die Diagnose von Leistung und Verhalten der Probanden bei der Lösung komplexer Probleme, wie sie sich auch im Arbeitsleben insbesondere für Führungskräfte stellen. Die Maße für Leistung und Verhalten sollen als Prädiktoren für die Vorhersage des späteren Erfolgs beim Problemlösen dienen und damit als Grundlage für Personalauswahl-, Platzierungs- und Entwicklungsentscheidungen herangezogen werden (vgl. Funke 1995, 170ff.). Im Sinne strenger Mess- und Testtheorie werden die Reliabilität wie die Validität von Szenarien jedoch eher verhalten eingeschätzt. Problemlöseszenarien sind im Vergleich zu anderen Verfahren der psychologischen Eignungsdiagnostik weniger valide oder zumindest seltener auf ihre Validität hin überprüft (vgl. Kersting 2001, Funke 1995, 177ff.; Hasselmann 1995, 253 und Wagener 2001, 259ff.).

Entwicklung

Neben diagnostischen Zwecken können Szenarios wegen der mit einer Durchführung i.d.R. einhergehenden Lernwirkung auch zur Entwicklung kognitiver Fähigkeiten eingesetzt werden. Dabei bietet sich eine Lernsituation, in der ohne Risiko und Kosten verschiedene Strategien des Umgangs mit komplexen Problemen ausprobiert werden können, was in realen Lernsituationen (»Learning-by-Doing«) so nicht gegeben ist. Über die Dynamik sowie die zeitlich und räumlich komprimierte Darstellung ergeben sich besondere Feedbackqualitäten. Es ist ein direkter Bezug von Entscheidung und Effekt vorhanden, wodurch zusätzlich die Selbstreflexion des Lernenden angeregt wird. Vielfältige Denk- und korrespondierende Steuerungsdefizite wie Ignoranz von Zeitverzögerungen, Umgang mit nicht-linearen Effekten, Vernetztheit etc. können so entdeckt und gemildert werden. Der Einsatz von Szenariosystemen zu Trainingszwecken weist fließende Übergänge zur Verwendung computergestützter Planspiele auf (vgl. etwa Obermann 1995). Beide Vorgehensweisen verfügen über Gemeinsamkeiten hinsichtlich Komplexität, Vernetztheit, Intransparenz und Polytelie der zugrunde liegenden Systemstruktur und 233

18

Szenariosysteme können entsprechend nicht trennscharf voneinander abgegrenzt werden. Planspiele setzen allerdings meist spezifische Kenntnisse voraus und finden oft im Gruppenverbund bzw. mit »Gegenspielern« statt (vgl. Funke 1995, Kersting 1999).

Verbreitung

234

Derzeit sind keine empirischen Studien zur Verbreitung von Szenariosystemen im Personalmanagement bekannt. Gleichwohl dokumentieren mehrere kommerziell angebotene Systeme, dass Szenarios ihren Weg von der Kognitionsforschung in die betriebliche Praxis gefunden haben (vgl. Sarges & Wottawa 2005).

19

Computer Based Training-Systeme Computer Based Training-Systeme (CBT-Systeme, Webbased Training [WBT]-Systeme, e-Learning-Systeme, »Courseware«, Lernsysteme u.a.m.) sind Anwendungen zur Vermittlung von deklarativen und prozeduralen Kenntnissen durch die Bereitstellung von Lerninhalten und die lernprozessbezogene Unterstützung von lernenden Anwendern (vgl. Back et al. 2001, 33ff.).

19.1

Architektur und Funktionalität von CBT-Systemen CBT-Systeme umfassen üblicherweise eine Datenbank mit Lernobjekten und eine sich darauf beziehende Metadatenbank, eine Komponente zur Steuerung des Lernprozesses, eine Präsentationskomponente sowie teilweise eine Kommunikationskomponente (vgl. Abb. 19.1). Computer Based Training-System Präsentationskomponente

Learning Content Management-System/ Autorensystem

Lernprozesssteuerung

Kommunikation

Lernobjekte

Metadaten

Learning ManagementSystem / Portalsystem

Abb. 19.1: Idealtypische Architektur von CBT-Systemen Eine Datenbank mit Lernobjekten dient der Speicherung sämtlicher notwendiger Lerninhalte. Eine Metadatenbank enthält Daten zu den Inhalten der Lernobjektsammlung. Die Präsentationskomponente enthält Funktionen zur auditiven und visuellen Darstellung der Lernobjekte und ermöglicht Interaktionen mit dem lernenden Anwender. Die Lernprozesssteuerungskomponente steuert den Ablauf des Lernprozesses. Eine fakultative Kommunikationskomponente ermöglicht Interaktionen zwischen lehrenden

235

19

Computer Based Training-Systeme und lernenden Anwendern als auch der lernenden Anwender untereinander.

Varianten

Nach dem Kriterium der Webbasierung können zwei zentrale Varianten von CBT-Systemen unterschieden werden (vgl. Heidack 2004, 639ff.). Nicht-webbasierte CBT-Systeme werden auf Datenträgern ausgeliefert und dezentral auf den Rechnern der jeweiligen Anwender installiert. Sie verfügen über eine integrierte Präsentationskomponente als Anwenderschnittstelle, weisen aber i.d.R. keine Kommunikationskomponente auf. Webbasierte CBTSysteme werden den Anwendern dagegen über Intra- oder Internet zur Verfügung gestellt. Sie werden zentral auf einem Anwendungsserver abgelegt. Als Präsentationskomponente finden dabei regelmäßig Browsersysteme Anwendung, die die entsprechenden Inhalte präsentierten (vgl. Kap. 28). Weit verbreitet wird das hier als Oberbegriff verstandene CBT auch lediglich für die nichtwebbasierten Systeme gebraucht, während für webbasierte Systeme entsprechend der WBT-Begriff Verwendung findet. Webbasierte CBT-Systeme weisen verschiedene Vorteile auf. Zunächst ist die Realisierung der Präsentationsschicht über Browsersysteme vorteilhaft. Browsersysteme sind weit verbreitet, gelten als einfach zu bedienen und erlauben den (nahezu) ubiquitären Zugriff auf die Lerninhalte. Ebenso können alle Arten von Korrekturen und Verbesserungen von CBT-System und Inhalten schnell und kostengünstig auf dem Anwendungsserver durchgeführt werden und stehen danach allen Anwendern unmittelbar zur Verfügung. Weiter erlaubt die Webbasierung von CBT-Systemen auch die Implementierung von Kommunikationskomponenten, die Interaktionen zwischen lehrenden und lernenden Anwendern sowie zwischen verschiedenen lernenden Anwendern erlauben. Solche Kommunikationsfunktionen bieten erhebliche Erweiterungen der Funktionalität in Richtung des kollaborativen Lernens. Webbasierte Systeme konstituieren eine zentrale technische Basis des so genannten »e-Learning« (vgl. Back et al. 2001) und bilden eine Vorstufe im Übergang zu umfassenderen Learning Management-Systemen (vgl. Kap. 20).

19.1.1

Lernobjektdatenbank Eine Datenhaltungskomponente dient grundsätzlich der Abspeicherung relevanter Lerninhalte. Anders als frühere monolithische Systeme, bemühen sich gegenwärtige Systeme dabei um eine modulare Strukturierung, die eine Wiederverwendbarkeit von Lerninhalten ermöglichen soll. Die Abspeicherung von Lerninhalten findet dabei grundsätzlich in Form von so genannten Lernob-

236

19.1 Architektur und Funktionalität von CBT-Systemen jekten (»Learning Objects«) statt. Lernobjekte sind kleinere, didaktisch sinnvolle Lerneinheiten, die sich aus einzelnen Informationsobjekten zusammensetzen. Art und Inhalt

Art und Inhalt der Informationsobjekte eines Lernobjekts hängen dabei vom erwünschten Lernziel ab. Im einfachsten Fall bestehen Informationsobjekte aus Lehrtexten, die gegebenenfalls durch weitere Informationsobjekte wie Grafiken, Audio- und Videosequenzen ergänzt werden können. Lernobjekte können aber auch aus interaktiven Simulationen und Übungsaufgaben bestehen, die entsprechende Eingaben vom Anwender erforderlich machen. Neben der reinen Präsentation von Lerninhalten können Lernobjekte auch Evaluationsmöglichkeiten enthalten, die eine Überprüfung des Lernerfolgs ermöglichen. Dies wird häufig durch Fragen mit Auswahlantworten (»Multiple Choice«) realisiert, aber auch grafische Zuordnungstests (»Drag & Drop-Test«), Lückentests, Bildertests, Wahr-Falsch-Tests und weitere Testtypen sind möglich (vgl. Schulmeister 2003, 62). Zwar bilden Lernobjekte i.d.R. kleinere Lerneinheiten ab, gleichwohl können Lernobjekte je nach erwünschter Lernstoffsegmentierung durchaus unterschiedliche Granularitäten aufweisen. Daher kann ein CBTSystem zahlreiche feingranulare Lernobjekte aufweisen, die jeweils in wenigen Minuten abgearbeitet werden können. Allerdings sind auch grobgranularere Lernobjekte möglich, die entsprechend mehr Lerninhalte transportieren und eine längere Bearbeitungszeit in Anspruch nehmen. Teilweise existieren auch Systeme, die für die selben Inhalte mehrere verschiedene Lernobjekte bereitstellen. Etwa kann derselbe Lerninhalt durch zwei Lernobjekte in unterschiedlicher Detaillierung aufbereitet werden, um unterschiedlichen Qualifizierungsbedarfen (Überblicksvs. Detailkenntnisse) gerecht zu werden. Ebenso können verschiedene Lernobjekte die selben Inhalte mittels verschiedener didaktischer Methoden aufbereiten, um einer heterogenen Anwendergruppe mit verschiedenen Lernstilen gerecht zu werden. Die Gesamtheit aller Lernobjekte eines CBT-Systems wird dabei meist als »Content« bezeichnet.

Aufbau

Um einen Kurs abzubilden, müssen mehrere Lernobjekte zu einer sinnvollen linearen oder verzweigten Sequenz zusammengeführt werden (vgl. Niegemann et al. 2003, 99ff.). Mehrere solcher Kurse können dann einen Lehrgang für ein breiteres Themenfeld konstituieren. Durch die Datenhaltung auf Lernobjektebene können entsprechende Kurse und Lehrgänge von der Lernprozesssteuerungskomponente zur Laufzeit modular zusammengestellt werden. Dabei kann ein Lernobjekt auch in mehreren Kursen 237

19

Computer Based Training-Systeme Verwendung finden. Abb. 19.2 deutet den damit angesprochenen modularen Aufbau in verschiedenen Ebenen von Lerninhalten an.

Lehrgangsebene

Kursebene

Lernobjektebene

Informationsobjektebene

Abb. 19.2: Modularer Aufbau von Lerninhaltsebenen (in Anlehnung an Maier-Häfele & Häfele 2003, 17) Inhalt und Anzahl abgelegter Lernobjekte determinieren damit die mit einem System realisierbaren Kurse. CBT-Systeme mit einer größeren Zahl von Kursen und entsprechend zahlreichen Lernobjekten werden teils auch als »Lernplattformen« bezeichnet. Herkunft

238

Konventionell bilden Lerninhalte einen integralen Bestandteil von CBT-Systemen und werden entsprechend zusammen mit dem System erworben. Allerdings existieren auch »leere« CBTSysteme. Die Lernobjektdatenbank besteht dann nicht aus konkreten, inhaltlich bestimmten Lernobjekten, sondern aus leeren Anwendungsschablonen (»Templates«) von Lernobjekten, die im Rahmen der Systemimplementierung erst zu befüllen und mit einer entsprechenden Navigationsstruktur zu versehen sind (vgl. Back et al. 2001, 211). Solche Systeme können mit Lernobjekten befüllt werden, die entweder extern erworben oder intern erstellt wurden. So existiert ein inzwischen umfangreicher Markt an einschlägigen Dienstleistern (»Content Provider«), die Lerninhalte für CBT-Systeme zur Verfügung stellen. Soweit solche Inhalte kompatibel mit bereits vorhandenen Systemen sind, können Lernob-

19.1 Architektur und Funktionalität von CBT-Systemen jektdatenbanken also auch mit zugekauften Inhalten gefüllt werden. Additiv besteht ebenso die Möglichkeit, bereits vorhandenen internen Content in das System zu importieren. Lernobjekte können dazu in umfangreichen Sammlungen in »Learning Content Management-Systemen (LMCS)« abgelegt sein, die entsprechende Lernobjekte bei Bedarf über Schnittstelle an das CBTSystem weiterreichen(vgl. Hettrich & Koroleva 2003). Ebenso können unter Rückgriff auf Autorensysteme individuelle Lernobjekte eigens erstellt und in das CBT-System importiert werden. Autorensysteme sind Entwicklungswerkzeuge zur Generierung von Lernobjekten und Lernprozessen (vgl. Kap. 20). Die ursprünglich enge Bindung von Lernobjekten an das korrespondierende CBT-System wird mit diesen Entwicklungen zunehmend aufgelöst. Lernobjekte können häufiger in verschiedenen Systemen gehalten und angewendet werden. Auch die Kombination selbst erstellter und zugekaufter Lernobjekte im Rahmen eines Kurses wird damit denkbar. Standardisierung

Um eigenen und fremden Content problemlos importieren und kombinieren zu können, ist eine vereinheitlichende Standardisierung der Lernobjektdatenhaltung besonders sinnvoll. Entsprechend existieren verschiedene Standardisierungsbemühungen (vgl. Hettrich & Koroleva 2003, 7f.). Derzeit bildet das »Sharable Content Object Reference Model (SCORM)« einen Standard mit gewisser Verbreitung (www.adlnet.org). Basierend auf früheren Standards spezifiziert SCORM, wie Lernobjekte auszugestalten sind, damit eine einfache Austauschbarkeit, Zugänglichkeit und Wiederverwendbarkeit der Lernobjekte gegeben ist. Dazu werden grundsätzlich die einzelnen austauschbaren und wieder verwendbaren Lernobjekte und deren Kombination und Aggregation zu Kursen dargestellt. Ebenso werden mögliche Variationen der Lernobjektsequenzen durch den Anwender beschrieben. Schließlich werden auch das Laufzeitverhalten und die notwendigen Schnittstellen eines CBT-Systems abgebildet. Das Einhalten solcher Standards sorgt dafür, dass verfügbare Lernobjekte in sämtlichen mit diesen Standards kompatiblen CBT-Systemen eingesetzt werden können. Allerdings existieren weitere Vorschläge unterschiedlicher Standardisierungskonsortien, so dass viele Unternehmen Entscheidungen über die Nutzung von Standards häufig in der Hoffnung auf spätere endgültige Einigung verschieben (vgl. Baumgartner 2007).

239

19

Computer Based Training-Systeme

19.1.2

Metadatenbank Um einzelne Lernobjekte in oft umfangreicheren internen oder externen Lernobjektdatenbanken suchen, finden und für die Anwendung zur Verfügung stellen zu können, müssen Lernobjekte mit Metadaten beschrieben werden.

Inhalte

Solche Metadaten beziehen sich zum einen auf technische Aspekte eines Lernobjekts wie etwa technische Anforderungen und Voraussetzungen der Nutzung des Lernobjekts. Zum anderen werden Lernobjekte auch inhaltlich beschrieben. Dies kann zunächst eine allgemeine Einordnung in ein Klassifizierungssystem umfassen, das generelle Auskunft über die Art des angebotenen Lerninhalts bietet. Weiter werden i.d.R. auch inhaltliche und didaktische Details des Lernobjekts beschrieben. Dabei können auch Beziehungen zu anderen Lernobjekten – etwa im Sinne aufeinander aufbauender Lerninhalte – aufgenommen werden. Weitere Metadaten können sich auf die Erstellungs- und Verwendungshistorie des Lernobjektes beziehen und Daten über Ersterstellung, Upgrades sowie Anwendungen und Anwender beinhalten. Teils können auch Anmerkungen und Kommentare von Erstellern und Anwendern des Lernobjekts in den Metadaten abgelegt werden. Schließlich können sich Metadaten auch auf die Nutzungsbedingungen und urheberrechtliche Aspekte der Anwendung beziehen.

Standardisierung

Zu einer system- und unternehmensübergreifenden Nutzung der Lernobjekte sollte auch deren Beschreibung mittels Metadaten standardisiert sein. Einen bekannten Standard bilden hier die »Learning Objects Metadata (LOM)«. Die Grundstruktur von LOM besteht aus neun Metadatenkategorien, die eine detaillierte und einheitliche Beschreibung von Lernobjekten zulassen (vgl. Hodgins et al. 2002). Solche Standardisierungen der Datenhaltung erlauben es, dass entsprechende selbst erstellte oder zugekaufte Lernobjekte einheitlich beschrieben werden können. Allerdings existieren auch diesbezüglich nach wie vor unterschiedliche Standards unterschiedlicher Konsortien (vgl. Baumgartner 2007).

19.1.3

Präsentationskomponente Als zentraler Anwenderschnittstelle kommt der Präsentationskomponente die Aufgabe zu, entsprechende Lernobjekte darzubieten und die Interaktion mit den Anwendern abzubilden. Insbesondere für die Wiedergabe von Lerninhalten sind Präsentationskomponenten multimedial ausgestaltet, d.h. sie können nicht nur Text- und Grafik-, sondern auch Audio- und Videoin-

240

19.1 Architektur und Funktionalität von CBT-Systemen halte wiedergeben. Solche multimedialen Präsentationen von Lerninhalten dienen dem Wechsel der Präsentationsart und unterstützen die Aufnahmefähigkeit der lernenden Anwender und damit den potenziellen Lernerfolg. Die Interaktivität der Präsentationskomponente ermöglicht dem Lernenden ein aktives Lernen, das im Rahmen adaptierbarer Systeme auch Einflussmöglichkeiten auf die Navigation und den Ablauf der Lerneinheiten zulässt. In Abhängigkeit von der Webbasierung des CBT-Systems finden sich wie bereits erwähnt zwei generelle Ausgestaltungsvarianten der Präsentationskomponente. Nicht-webbasierte Systeme verfügen i.d.R. über eine integrierte Präsentationsschnittstelle, die die erwähnten Funktionen der Präsentation und Interaktion übernimmt. Webbasierte Systeme nutzen dagegen regelmäßig Browsersysteme zur Realisierung der Präsentationsschicht (vgl. Kap. 28). Aufgrund der mittlerweile üblichen hohen Bandbreite bzw. Datenübertragungsrate ist es dabei problemlos möglich, auch datenintensive Lernobjekte mit größeren Audio- und Videodateien in anwenderfreundlicher Weise, d.h. schnell und mit hoher Auflösung zu übertragen.

19.1.4

Lernprozesssteuerungskomponente In Interaktion mit der Datenhaltungs- und Präsentationskomponente dient die Lernprozesssteuerung der strukturierten Ablaufsteuerung der von individuellen Anwendern zu absolvierenden Lernprozesse. Nach der Art der implementierten Ablaufsteuerung lassen sich dabei ƒ lineare Systeme, ƒ adaptive Systeme und ƒ adaptierbare Systeme unterscheiden (vgl. Bodendorf 1993, 64).

Lineare Systeme

Lineare Systeme weisen einen einfachen, nicht-adaptiven Ablauf der Kurse auf, der für alle lernenden Anwender gleich ist. Die Lernprozesssteuerung greift hierbei auf einzelne Lernobjekte aus der Datenhaltungskomponente zurück und gruppiert diese in ein lineares Ablaufschema. Diese werden den lernenden Anwendern dann in der zeitlich und logisch richtigen Reihenfolge via Präsentationskomponente präsentiert. Gegebenfalls können dabei einzelne oder alle Objekte auch mit einer Zeitbindung versehen werden. Etwa ist es möglich Maximal- und/oder Minimalbearbeitungsdauern für einzelne Lernobjekte vorzugeben. In diesem Fall überwacht die Lernprozesssteuerung die Einhaltung solcher Ober- und/oder Untergrenzen, indem sie etwa die Bearbeitung ei241

19

Computer Based Training-Systeme nes neuen Lernobjektes erst nach Erreichen der Minimalbearbeitungszeit zulässt oder nach dem Ablauf der Maximalarbeitszeit dem Anwender ein neues Lernobjekt vorgibt.

Adaptive Systeme

Da solche rigiden linearen Abläufe den teils sehr unterschiedlichen Lernverhalten, -geschwindigkeiten und -kapazitäten einzelner Anwender wenig gerecht werden, liegen zunehmend adaptive Systeme vor. Eine einfache Anreicherung eines linearen Ablaufs stellt dabei zunächst der Einbau einer einfachen »Wiederholschleife« dar. Dabei wird denjenigen Anwendern, die die Evaluation eines Lernobjektes nicht positiv absolvieren konnten, die Lerneinheit solang wiederholt zur Bearbeitung vorgelegt, bis die Inhalte adäquat erlernt wurden und eine positive Evaluation möglich ist. Weitergehenden Systeme orientieren sich am Konzept der »Programmierten Unterweisung« und bieten beispielsweise vertiefte und detailliertere Aufbereitungen desselben Lernstoffes für Anwender an, die den Lernstoff zunächst nicht ausreichend aufnehmen konnten (vgl. Schulmeister 2007, 87ff.). Abb. 19.3 deutet einen solchen verzweigten, adaptiven Ablauf eines Kurses an.

Start Kurs1

Evaluation1 negativ

Präsentation Lernobjekt1

Präsentation Lernobjekt2

Präsentation1 erfolgt

Präsentation2 erfolgt

Evaluation Lernobjekt1

Evaluation Lernobjekt2

XOR

Evaluation1 positiv

...

Vertiefung Lernobjekt1

Feedback Lerneinheit1

Vertiefung1 erfolgt

Kurs1 abgeschlossen

Abb. 19.3: Adaptiver Ablauf eines Kurses Solche zusätzlichen Aufbereitungen derselben Lernobjekte auf einer (teils auch mehreren) detaillierteren Ebene(n), ermöglicht es 242

19.1 Architektur und Funktionalität von CBT-Systemen Anwendern mit heterogenem Vorwissen, Auffassungsgaben und Lerngeschwindigkeiten gerecht zu werden. Entsprechend sieht die Lernprozesssteuerung je nach Evaluationsergebnissen für einzelne Anwender unterschiedliche, an sie adaptierte Abläufe vor. Eine weitergehende Adaptivität verheißen so genannte »Intelligente Tutorielle Systeme (ITS)« (vgl. Schulmeister 2007, 175ff.). Solche Systeme folgen in Konzeption und Architektur wissensbasierten Systemen (vgl. Heinecke 1992). Sie sollen eine adaptive Lernprozesssteuerung realisieren, die sich ähnlich einem menschlichen Tutor ausgeprägt an die vielfältigen Spezifika der jeweiligen lernenden Anwender anpasst. Wohl aufgrund der Komplexität und des Aufwands der Erstellung, haben sich solche Systeme derzeit nicht verbreitet durchsetzen können und werden daher hier nicht vertieft aufgegriffen. Adaptierbare Systeme

Neben solchen automatisierten und damit fremdbestimmten Varianten der Adaption des CBT-Systems an unterschiedliche Anwender, existieren mit den adaptierbaren Systemen additiv auch Varianten einer selbst bestimmten Adaption der Inhalte durch den individuellen Anwender. Adaptierbare Systeme erlauben es dem Anwender, im Sinne eines aktiven Lernens den Lernprozess selbst bestimmt zu gestalten. Entsprechend bieten adaptierbare Systeme dem Anwender die Möglichkeit, die Bearbeitungsdauer, die Wiederholung, die Wahl des adäquaten Detaillierungsgrads, die Vertiefung oder die Sequenzierung einzelner Lernobjekte selbstständig zu bestimmen. Die Lernprozesssteuerung adaptierbarer Systeme ist damit reaktiv orientiert, da sie auf Anfragen des Anwenders »wartet«, um diese dann zu bedienen. Bei umfangreicheren und insbesondere bei in komplexer Weise interdependenten Lerninhalten dürfte ein völlig selbst bestimmtes Lernen (beispielsweise die adäquate Sequenzierung verfügbarer Lernobjekte) dem mit den Inhalten zunächst ja gerade nicht vertrauten Anwender allerdings vielfach schwer fallen. Häufig finden sich daher Kombinationen aus adaptiver und adaptierbarer Ausgestaltung (vgl. Bodendorf 1993, 64). Solche Systeme geben entsprechend einen verzweigten adaptiven Grundablauf der Bearbeitung einzelner Lernobjekte vor, von dem der Anwender aber auf Wunsch etwa durch zusätzliche Wiederholungen oder Vorgreifen auf Lernobjekte abweichen kann, um so seinen individuellen Lernbedürfnissen gerecht zu werden.

19.1.5

Kommunikationskomponente Um die zahlreichen Interaktionsmöglichkeiten des Internets nutzen zu können, weisen speziell webbasierte CBT-Systeme Kom243

19

Computer Based Training-Systeme munikationskomponenten auf. Grundsätzlich werden dazu Techniken der »Computer Supported Cooperative Work (CSCW)« verwendet. In Anlehnung an diesen Bereich wird auch von »Computer Supported Cooperative Learning (CSCL)» gesprochen. Die Entscheidung, einen oder mehrere konkrete Kommunikationsdienste anzubieten, hängt zentral von Inhalten und Zielsetzung eines Systems ab. Grundsätzlich sollen so ermöglichte Interaktionen zwischen den Akteuren zur Steigerung und Sicherung des Lernerfolges beitragen und die Bildung virtueller Lerngemeinschaften unterstützen. Dass solche Kommunikationsmöglichkeiten insbesondere auch von Learning Management-Systemen angeboten werden, zeigt den letztlich fließenden Übergang zwischen beiden Kategorien (vgl. zu einer vertieften Darstellung der Kommunikationsmöglichkeiten daher Kap. 20).

19.2

Anwendung von CBT-Systemen Aus ökonomischer Perspektive dienen CBT-Systeme grundsätzlich einer effizienten und schnellen Vermittlung aller Arten von standardisierbarem, deklarativem und/oder prozeduralem Wissen im Rahmen der betrieblichen Personalentwicklung. Insbesondere bei der Notwendigkeit, eine größere Anzahl von räumlich verstreuten Anwendern in kürzerer Zeit in standardisierbaren Inhalten zu schulen, begünstigt die Anwendung von (webbasierten) CBT-Systemen, die dann trotz erheblichen Erstellungskosten von Lernobjekten bei marginalen Distributionskosten erhebliche Rationalisierungspotenziale aufweisen. Dabei lassen sich CBT-Systeme zunächst isoliert anwenden, um entsprechende Schulungsmaßnahmen durchzuführen. Bei einer solchen isolierten Anwendung wird das CBT-System einzelnen lernenden Anwendern zur Verfügung gestellt und durch Administratoren (und gegebenenfalls lehrende Anwender) administriert. Allerdings ist auch die Etablierung von Lernportalen auf der Basis von CBT-Systemen oder eine Integration in Learning Management-Systeme möglich. Eine Zusammenführung aller vorhandenen CBT-Systeme des Unternehmens in einem Lernportal (oder auch einem umfassenderen Mitarbeiterportal) ermöglicht einen einfachen, einheitlichen und personalisierten Zugang zu allen relevanten Lernressourcen (vgl. Back et al. 2001, 230ff. und Kap. 25). Gleichermaßen können über Portale auch nicht-webbasierte Systeme über Internet zur Verfügung gestellt werden. Eine mögliche Einbindung von CBT-Systemen in ein Learning Management-System ermöglicht es, zusätzlich zu didaktischen auch damit zusammenhängende dispositive und administrative Aufgaben der Weiterbildung wie

244

19.2 Anwendung von CBT-Systemen etwa die Verwaltung von Kursteilnehmern, Kursen oder Budgets integriert abzuarbeiten. Häufig enthalten Learning ManagementSysteme allerdings auch umfassende interne CBT-Funktionalitäten. Entsprechend liegt auch diesbezüglich eine Überschneidung beider Kategorien vor (vgl. Kap. 20). In didaktischer Perspektive werden mögliche Vorteile von CBTSystemen etwa in personalisierbaren Inhalten, in einem räumlich, zeitlich und inhaltlich selbstbestimmten Lernen »On Demand« gesehen. Allerdings verlangt CBT auch die Fähigkeit, alleine, d.h. getrennt von anderen lernenden und anleitenden Personen selbstmotiviert und selbstbestimmt zu lernen. Sollen Inhalte vermittelt werden, kann man CBT-Systeme als wesentliche oder einzige Methode vorsehen. Zunehmend wird die Anwendung von CBT-Systemen allerdings im Rahmen eines »Blended Learning« diskutiert, das verschiedene didaktische Methoden (speziell elektronische und konventionelle) kombiniert. Die Herausforderung dieser Anwendungsvariante besteht darin, computergestütztes und konventionelles Lernen so zu kombinieren, dass erwünschte Lernziele in möglichst ökonomischer Weise erreicht und so die jeweiligen methodischen Stärken genutzt werden (vgl. Sauter et al. 2004). CBT-Systemen bedürfen entsprechend (nicht nur beim Blended Learning) einer systematischen Integration in die unternehmensindividuellen Personalentwicklungsstrategien und -konzepte. Verbreitung

Eine empirische Studie zur Verbreitung des e-Learning zeigt auf, dass 30% der Unternehmen CBT-Systeme anwenden, wobei sich dieser Anteil bei Unternehmen mit mehr als 500 Mitarbeitern auf 60% verdoppelt (vgl. Küpper 2005, 91ff.). Dabei bleibt allerdings unklar, inwieweit im Sinne der hier verwendeten Kategorisierung CBT-Systeme oder zumindest anteilig auch umfassendere Learning Management-Systeme mit didaktischen Komponenten (vgl. Kap. 20) angewendet werden.

245

20

Learning Management-Systeme Learning Management-Systeme (LMS, Lernmanagementsysteme, Lernplattformen, Lernumgebungen, »[Virtual] Learning Environments [VLE]«, früher auch Seminarmanagementsysteme) sind Systeme zur umfassenden administrativen und didaktischen Unterstützung von Lernprozessen in Unternehmen.

Architektur und Funktionalität von Learning ManagementSystemen Idealtypisch bestehen umfassende Learning Management-Systeme aus einer Administrations- und einer Content-Datenbank soLearning Management-System

Kursorganisation Kursabrechnung Administration

Ressourcen

Personen

Kurse

Durch führungen

Lernobjekte

Lernprozessteuerung

Kursbuchung

Autorenkomponente

Kursangebot

Kommunikation

Anwenderschnittstelle

Analyse

20.1

Metadaten

»Content«-Datenbank

Administrationsdatenbank externe Anbieter

Autorensysteme (L)CMS Contentprovider

Abb. 20.1: Idealtypische Architektur von Learning ManagementSystemen (in Anlehnung an Schulmeister 2003, 11)

247

20

Learning Management-Systeme wie aus einer Administrations-, Analyse-, Kommunikations-, Autoren- und Lernprozesssteuerungskomponente (vgl. Abb. 20.1). Die Administrationsdatenbank enthält umfangreiche Daten zur Verwaltung des Weiterbildungsgeschehens. Die Content-Datenbank speichert Lernobjekte und Metadaten elektronischer Kurse. Die Administrationskomponente unterstützt das Anbieten, Buchen, Durchführen und Abrechnen von Kursen. Die Analysekomponente ermöglicht das Erstellen vielfältiger Abfragen und Berichte. Die Kommunikationskomponente ermöglicht Interaktion zwischen lernenden und lehrenden Anwendern. Eine Autorenkomponente erlaubt die individuelle Erstellung von Lernobjekten, während die Lernprozesssteuerung den Ablauf elektronischer Kurse steuert.

Varianten

Nach der Existenz von Komponenten zur Erstellung (Autorenkomponente) und Bereitstellung von Lerninhalten (ContentDatenbank, Lernprozesssteuerung und Kommunikationskomponente) können grob zwei unterschiedlich umfangreiche Varianten von Learning Management-Systemen unterschieden werden. Eine erste Variante beschränkt sich auf die Disposition und Administration des Lernens auf der Basis einer Administrationsdatenbank. Content wird in diesen Systemen nur in Form externer Inhalte, etwa durch die Anbindung von separaten CBT-Systemen (vgl. Kap. 19) zur Verfügung gestellt. Solche Systeme sind entsprechend webbasierte Weiterentwicklungen oder aber bloße Umbenennungen klassischer Seminarmanagementsysteme (vgl. Strohmeier 1995). Umfassendere Systeme weisen dagegen zusätzliche didaktische Komponenten, insbesondere eine Content-Datenbank und eine darauf bezogene Lernprozesssteuerung sowie Kommunikationskomponenten für das kollaborative Lernen auf. Solche umfassenderen Learning Management-Systeme sind damit letztlich Resultat einer anhaltenden Konvergenz der früher strikt getrennten CBT- und Seminarmanagementkategorie. Zur begrifflichen Unterscheidung beider Varianten wird – anders als hier – der Terminus Learning Management-System teils lediglich für die erste Variante vorgesehen, während die umfassendere zweite Variante als »integriertes Learning Management-System« bezeichnet wird (vgl. Clarey et al. 2007, 13ff.).

Mandanten

Learning Management-Systeme sind häufig mandantenfähig. Entsprechend können mehrere Unternehmen oder Unternehmensteile als Mandanten desselben Systems betrieben werden, wobei die einzelnen Mandanten völlig unabhängig voneinander sind (vgl. Hettrich & Koroleva 2003, 32f.).

248

20.1 Architektur und Funktionalität von Learning Management-Systemen

20.1.1

Administrationsdatenbank Die Administrationsdatenbank enthält Daten zu allen angebotenen und absolvierten Kursen, lehrenden und lernenden Personen sowie notwendigen Lernressourcen.

Kursdatei

Eine Kursdatei enthält zunächst Angaben zu allen konventionellen wie elektronischen Kursen eines Unternehmens. Kursdaten beziehen sich zunächst auf Art und Inhalt des Kurses. Neben der Einordnung in ein Klassifizierungssystem der angebotenen Lerninhalte werden bei konventionellen Kursen zunächst die Zielgruppen, Voraussetzungen, Lerninhalte, die Methodik sowie die mit dem Kurs erwerbbaren Qualifikationen näher beschrieben. Neben Inhalten werden auch administrativ wichtige Daten wie Veranstaltungstermine, Veranstaltungsdauer, Veranstaltungsorte sowie ggf. Minimal- und Maximalteilnehmerzahlen aufgenommen. Unter Bezug auf die Personen- und Ressourcendatei werden auch die Dozenten und notwendige Lernressourcen eines Kurses aufgenommen. Für Zwecke der internen Verrechung oder externen Fakturierung eines Kurses können oft auch Kostendaten und Teilnahmegebühren abgelegt werden. Handelt es sich um einen Kurs eines externen Dienstleisters, werden auch dessen Kontaktdaten aufgenommen. Auch elektronische Kurse werden zunächst inhaltlich konkretisiert, allerdings entfällt ein Teil der administrativen Daten, da Veranstaltungsorte nicht notwendig sind und Dozenten und Termine nur im Falle synchroner Teleseminare existieren. Daten zum Kursangebot dienen dabei der Erstellung eines konventionellen und/oder elektronischen Kurskataloges, der als Informationsbasis möglicher Interessenten dient. Insbesondere wenn in größerem Maße auf die Angebote unterschiedlicher externer Hersteller zurückgegriffen werden soll, ist ein direkter Import deren Kursdaten sinnvoll, um ein erneutes manuelles Einpflegen zu vermeiden. Entsprechend existieren teils Schnittstellen zum Import von Kursdaten. Allerdings ist eine einfache automatisierte Übernahme von Daten wegen mangelnder Standardisierung von Kursdatenbeschreibungen nicht immer möglich (vgl. Hettrich & Koroleva 2003, 60f.).

Personendatei

Eine Personendatei enthält Daten zu unterschiedlichen, am Lernprozess beteiligten Personengruppen. Dies bezieht sich zunächst auf interne und externe Dozenten, die für die Durchführung elektronischer oder konventioneller Kurse vorgesehen sind. Neben dem Namen, den Kontaktdaten und den Finanzdaten der Referenten zählen hierzu auch Informationen über deren fachlichen Einsatzbereiche und über die pädagogischen Fähigkeiten. 249

20

Learning Management-Systeme Auch die zeitlichen Einsatzdaten der Dozenten können hier abgelegt werden. Werden systematische Dozentenbewertungen durchgeführt, kann die Datei auch Evaluationsdaten und Bewertungsergebnisse einzelner Dozenten enthalten. Werden für elektronische Kurse Tutoren vorgesehen, können diese analog aufgenommen werden. Teils können auch Autoren, die Lerninhalte für das System erstellen, aber nicht unmittelbar als Dozenten oder Tutoren auftreten, in der Datei verwaltet werden. Eine zentrale Personengruppe bilden schließlich die internen und externen Kursteilnehmer bzw. Kursinteressenten, die ebenfalls abgelegt werden. Neben den Personalstammdaten wie Name und Kontaktdaten, die bei internen Personen teils aus anderen Personalsystemen importiert werden können, sind dies zunächst Daten zur Qualifikation und Qualifizierungshistorie ebenso wie möglicher Qualifizierungsziele und Interessensgebiete von Interessenten. Weiter werden teils auch Abrechnungsdaten wie z.B. Kostenstellen oder Bankverbindungen gespeichert, um entsprechende Daten für eine mögliche interne Verrechnung oder externe Fakturierung einer Entwicklungsdienstleistung bereitstellen zu können. Ebenso können in manchen Systemen internen Teilnehmern Entwicklungsbudgets zugeordnet werden, die im Sinne einer finanziellen Obergrenze die Zahl der innerhalb eines gewissen Zeitraums absolvierbaren Kurse abbilden. Teils werden auch Zugriffsrechte und Anwenderrollen einzelner Personen, die die Zugriffsmöglichkeiten auf ein System festlegen, abgelegt. Dabei kann eine Person auch mehrere Rollen übernehmen. Ein Dozent eines Kurses kann z.B. gleichzeitig auch Teilnehmer eines anderen Kurses sein.

Ressourcendatei

Die Ressourcendatei bezieht sich auf konventionelle Kurse und enthält eine Auflistung der zu deren Durchführung notwendigen materiellen Ressourcen. Dies bezieht sich zunächst etwa auf interne oder externe Räume und deren Ausstattung hinsichtlich Größe und Bestuhlung sowie zur Verfügung stehende Präsentationsmedien. Ebenso können weitere notwendige Lernmaterialien wie Bücher, Kursunterlagen aber auch Rechner, spezielles Werkzeug und weiteres technisches Equipment abgelegt werden. Im weiteren Sinne zählen auch Übernachtungsmöglichkeiten für nicht ortsansässige Teilnehmer zu den benötigten »Ressourcen« eines Kurses und können daher teilweise mit diversen Attributen wie Kosten, Kapazitäten etc. ebenfalls abgespeichert werden.

Durchführungsdatei

Eine weitere Datei speichert Daten zu den (teil-)absolvierten Kursen. Im Falle konventioneller Präsenzkurse werden etwa die Teilnahme von Personen, die dafür entstandenen Kosten und die

250

20.1 Architektur und Funktionalität von Learning Management-Systemen damit erzielten Qualifizierungsergebnisse einschließlich Tests und Abschlussnoten festgehalten. Ebenso werden durchführende Dozenten und eingesetzte Ressourcen erfasst. Werden Seminarbeurteilungen durch die Teilnehmer durchgeführt, werden auch diese in einer Durchführungsdatei dem entsprechenden Kurs zugeordnet. Weitergehende Daten können für elektronische Kurse erfasst werden. So kann jeder Zugriff auf einen Kurs durch einen Anwender mitprotokolliert und in der Durchführungsdatei abgelegt werden. Dies kann etwa die Häufigkeit und Dauer der Aufrufe eines elektronischen Kurses, das generelle Navigationsverhalten, die Ergebnisse von Testaufgaben u.a.m. enthalten. Der Grund für die automatisierte Erfassung solcher Daten liegt in der Möglichkeit, einem Tutor über die Analysekomponente Einblicke in das Lernverhalten einzelner Anwender und Hinweise für eventuell notwendige Hilfestellungen und Interventionen zu geben. Teils wird aber auf ein solches automatisiertes »Monitoring« aus Gründen des Datenschutzes wie der Didaktik aber auch verzichtet. Grundsätzlich bildet die Durchführungsdatei damit die Datenbasis für ein umfassendes Bildungscontrolling und teilweise auch für unmittelbar steuernde Eingriffe in individuelle Lernprozesse. Oft können hier sukzessive abgespeicherte Daten, wie etwa die Weiterbildungshistorie einzelner Mitarbeiter, auch in andere datenhaltende Systeme exportiert werden.

20.1.2

Content-Datenbank Die Content-Datenbank speichert alle vom System zur Verfügung gestellten Lerninhalte. Wie bei CBT-Systemen findet eine Datenhaltung dabei in Form modularer und wieder verwendbarer Lernobjekte statt, die zu Kursen und Lehrgängen zusammengefasst werden können. Auch hier werden Lernobjekte mittels Metadaten näher beschrieben. Ebenso gelten die angesprochenen Standardisierungsbemühungen (vgl. dazu die Ausführungen in Kap. 19). Ein erster Unterschied zur Datenhaltung eines CBT-Systems liegt im Umfang der enthaltenen Lernobjekte und der daraus generierbaren Kurse. Während konventionelle CBT-Systeme sich i.d.R. auf spezifische Lerngebiete und -inhalte beschränken, zielt die Content-Datenbank i.d.R. auf die umfassende Abbildung aller im Unternehmen angebotenen Lerninhalte und fällt daher entsprechend oft erheblich umfangreicher aus. Als weiterer Unterschied können in der Content-Datenbank eines Learning Management-Systems auch Inhalte für Präsenzveranstaltungen, wie etwa konventionelle Lehrtexte, gehalten werden. Dabei wird die Content-Datenbank häufig über ein integriertes oder aber extern 251

20

Learning Management-Systeme angebundenes Content Management-System realisiert (vgl. Schulmeister 2003, 15f.). Content Management-Systeme weisen zunächst den Vorteil auf, spezifisch auf die Ablage von multimedialen Dateien und damit auf Lernobjekte ausgerichtet zu sein. I.d.R. werden dabei Inhalte und Formatvorlagen (»Templates«) getrennt abgelegt, was eine Anzeige identischer Inhalte in unterschiedlichen Formatierungen ermöglicht. Entsprechend wird etwa eine Lernwebseite aus Formatvorlagen und Inhalten dynamisch generiert, sobald sie von der Lernprozesssteuerung angefordert wird. Content Management-Systeme ermöglichen weiter auch den Bereitstellungsprozess umfassend zu administrieren. So können Lerninhalte von Autoren eingestellt und anschließend von Redakteuren gesichtet, redigiert und freigegeben werden. Ebenso existieren Suchmöglichkeiten, die ein Auffinden von Content nach Stichwort oder Kategorie zulässt (vgl. Maier-Häfele & Häfele 2003, 10ff.). Durch die Auslagerung der Lerninhalte in externe Content Management-Systeme werden auch oft die beiden Kategorien Learning Management-Systeme (LMS) vs. Learning Content Management-Systeme (LCMS) unterschieden (vgl. etwa Hettrich & Koroleva 2003). Aufgrund ebenfalls vorhandener interner Content Management-Lösungen sind die Übergänge allerdings fließend und eine Unterscheidung ist nicht überschneidungsfrei möglich. Wie bereits erwähnt, weisen einige Learning Management-Systeme allerdings gar keine eigene Content-Datenbank auf, sondern beschränken sich darauf, Zugänge zu externem Content zu liefern (vgl. Schulmeister 2003, 11).

20.1.3

Administrationskomponente Eine Administrationskomponente verwaltet die gesamten administrativen Prozesse und verbindet die unterschiedlichen beteiligten Anwenderkategorien mittels Workflows. Zentrale Funktionalitäten beziehen sich dabei auf ƒ das Kursangebot, ƒ die Kursbuchung, ƒ die Kursdurchführung und ƒ die Kursabrechnung.

Kursangebot

252

Zunächst sind in einer Administrationskomponente üblicherweise Funktionalitäten zum Angebot einzelner Kurse enthalten. So beziehen sich Katalogerstellungsfunktionen auf die Zusammenstellung und Konkretisierung aller angebotenen, d.h. internen und externen, konventionellen und elektronischen Kurse. Neben einer Bestimmung der grundsätzlich anzubietenden Kurstypen umfasst dies für Präsenzkurse und für elektronische Kurse mit Prä-

20.1 Architektur und Funktionalität von Learning Management-Systemen senzanteilen (»Teletutoring« oder »Teleseminare«) eine zusätzliche Konkretisierung der Häufigkeit und Zeitpunkte des Angebots. Hierzu ist zunächst eine Bedarfsschätzung für einzelne Kurse notwendig, die etwa unter Rückgriff auf Durchführungsdaten vergangener Kurse, aber auch unter Berücksichtigung von Voranmeldungen und Wartelisten bislang nicht berücksichtigter Teilnehmer durchgeführt werden kann. Dabei sind auch mögliche Vorgaben durch ein Personalentwicklungsbudget und die jeweilige Verfügbarkeit von Dozenten bzw. Tutoren sowie gegebenenfalls weiterer notwendiger Ressourcen wie Kursräume zu berücksichtigen. Im einfachsten Fall wird dieses Angebotsmanagement »manuell« durchgeführt, wobei das System Fehler wie Doppelbelegungen von Ressourcen oder das Angebot von Kursen ohne verfügbare Dozenten aufdeckt. Da solche Dispositionsprobleme bereits bei einer mittleren Anzahl von Kursen, Dozenten und Ressourcen eine hohe Komplexität erreichen können, existieren teils auch Möglichkeiten eines automatisierten Angebotsmanagements, das auf der Basis von Approximationsalgorithmen die Zuordnung von Kursen, Zeiten, Dozenten und Ressourcen übernimmt. Für dozenten- und tutorenfreie elektronische Kurse sind solche Konkretisierungen dagegen nicht nötig, da die entsprechenden Kurse auch größeren Teilnehmerzahlen direkt auf Abruf simultan zur Verfügung gestellt werden können. Sind diese Vorarbeiten erfüllt, kann zunächst eine elektronische Version des Kurskataloges zur Verfügung gestellt werden. Interessierte Anwender können dann im Katalog browsen und mit unterschiedlichen Suchfunktionen wie Kategoriensuche oder Freitextsuche gezielt nach einschlägigen Kursangeboten suchen (vgl. Milius 2002, 168). Teils wird zusätzlich zur elektronischen Version auch die Erstellung einer Printversion unterstützt, die dann postalisch an interne und externe Interessentengruppen versandt werden kann. Auf der Basis eines Gesamtkatalogs, der das Gesamtangebot an Kursen umfasst, können oft auch zielgruppenspezifische Kataloge für spezielle Qualifikations- und Interessentengruppen erstellt werden. Teils kann das Angebot auch vollständig individualisiert bzw. personalisiert werden. Auf Basis festgelegter Qualifizierungsbedarfe und/oder vom Anwender selbst eingepflegter Interessensgebiete können entsprechend auch individuell zugeschnittene Kataloge für einzelne Interessenten erstellt und möglichen Teilnehmern proaktiv vorgeschlagen werden. Solche personalisierte Kurskataloge bilden bereits den Übergang zu einem aktiven Angebotsmanagement, das gerade

253

20

Learning Management-Systeme auch für die Gewinnung externer zahlender Teilnehmer relevant ist.

Kursbuchung

Weitere zentrale administrative Funktionen beziehen sich auf die Buchung der Kurse, die Teilnehmer mit einem konkreten Kurs verknüpft. Buchungen können über verschiedene Kanäle erfolgen. In aller Regel verfügen Learning Management-Systeme über Self Service-Buchungsmöglichkeiten. Interne und externe Interessenten können sich damit nach der Durchsicht des Kataloges direkt auf einen Kurs buchen. Häufig ist aber zusätzlich auch eine Buchung durch einen Anwender der Fachabteilung »Personal« möglich, der insbesondere interne Teilnehmer auf erwünschte Kurse bucht – ggf. auch nachdem der Anwender telefonisch, postalisch oder e-mail-basiert um eine Teilnahme gebeten hat. Das System prüft dann zunächst die Berechtigung sowie eventuell das Vorliegen bestimmter Voraussetzungen an Vorkenntnissen und das Budget der buchenden internen Person bzw. prüft das Vorliegen einer Zahlung(sanweisung) durch einen externen Interessenten. Im Falle rein elektronischer Kurse werden diese dann – mit oder ohne zeitliche Begrenzung – frei geschaltet. Im Falle konventioneller Kurse prüft das System weiter die Verfügbarkeit des Kurses und bucht den Interessenten im Falle der Verfügbarkeit eines freien Kursplatzes direkt auf den Kurs. Andernfalls sind oft Buchungen auf Wartelisten üblich, deren Angehörige bei späteren Wiederholungskursen bevorzugt berücksichtigt werden. Teilweise sind über festlegbare »Trigger«-Ereignisse auch automatische Buchungen möglich, etwa wenn ein Mitarbeiter auf einer Warteliste steht und ein neuer geeigneter Kurs angelegt wird. Auch Umbuchungen auf Parallelkurse o.ä. sind möglich. Im Anschluss an eine erfolgte Buchung ist die Ausgabe von Buchungsbestätigungen und entsprechender Kursunterlagen wie Anreiseskizzen per e-Mail möglich. Auch Stornierungen konventioneller Kurse etwa bei Nichterreichung der Minimalteilnehmerzahl oder Erkrankung eines Dozenten sind durchführbar. Ebenso werden teilnehmerseitige Stornierungen mit etwaigen Stornierungsgebühren u.a. unterstützt. Auch diesbezüglich können notwendige Kommunikationsvorgänge per e-Mail oder konventionelle Briefe unterstützt werden.

Kursdurchführung

Die Kursdurchführung bezieht sich auf zahlreiche Aufgaben, die der unmittelbaren Vorbereitung und Durchführung insbesondere von konventionellen Präsenzkursen dienen. Zunächst können entsprechende Anfragen und Nachrichten an benötigte Dozenten und deren Einplanung in verschiedenen Kursen vorgenommen werden. Auch die Erstellung und Verwaltung von Verträgen (zu

254

20.1 Architektur und Funktionalität von Learning Management-Systemen Inhalt, Vergütung, Zeitaufwand, sonstige Vereinbarungen) mit Dozenten wird oft unterstützt. Analog werden häufig umfangreiche Möglichkeiten der Organisation notwendiger Ressourcen vorgenommen. Dies bezieht sich zunächst auf die Buchung notwendiger interner und externer Räumlichkeiten. Darin beinhaltet ist auch deren Ausstattung mit erforderlichen Präsentationsmedien, Bestuhlung u.a.m. Ebenso können benötigte Kursunterlagen zusammengestellt werden. Werden diese in der Content-Datenbank gehalten, kann eine systemseitige Zusammenstellung und Ausdruck zum jeweiligen Kurstermin erfolgen. Analoges gilt für die Erstellung von Teilnehmerlisten, Namensschildern, Platz- und Raumbeschriftungen etc. Zu den Ressourcen im weiteren Sinne zählt auch die Verpflegung während des Kurses, die ggf. in Abstimmung mit Cateringunternehmen geplant und administriert werden kann. Im weiteren Sinne zählen auch die Übernachtungsmöglichkeiten für nicht ortansässige Teilnehmer zu den benötigten Ressourcen. Entsprechend kann ein Teil der Systeme auch die Buchung entsprechender Hotels etc. unterstützen. Werden von den Teilnehmern Evaluationen von Kurs und/oder Dozent erwartet, können auch diese entweder durch Ausdruck eines Evaluationsbogens oder durch Bereitstellung eines entsprechenden Onlineformulars unterstützt werden. Ebenso kann auch die Durchführung und Auswertung schriftlicher Tests der Teilnehmer administriert werden. Im Anschluss können Teilnehmerzertifikate ausgegeben und versandt sowie entsprechende Qualifikationsdaten generiert in der Personendatei abgelegt oder zur Ausgabe an externe Anwendungssysteme bereitgestellt werden. Kursabrechnung

Zur Abrundung der Funktionalitäten werden von Teilen der Systeme Kursabrechnungsfunktionalitäten in unterschiedlichem Umfang angeboten. Die Abrechnung bezieht sich zunächst auf die Rechnungsstellung von Kursen für Teilnehmer. Dies ermöglicht zunächst nicht voll ausgebuchte interne Kurse mit zahlenden externen Teilnehmern aufzufüllen. Ebenso wird der Einsatz des Learning Management-Systems im Rahmen kommerzieller Weiterbildungsunternehmen möglich. Dabei werden teils umfassende Fakturierungsfunktionalitäten geboten. So ist zunächst die Erstellung der Rechnung mit meist frei bestimmbaren Positionen wie etwa Kursteilnahme, Kursunterlagen, Übernachtungsgebühren etc. möglich. Daneben kann der Zahlungseingang überwacht und mit einem Mahnwesen verbunden werden. Ebenso sind Stornierungen und Teilgutschriften von Rechnungsbeträgen durchführbar. Neben einer faktischen Rechnungsstellung werden teils auch interne Verbuchungen der Kurse unterstützt, die die 255

20

Learning Management-Systeme Kostenstellen der Kursteilnehmer mit entsprechenden Beträgen belasten. Teils kann für unterschiedliche Teilnehmergruppen festgelegt werden, wie eine Kursteilnahme konkret abzurechnen ist. Manche Systeme können auch weitere Abrechnungsvorgänge wie die Abrechnung von Dozentenhonoraren, Raummieten, Reisekosten sowie Kosten für externen Content und WBT-Kurse u.a.m. abrechnen. Entsprechend werden teils umfassende Abrechnungsfunktionalitäten geboten, deren Datenbestand die Basis für ein Kostencontrolling der Personalentwicklung bildet. Zur Verbuchung existieren teilweise Schnittstellen zu Buchhaltungssystemen. Teilweise werden Abrechnungsfunktionen (und die Verbuchung der Kosten) aber auch direkt über Anbindung externer Systeme – wie etwa ERP-Systeme (vgl. Kap. 23) – realisiert (vgl. Schulmeister 2003, 10).

Häufig wird die Administrationskomponente durch hinterlegte Workflow- und Zusatzfunktionen Workflows unterstützt. Beispielsweise kann im Rahmen eines Self Service-Konzeptes ein Genehmigungsverfahren abgebildet werden, bei dem der direkte Vorgesetzte des buchenden Mitarbeiters einer Kursbuchung ebenfalls per Self Service zustimmen muss, bevor der Mitarbeiter einen Kurs tatsächlich buchen und besuchen kann. Analog sind vorgefertigte Workflows für oft zahlreiche weitere Prozesse der Angebotserstellung, Buchung, Durchführung und Abrechnung von Kursen implementiert. Diese können unmodifiziert übernommen werden oder im Rahmen eines Customizing modifiziert, teilweise auch vollständig neu generiert werden. Kurs- und Workflow-Funktionen können um allgemeine administrative Zusatzfunktionen wie Kalender, Erinnerungs- und Wiedervorlage-Funktionen ergänzt werden.

20.1.4

Lernprozesssteuerungskomponente Analog zu CBT-Systemen weisen umfangreiche Learning Management-Systeme eine Komponente zur Lernprozesssteuerung auf, die in Interaktion mit der Content-Datenbank und der Anwenderschnittstelle der strukturierten Ablaufsteuerung individueller Lernprozesse dient (vgl. dazu Kap. 19).

20.1.5

Autorenkomponente Nur vereinzelt enthalten Learning Management-Systeme auch Komponenten zur unternehmensindividuellen Erstellung von Lerninhalten. Grundsätzlich können Lerninhalte dabei über ƒ umfassende Autorensysteme, ƒ erweiterte HTML-Editoren und

256

20.1 Architektur und Funktionalität von Learning Management-Systemen ƒ vorgefertigte CBT-Templates erstellt werden (vgl. Maier-Häfele & Häfele 2003, 7ff.). Umfassende Autorensysteme weisen als professionelle Entwicklungssysteme meist eine eigene Programmiersprache auf, die komplexe Ausgestaltungen von Informationsobjekten, Lernobjekten und Kursen zulässt. Allerdings stehen dem hoher Einarbeitungsaufwand und große Bedienungskomplexität gegenüber, weswegen solche umfassenden Möglichkeiten i.d.R. nur von externen Autorensystemen mit entsprechenden Schnittstellen zum Learning Management-System angeboten werden. Eher vorfindbar ist die Lösung eines (erweiterten) HTML-Editors, der angeboten wird, um Websites mit Lerninhalten erstellen zu können. Ebenso finden sich vorgefertigte CBT-Templates (»Rapid Content DevelopmentSystem«), die im Sinne »leerer« Anwendungsschablonen ein einfaches und rasches Befüllen leerer Lernobjekte mit entsprechendem Inhalt und die Erstellung einer korrespondierenden Navigationsstruktur zulassen (vgl. auch Kap. 19). Werden solche Autorenkomponenten angeboten, werden diese häufig auch als »Plug In« realisiert, das von Fremdanbietern zugekauft wird. Die Autorenkomponenten haben dann den Charakter eines Zusatzprogramms, das im Rahmen des Learning Management-Systems aktiviert und deaktiviert werden kann und dessen Funktionalität erweitert (vgl. Baumgartner et al. 2002, 34).

20.1.6

Kommunikationskomponente Zur Ermöglichung eines interaktiven und kollaborativen Lernens und der Bildung von virtuellen Lerngemeinschaften verfügen viele Learning Management-Systeme über kommunikative Komponenten. Grundsätzlich werden hierzu Techniken der »Computer Supported Cooperative Work (CSCW)« verwendet. In Anlehnung an diesen Bereich wird auch von »Computer Supported Cooperative Learning (CSCL)» gesprochen. Nach den einbeziehbaren Interaktionspartnern können Interaktionskomponenten lehrende und lernenden und/oder verschiedene lernende Anwender miteinander verbinden. Wie bei CSCW können dabei synchrone und asynchrone Varianten der Kommunikation unterschieden werden (vgl. Niegemann et al. 2003, 120ff.). Die diversen Kommunikationsdienste können dabei intern vom Learning Management-System angeboten werden. Häufig werden gerade Kommunikationsdienste aber auch als externe Dienste im Sinne eines »Plug In« realisiert. Die Kommunikationsdienste haben dann den Charakter von Hilfsprogrammen, die die Funktionalität des Systems erweitern. Oft wird die Funktionalität dabei direkt in die Browser257

20

Learning Management-Systeme oberfläche integriert. Häufig angebotene Kommunikationstechniken stellen dabei ƒ e-Mail, ƒ Mehrbenutzereditoren, ƒ Videokonferenzen, ƒ Diskussionsforen und ƒ Chats dar, wobei die integrative Zusammenfassung dieser Techniken oft auch als virtuelles Klassenzimmer (»Virtual Classroom«) bezeichnet wird. Als einfache asynchrone Kommunikationsmöglichkeit werden häufig e-Mail-Funktionen angeboten. Damit können Textnachrichten zwischen verschiedenen Anwendern und über Anhänge auch beliebige Dokumente ausgetauscht werden. In der Interaktion zwischen lehrenden und lernenden Akteuren ermöglicht dies eine einfache, asynchrone Form des Teletutoring, bei dem der lehrende Anwender den lernenden Anwender fachlich, technisch und organisatorisch in seinem Lernprozess unterstützt. Ebenso ermöglichen e-Mail-Funktionen den Austausch zwischen verschiedenen lernenden Anwendern im Sinne eines kooperativen Lernens. Bei Lerninhalten, die im Sinne eines aktiven aufgaben- oder projektorientierten Lernens zu bearbeiten sind, bieten verschiedene Varianten von Mehrbenutzereditoren die Möglichkeit einer synchronen oder asynchronen gemeinsamen Bearbeitung von Dateien (Texte, Grafiken u.a.) durch verschiedene lernende Anwender. Räumlich getrennte Anwender können LernProjekte so gemeinsam und interaktiv bearbeiten. Videokonferenzen ermöglichen die synchrone Übertragung von audio-visuellen Daten sowie optional weiterer Dateien als Anhänge. Die im Kontext von CBT-Systemen vereinzelt vorhandenen Implementierungen ermöglichen zunächst die Abhaltung von Teleseminaren, bei dem die Lehrveranstaltungen eines lehrenden Anwenders in Echtzeit verschiedenen lernenden Anwendern bereitgestellt werden. Damit können gewisse Vorteile von Präsenzseminaren genutzt werden, ohne Nachteile wie Reisekosten und Zeitaufwand in Kauf nehmen zu müssen. Ebenso eignet sich diese Kommunikationstechnik für ein synchrones Teletutoring. Diskussionsforen (»Bulletin Boards«) sind virtuelle Räume zum Austausch von Informationen zwischen den lernenden Anwendern. Die Kommunikation findet dabei asynchron statt. Ein Anwender hinterlässt einen Diskussionsbeitrag (»Posting«) im Forum, wo ihn andere Anwender lesen und darauf antworten können. Mehrere Beiträge zum selben Thema werden dann jeweils zu einem Thema (»To-

258

20.1 Architektur und Funktionalität von Learning Management-Systemen pic«) zusammengefasst. Auf diese Weise können lernende Anwender Kontakte knüpfen, Ansprechpartner für Probleme finden sowie Antworten auf offene Fragen erhalten. Dabei können Foren auch von Moderatoren begleitet und geleitet werden. Teilweise angebotene Chats ermöglichen einen synchronen Austausch von Textnachrichten. Die einzelnen Chats werden dabei thematisch nach Chaträumen (»Chatrooms«) geordnet. Chaträume können dabei von den Anwendern individuell generiert, betreten und verlassen werden. Allerdings wird der spezifische Wert von Chats für Lernzwecke trotz allgemeiner Beliebtheit als eher gering eingeschätzt, insbesondere wenn größere Anwendergruppen miteinander kommunizieren sollen (vgl. Niegemann et al. 2003, 121).

20.1.7

Analysekomponente Eine Analysekomponente dient hauptsächlich der Auswertung von Daten der Datenbank-Komponenten. So kann zunächst die Content-Datenbank auf spezifische Lernobjekte hin durchsucht werden. Deutlich häufiger dürfte allerdings auf Daten der Administrations-Datenbank zugegriffen werden.

Controlling

Zunächst kann die Analysekomponente für alle Arten von Kursen Informationen für ein umfassendes Entwicklungscontrolling bereit stellen. Hierzu verfügen die Systeme über eine oft umfangreiche Sammlung an vorgefertigten Abfragen bzw. Berichten zu zahlreichen Fragestellungen. Beispielsweise bieten Buchungsund Teilnahmestatistiken Aufschluss über die Nachfrage nach und die tatsächliche Auslastung von einzelnen Kursen und Kursgruppen. Auswertungen der Kursbewertungen zeigen ein Meinungsbild zur Qualität von Kursen (und teils auch Dozenten und Tutoren). Auf der Basis von Abrechnungsdaten vielfältig mögliche Kostenauswertungen, etwa nach Kurs, Themengebiet, Teilnehmer oder Organisationseinheit, eingesetzter Ressource etc. bilden eine Grundlage für ein umfassendes Kostencontrolling. Analog können auch Einnahmen von externen Teilnehmern ausgewertet werden und durch Abgleich mit den Kosten Deckungsbeiträge einzelner Kurse berechnet werden. Neben mitgelieferten Analysen verfügen die Systeme meist auch über individuell spezifizierbare Ad-hoc-Abfragemöglichkeiten über alle verfügbaren Datenfelder. Dabei kann auch die Disposition von künftig notwendigen Kursen, etwa über die Analyse der Bildungshistorie einzelner Mitarbeiter, dem Abgleich mit der Entwicklungs- und der Einsatzplanung der Mitarbeiter, der Analyse der Verfügbarkeit von Räumlichkeiten und Dozenten etc. unterstützt werden. 259

20

Learning Management-Systeme Teils werden gewisse Abfragemöglichkeiten per Self Service auch den Teilnehmern direkt zugänglich gemacht, die dann etwa nach Kursen suchen oder ihre eigene Bildungshistorie und den aktuellen Stand ihres Entwicklungsbudgets abfragen können.

Tracking

Ausschließlich auf elektronische Kurse beschränkt, eröffnet das so genannten »Tracking« (teils auch »Monitoring«) fakultativ detailliertere Aufschlüsse zu individueller Nachfrage und Lernverhalten. Dieses automatische Protokollieren von Lernaktivitäten und Evaluationsergebnissen lernender Anwender soll grundsätzlich Aufschlüsse über den Lernstil und speziell über notwendige Ergänzungen und Aktivitäten eines menschlichen Tutors geben. So soll etwa die Notwendigkeit einer ergänzenden Hilfestellung erkannt werden können, wenn ein lernender Anwender zu lange für die Bearbeitung eines Lernobjektes benötigt und/oder anhaltend unrichtige Testergebnisse aufweist. Ebenso sollen individuelle Tracking-Daten zu aggregierten Aussagen führen, die eine ökonomische und didaktische Bewertung des angebotenen Kurses zulassen sollen. Hier erhofft man sich Hinweise auf Verbesserungs- und Vertiefungsbedarf etwa solcher Lernobjekte, die einer größeren Anzahl von Anwendern systematisch Probleme bereiten. Allerdings wird ein detailliertes Tracking aus Gründen des Datenschutzes (vgl. Kap. 3) und insbesondere auch in didaktischer Argumentation teils explizit abgelehnt.

20.1.8

Anwenderschnittstelle Learning Management-Systeme sind inzwischen hauptsächlich als webbasierte Systeme realisiert, auf die mittels Browsersystemen zugegriffen wird (vgl. Kap. 28). Vereinzelt existieren aber zusätzlich zum Browserzugriff insbesondere für »nicht lernende« Anwender auch konventionelle, nicht-webbasierte Anwenderschnittstellen (vgl. Hettrich & Koroleva 2003, 36f.).

20.2

Anwendung von Learning Management-Systemen Learning Management-Systeme bilden das Ergebnis der Konvergenz zweier »klassischer« personalwirtschaftlicher Systemkategorien. Die dadurch (zunehmend) vorhandene Kombination einer Unterstützung von direkten didaktischen Aufgaben und indirekten administrativen Aufgaben der Weiterbildung ermöglicht die Bereitstellung einer umfassenden Weiterbildungsinfrastruktur. Die individuelle Gestaltbarkeit der didaktischen wie der administrativen Dimension von Learning Management-Systemen ermöglicht dabei die Entwicklung und die Realisierung unternehmens-

260

20.2 Anwendung von Learning Management-Systemen individueller Lern- und Entwicklungsstrategien. So wird angesichts der unmittelbaren Verfügbarkeit von Lerninhalten elektronischer Kurse die Option eines zeitnahen, feingranularen und unmittelbar bedarfsorientierten Lernens (»On Demand-Learning«) eröffnet. Ebenso können Learning Management-Systeme durch die explizite Kombination elektronischer und konventioneller Varianten der Wissensvermittlung als zentrale Basis für ein Blended Learning dienen. Analoges gilt für den als zukunftsweisend erachteten Bereich des aktiven kollaborativen Lernens (vgl. Clarey et al. 2007). Das zentrale Potenzial von Learning Management-Systemen wird daher nicht ausgeschöpft, wenn »lediglich« eine Rationalisierung von Lern- und Administrationsprozessen angestrebt wird, um eine effiziente und schnelle Vermittlung von Inhalten an eine größere Zahl von lernenden Anwendern und ein umfassendes Bildungscontrolling zu ermöglichen. Eine umfassende Nutzung erfordert vielmehr eine strategische und unternehmensindividuelle Ausrichtung administrativer und insbesondere didaktischer Prozesse und Inhalte des Systems. Entsprechend sind im Rahmen der Implementierung erhebliche konzeptionelle Anstrengungen notwendig. Neben der Anwendung zur Unterstützung der innerbetrieblichen Personalentwicklung können Learning Management-Systeme aufgrund ihrer Funktionalität oft auch von kommerziellen Weiterbildungsdienstleistern und klassischen Bildungsinstitutionen wie Universitäten eingesetzt werden. Teilweise werden für diese unterschiedlichen Anwenderkategorien auch spezifische Versionen angeboten (vgl. Milius 2002). Verbreitung

Eine empirische Studie zur Verbreitung des e-Learning zeigt auf, dass 30% der Unternehmen CBT-Systeme anwenden, wobei sich dieser Anteil bei Unternehmen mit mehr als 500 Mitarbeitern auf 60% verdoppelt (vgl. Küpper 2005, 91ff.). Dabei ist im Sinne der hier verwendeten Kategorisierung allerdings davon auszugehen, dass auch zahlreiche CBT-Systeme (vgl. Kap. 19) angewendet werden.

261

21

Performance Management-Systeme (Personalwirtschaftliche) Performance Management-Systeme (»HR Performance Management-Systeme«, »Employee Performance Management-Systeme«, e-Performance-Systeme, teils auch Personalbeurteilungssysteme) sind Anwendungen zur systematischen Steuerung der individuellen Arbeitsleistung von Mitarbeitern.

21.1

Architektur und Funktionalität von Performance Management-Systemen Performance Management-Systeme weisen neben der obligatorischen Anwenderschnittstelle eine Datenbankkomponente mit Daten zu Mitarbeitern, Gesprächen, Zielvereinbarungen und Beurteilungen auf, die fakultativ um eine Datei mit weiteren Beurteilungskriterien ergänzt werden. Funktionale Komponenten beziehen sich auf die Zielfestlegung, den Beurteilungsvorgang, die Analyse von Beurteilungen sowie auf die Administration des Prozesses (vgl. Abb. 21.1). Performance Management-System Anwenderschnittstelle Administration Zielfestlegung

Beurteilung

Mitarbeiter

Ziele

Gespräche

Kriterien

Analyse

Arbeitszeitmanagement Personalabrechnung

Beurteilungen

Vergütungsmanagement Learning Management Entwicklungsplanung

Abb. 21.1: Idealtypische Architektur von Performance Management-Systemen

263

21

Performance Management-Systeme Eine Personendatei enthält Stammdaten der zu beurteilenden und der beurteilenden Personen. Eine Gesprächsdatei erfasst alle mit einem Mitarbeiter geführten Gespräche. Eine Ziel(vereinbarungs)datei nimmt die für eine Periode vereinbarten Ziele auf. Eine Beurteilungsdatei historisiert erhaltene Beurteilungen. Die Teilprozesse der Festlegung von Zielen, der Beurteilung der Zielerreichung sowie der Analyse von Beurteilungsergebnissen werden von jeweils eigenen funktionalen Komponenten unterstützt. Eine Administrationskomponente verwaltet den Prozess und verbindet die unterschiedlichen beteiligten Anwenderkategorien mit Workflows.

Abgrenzung CPM

Neben personalwirtschaftlichen Performance Management-Systemen, die auf Ebene individueller Mitarbeiter ansetzen, existieren auch Performance Management-Systeme auf Ebene des Gesamtunternehmens (»Corporate Performance Management [CPM]«). Solche Systeme zielen auf das Management des gesamten Unternehmenserfolgs (vgl. etwa Miranda 2004). Ohne Frage bedürfen beide Ebenen einer Abstimmung. Entsprechend finden sich vereinzelt Systeme, die beide Ebenen integrieren oder personalwirtschaftliche Performance Management-Systeme, die sich im Rahmen der Kaskadierung von Zielen an generellen Zielen des Unternehmens ausrichten lassen. Gleichwohl muss derzeit von zwei getrennten Systemkategorien ausgegangen werden.

21.1.1

Datenhaltungskomponenten Eine Personendatei enthält zunächst die Stammdaten wie Name, Stellenbesetzung, Dauer der Zugehörigkeit etc. der zu beurteilenden wie der beurteilenden Personen. Sollen externe Beurteiler, z.B. Kunden, herangezogen werden, können teilweise auch diese in der Datei aufgenommen werden. Eine Gesprächsdatei speichert alle im Rahmen des Performance Management geführten Gespräche. I.d.R. finden sich hier verschiedene Gesprächskategorien. Neben Zielvereinbarungsgesprächen, die der Festlegung entsprechender Ziele dienen, werden i.d.R auch innerperiodische Zielverfolgungsgespräche, die der Evaluation, aber auch dem Ergreifen von Maßnahmen im Bereich Beratung und Training dienen, sowie Zielerreichungsgespräche abgelegt. Eine Ziel(vereinbarungs)datei dient der strukturierten Ablage von mit den Mitarbeitern vereinbarten (Leistungs-)Zielen. Als Ergebnis einer Kaskadierung oder sukzessiven Operationalisierung können dabei häufig nicht nur individuelle Einzelziele, sondern

264

21.1 Architektur und Funktionalität von Performance Management-Systemen komplette Zielhierarchien mit Ober- und Unterzielen in einer Baumstruktur abgelegt werden. Damit ist es auch möglich, Mitarbeiter unterschiedlicher Hierarchieebenen mit entsprechend unterschiedlich »konkreten« Zielen in den Beurteilungsprozess mit aufzunehmen. Ziele werden zunächst eindeutig benannt, näher beschrieben und in die Zielhierarchie eingeordnet. Zur Schaffung eines besseren Verständnisses ist i.d.R. auch Freitext zu jedem Ziel eingebbar. Die Zuordnung von Zielen zu einzelnen Mitarbeitern schafft dementsprechend klare Verantwortlichkeiten für die Zielerreichung. Zusätzlich zu den Zielen können auch die Messvorschriften abgelegt werden, mittels derer die Zielerreichung zu erheben ist. Bei operational definierten Zielen wie »Erhöhung der Leads um 3% im ersten Halbjahr« ergeben sich solche »Messvorschriften« allerdings häufig von selbst. Ebenso können »Meilensteine« festgelegt werden, die wichtige innerperiodische Etappen der Zielerreichung markieren. Teils werden auch die zur Zielerreichung notwendigen Arbeitsmittel festgehalten. Neben Zielen kann eine fakultative Datenhaltungskomponente weitere Beurteilungskriterien aufnehmen. So existieren Systeme, die die Beurteilung von Kompetenzen oder Qualifikationen ermöglichen. Solche Systeme halten entsprechend Qualifikationen in strukturierter Weise, meist einer Baumstruktur, vor. Darüber hinaus existieren aber auch Systeme, die im Rahmen der Systemimplementierung (vgl. Kap. 2) eine völlig freie Anlage beliebiger personen-, verhaltens- und/oder leistungsorientierter Beurteilungskriterien ermöglichen. In der Folge können auch umfangreiche Sammlungen möglicher Beurteilungskriterien nach Kategorien geordnet und in einer Baumstruktur abgelegt werden. Da die Beurteilung von Qualifikationen wie weiterer Kriterien meist nach der Einstufungsmethode erfolgt, können die einzelnen Qualifikationen wie Kriterien teils mit spezifischen ordinalskalierten Einstufungsskalen verbunden werden. Diese sind im Rahmen des Customizing ebenfalls zu erstellen. Um solche Kriteriensammlungen für unterschiedliche Beurteilungsanlässe (z.B. Prämiengewährung oder Entwicklungsgespräch) sowie verschiedene Beurteiltenkategorien (z.B. Führungskraft, Auszubildende etc.) nutzen zu können, können verschiedene Kriterien und dazugehörige Skalen zu umfassenderen Beurteilungstypen zusammengefasst werden. Diese zusätzliche Bereitstellung von Beurteilungskriterien und -typen ermöglicht die alternative oder additive Beurteilung von Mitarbeitern jenseits eines Zielvereinbarungskonzeptes.

265

21

Performance Management-Systeme Eine Ergebnisdatei speichert durchgeführte Beurteilungen ab. Je nach Art der Beurteilungskomponente können diese in Beurteilungsprofilen und/oder Freitexten bestehen. Beurteilungen werden dabei regelmäßig historisiert und stehen damit für vergleichende Analysen im Zeitablauf zur Verfügung. Die Beurteilungsdatei dient dabei sowohl als Datenlieferant für die Analysekomponente als auch für externe Systeme im Bereich Vergütungsmanagement, Learning Management und Entwicklungsplanung.

21.1.2

Administrationskomponente Die Administrationskomponente dient der Verwaltung und Steuerung des gesamten Performance Management-Zyklusses. Dies schließt zunächst eine Anwenderverwaltung mit ein, bei der verschiedene Anwenderrollen wie »Beurteiler (Fachvorgesetzter)«, »Beurteilter« u.a.m. die grundsätzlichen Zugriffsmöglichkeiten auf Daten und Funktionen des Systems bestimmen. Da es sich bei Performance Management um einen sich zyklisch wiederholenden Prozess wiederkehrender Funktionen handelt, finden sich in zahlreichen Systemen Workflowfunktionalitäten, die eine Abbildung solcher Prozesse ermöglichen. Oft bieten Systeme bereits vorgefertigte Referenzprozesse an, die im Rahmen des Customizing teils auch noch modifiziert und an unternehmensindividuelle Belange angepasst werden können. Abb. 21.2 deutet einen solchen Prozess grob an. Den einzelnen Funktionen werden dabei ein oder mehrere konkrete Anwender(rollen) zugeordnet. Mittels einer Workflowengine übernimmt die Administrationskomponente die Ablaufsteuerung des Prozesses. Tritt ein Auslöseereignis, wie etwa die Festlegung von Bereichszielen ein, wird die Abarbeitung des Prozesses automatisiert angestoßen. Bei den entsprechenden Anwendern wird dabei ein WorkflowEingang erzeugt, der eine anstehende Aufgabe wie »Zielvereinbarungsgespräch vereinbaren« oder »Zwischenbeurteilung durchführen« anzeigt. Beim korrespondierenden Bearbeitungsvorgang, stellt die Administrationskomponente dem Bearbeiter auch die zur Bearbeitung notwendigen Systemfunktionen – wie etwa eine Eingabemaske zur Durchführung einer Zwischenbeurteilung – zur Verfügung. Auch die anschließende automatisierte Weiterleitung von Teilergebnissen entlang der Prozesskette (»Routing«) wird von der Administrationskomponente übernommen. Bedürfen vergebene Beurteilungen einer Genehmigung – etwa durch den nächst höheren Vorgesetzten – dann können auch Genehmigungsverfahren eine Abbildung im Prozess erfahren. Aufgrund der meist vorliegenden Webbasierung der Systeme, können auch

266

21.1 Architektur und Funktionalität von Performance Management-Systemen räumlich getrennte Anwender im Sinne eines Self Service an derartigen Performance Management-Prozessen teilnehmen. Zielbildung Zielvereinbarungsgespräch Ziele vereinbart Zielbearbeitung Vorgabezeitraum abgelaufen XOR

Zielerreichungsgespräch

Zielverfolgungsgespräch

Zielerreichung geklärt

Zwischenergebnisse geklärt

Endbeurteilung

Zwischenbeurteilung

Endbeurteilung erfolgt

Zwischenbeurteilung erfolgt

š Entwicklung

Vergütung

Abb. 21.2: Zyklischer Ablauf eines Beurteilungsprozesses Auf diese Weise kann der gesamte Prozess des Performance Managements im und vom System strukturiert verwaltet und gesteuert werden.

21.1.3

Zielfestlegungskomponente Die Zielfestlegungskomponente unterstützt die unternehmensweite Festlegung von Mitarbeiterzielen. Je nach System kann diese Festlegung auf unterschiedliche Weise erfolgen. Sehr häufig werden Ziele nach einem Zielvereinbarungsgespräch über Manager Self Service vom entsprechenden Vorgesetzten einfach eingegeben. Die Funktionalität der Komponente beschränkt sich dann 267

21

Performance Management-Systeme auf einfache Datenhaltung. Neben der bloßen Benennung, können Ziele i.d.R. auch näher beschrieben und mit entsprechenden Messvorschriften bzw. Kennzahlen versehen werden. Ebenso wird die Zielperiode bzw. der Termin der Zielerreichung festgelegt. Teils können dabei verschiedene Zeiträume parallel verwendet werden und etwa Halbjahres- und Jahresziele definiert werden. Im Rahmen von Zielvereinbarungszyklen werden Ziele jedoch häufig einheitlich auf Jahresfrist festgelegt. Die damit für einen Mitarbeiter entstehende Zielsammlung kann weiter oft mit unterschiedlichen Gewichtungen versehen werden, wenn den festgelegten Zielen eine unterschiedliche Wertigkeit zukommen soll. Weitergehende Systeme bemühen sich um die Abstimmung der individuellen Ziele mit generellen Zielen bzw. Strategien des Unternehmens. Häufig werden hier Vorgehensweisen implementiert, die sich an der »Balanced Scorecard (BSC)« orientieren (vgl. Kaplan & Norton 1996). Dazu werden zunächst auf Unternehmensebene (strategische) Ziele definiert, die aus mehreren Perspektiven, konventionellerweise der Finanz-, der Kunden-, der Prozess- und der Mitarbeiterperspektive, zu betrachten sind.

Kaskadierung

Kaskadierung

Finanzen Kunden

F2.1 Umsatz Außendienst F3.1 Umsatz Reisender

F1.2 Kostensenkung

F2.2 Spesen Außendienst

F3.2 Spesen Reisender

...

...

...

K1.1 Neukundengewinnung K2.1 Anzahl Leads

P1.1 Prozessbeschleunigung P2.1 Antwortzeiten

P3.1 ' t Anfrage-Besuch

P1.2 KVP

P2.2 Anzahl Retouren

P3.2 Anzahl Retouren

...

...

...

M1.1 Absentismus

M2.1 Anzahl Fehltage

M3.1 Anzahl Fehltage

M2.2 Anzahl Trainings

M3.1 Teilnahme Training

...

...

K3.1 Anzahl Leads/Reis.

K1.2 Kundenzufriedenheit

K2.2 Wiederkaufrate

K3.2 Wiederkaufrate

...

...

...

Abb. 21.2: Zielkaskadierung M1.2 Qualifikation ...

Abb. 21.3: Kaskadierung von Zielen

268

Mitarbeiter

Prozesse

Bereich

Mitarbeiter

Unternehmen F1.1 Umsatzwachstum

21.1 Architektur und Funktionalität von Performance Management-Systemen Für jede Perspektive sind dabei zentrale Ziele und korrespondierende Kennzahlen zu bestimmen. Ist dieser Zielbildungsprozess auf Unternehmensebene abgeschlossen, unterstützt die Zielfestlegungskomponente die Kaskadierung von Zielen auf nachgelagerte Ebenen. Entsprechend können die generellen Ziele beispielsweise auf Bereichsziele und anschließend auf Individualziele herunter gebrochen werden. Die systemseitige Unterstützung beschränkt sich hierbei allerdings auf die Bereitstellung entsprechender Datenstrukturen und das Einfordern von Pflichteingaben. Der inhaltliche Kaskadierungsprozess muss durch die jeweiligen Anwender stattfinden. Abb. 21.3 deutet einen solchen Kaskadierungsprozess für einen Mitarbeiter des Vertriebsaußendienstes an. Auf diese Weise entsteht eine Zielhierarchie, die sicherstellt, dass Ziele der Individualebene auch auf generelle Ziele des Unternehmens ausgerichtet sind. Damit wird tendenziell ein »Top-Down«-Ansatz der Zielbildung verfolgt, der den Mitarbeitern Ziele mehr oder minder autoritär vorgibt. Teils ist es daher möglich, im Rahmen von Zielvereinbarungsgesprächen weitere, individuell vereinbarte Ziele einzubringen. Rein partizipative »Bottom-Up«-Systeme, wie im Rahmen der »Management-by-Objectives«-Diskussion ebenfalls angedacht, lassen sich derzeit dagegen nicht nachweisen.

21.1.4

Beurteilungskomponente Die Beurteilungskomponente dient grundsätzlich der Unterstützung der beurteilenden Person bei der Beurteilung. Vorfindbare Systeme unterscheiden sich diesbezüglich teilweise in Bezug auf mögliche ƒ Beurteilungsmethode, ƒ Beurteiler und ƒ Ergebnisausgaben.

Beurteilungsmethoden

Beurteilungsmethoden sind diejenigen Vorgehensweisen, die einer beurteilenden Person systemseitig zur Durchführung der Beurteilung angeboten werden. Allerdings wird das bekannte Methodenspektrum kaum ausgenutzt. In der Regel dominieren Varianten der Einstufungsmethode, die eventuell um die freie Eindruckschilderung mit und ohne Merkmalsvorgabe ergänzt werden. Zunächst wird die Einstufungsmethode zur Überprüfung der Zielerreichung eingesetzt, wenn – neben absoluten Werten – die Zielerreichung auch auf einer numerischen Skala von 0-100% (falls eine Übererfüllung möglich ist, auch darüber hinaus) eingestuft wird. Die Ergebnisse einzelner Ziele können dann meist – etwa über die Bildung eines Mittelwertes – zu einem aggregier269

21

Performance Management-Systeme

...

Kategorie1

ten Wert zusammengefasst werden. Dabei können auch unterschiedliche Gewichtungen einzelner Ziele berücksichtigt werden. Sollen alternativ oder additiv zur Zielerreichung weitere Aspekte beurteilt werden, wird auch hierzu meist die Einstufungsmethode verwendet. Entsprechend haben der oder die Beurteiler die einzelnen Kriterien eines ausgewählten Beurteilungstyps auf einer ordinalen Skala einzuschätzen. Da die einzelnen Stufen der Ordinalskala dabei meist mit numerischen Werten versehen werden, kann auch hier eine Aggregation zu Gesamtwerten erfolgen. Dabei können auch unterschiedliche Gewichtungen einzelner Kriterien berücksichtigt werden, wie in Abb. 21.4 angedeutet. Einstufung

Einstufungstext

Gewichtung

Kriterium1

4

ausreichend

3,00

Kriterium2

10

sehr gut

2,00

Kriterium3

9

sehr gut - gut

1,00

Kriterium ..

...

...

...

Kriterium7

6

befriedigend

1,00

Kriterium8

7

gut - befriedigend

1,00

Kriterium ..

...

...

...

6

176

Abb. 21.4: Gewichtete ordinale Einstufung Meist zusätzlich möglich ist die freie Eindruckschilderung mit oder ohne Merkmalsvorgabe, die in einer systemseitigen Umsetzung schlicht in entsprechenden Freitextfeldern besteht. Zur weiteren Unterstützung des Beurteilungsprozesses ist es teilweise möglich, dass Beurteiler wie Beurteilter im Zeitablauf Notizen über leistungsrelevante Sachverhalte und erreichte (Zwischen-) Ergebnisse im System dokumentieren können, damit diese nicht vergessen werden und zum Beurteilungszeitpunkt zur Verfügung stehen. Beurteiler

270

Beurteiler sind diejenigen Personen, die die Beurteilung unter Anwendung des Systems durchführen sollen. Konventionell kommt zunächst dem jeweils direkten Vorgesetzten eines zu Beurteilenden diese Rolle zu. Zahlreiche Systeme lassen jedoch mehr als einen Beurteiler pro Beurteilung zu (»Multi Rater«-Ansatz). So besteht eine Variante zunächst auch in der Selbstbeurteilung des Mitarbeiters per Self Service. Umfassendere Systeme ermöglichen auch eine so genannte »360°«-Beurteilung, die ne-

21.1 Architektur und Funktionalität von Performance Management-Systemen ben Vorgesetzen- und Selbstsicht auch die Sicht von Kollegen, Untergegebenen sowie ggf. von Kunden ermöglicht. Eine interessante Variante besteht darin, dass sowohl der Vorgesetzte der zu beurteilenden Person als auch die zu beurteilende Person selbst aus ihrer Sicht geeignete Beurteiler vorschlagen und systemgestützt zur Abgabe einer Beurteilung »einladen«. So angefragte Personen können dann einer Beurteilung zustimmen oder diese u.U. auch ablehnen. Werden mehrere Beurteiler zugelassen, bietet die Beurteilungskomponente teils auch einfache Konsolidierungen der erzielten Ergebnisse an. Beispielsweise ist – bei heterogenen Beurteilungsergebnissen – die Ausgabe von Mittelwert, Median oder Varianz aller Beurteilungen möglich. Ebenso ist es teilweise möglich, dass insbesondere der Beurteilte Kommentare zu erhaltenen Beurteilungen abgeben kann, die dann gemeinsam mit der Beurteilung abgelegt werden. Ergebnisausgabe

Teils unterstützen die Beurteilungskomponenten auch die Aufbereitung der Beurteilungsergebnisse. Zunächst finden sich Systeme, die auf der Basis von Beurteilungsergebnissen Beurteilungstexte generieren können. Unter Rückgriff auf die Ergebnisse kann unter Heranziehen von Textbausteinen automatisiert ein Fließtext generiert werden, der die Ergebnisse der Beurteilung in verbaler Form wiedergibt. Teilweise findet die Erstellung des entsprechenden Textes dabei simultan mit der Einstufung des zu Beurteilenden statt. Wird ein Kriterium wie etwa »Arbeitsgüte« eingestuft, bietet das System verschiedene Textvorschläge an, die der gewählten Stufe entsprechen. Auf diese Weise entsteht neben der Einstufung ein korrespondierender Beurteilungstext, der modifiziert oder unmodifiziert abgelegt werden kann. Insbesondere für Beurteilungstexte, die von Beurteilern im Rahmen einer freien Eindruckschilderung erstellt wurden, bieten einige Systeme auch Sprachscanner an, die ähnlich einer Rechtschreibprüfung den Text auf kritische Stellen – wie etwa latent diskriminierende Begriffe – hin absuchen und entsprechende Hinweise geben.

21.1.5

Analysekomponente Die Analysekomponente ermöglicht Abfragen und Berichte über alle Aspekte der Leistungssteuerung sowie ein Tracking des gesamten Performance Management-Prozesses.

Abfragen

Zunächst ermöglicht die Analysekomponente generelle Stärken- / Schwächenanalysen des existierenden Personals, die Identifikation von Leistungsträgern, die systematische Überwachung der Zielerreichung etc. Teilweise können dabei »Zielkarten« ausgege271

21

Performance Management-Systeme ben werden, die mittels Ampelfunktionen o.ä. übersichtlich über die Zielerreichung informieren. Übergreifend können dabei auch vergleichende Analysen zur Zielerreichung je Team oder Abteilung und im Vergleich verschiedener Zielperioden durchgeführt werden. Teilweise können zur breiteren Analyse der Beurteilungsdaten weitere Daten aus externen Anwendungssystemen herangezogen werden. Insbesondere werden hierfür Lohn- und Gehaltsdaten sowie Arbeitszeitdaten wie etwa Fehltage vorgeschlagen. Ebenso werden Auswertungen in Bezug auf Gewährung möglicher (Zielerreichungs-)Prämien oder die Notwendigkeit bestimmter Personalentwicklungsmaßnahmen ermöglicht

Tracking

Weiter ist es mittels eines »Tracking« zunächst der Fachabteilung »Personal« möglich, die Abarbeitung des Prozesses systematisch zu überwachen. Säumige Beurteiler, anstehende Gespräche etc. können so direkt erkannt und angesprochen bzw. eingefordert werden. Ein Tracking dient aber auch dazu, den Beurteilern jederzeit einen Überblick über den Stand »ihrer« Beurteilungsprozesse zu geben und aufzuzeigen, wo noch Handlungsbedarf besteht. Ebenso können Beurteilte jederzeit Stand und (Zwischen-) Ergebnisse ihrer Beurteilung(en) einsehen, demnächst anstehende Gesprächstermine abfragen etc. Insgesamt bietet das Tracking allen Beteiligten permanent eine systematische Übersicht über den Stand des Beurteilungsprozesses.

21.2

Anwendung von Performance Management-Systemen Performance Management-Systeme können in Unternehmen zur systematischen Planung, Steuerung und Kontrolle individueller Leistungserbringung eingesetzt werden. Grundsätzlich auf altbekannten Konzepten und Methoden wie Zielvereinbarung, Kennzahlen und Einstufung beruhend, handelt es sich damit um eine strategisch interessante personalwirtschaftliche Systemkategorie, die das Potenzial aufweist, individuelles Handeln an übergreifenden Zielen auszurichten. Insofern ist die organisatorische und strategische Einbettung von Performance Management-Systemen eine zentrale Voraussetzung zur Nutzung wesentlicher Potenziale. Auch die Administration kann insbesondere durch die häufig angebotene Möglichkeit eines webbasierten Self Service erheblich vereinfacht werden. Der Gesamtprozess kann so administrativ deutlich besser gehandhabt werden. Zur Unterstützung der erwünschten individuellen Leistungserbringung kann das Performance Management teils auch systematisch mit der Entwicklung und Vergütung der entsprechenden Mitarbeiter abgestimmt werden. Entsprechend finden sich teils modulare Lösungen (vgl.

272

21.2 Anwendung von Performance Management-Systemen Kap. 1), die das Performance Management mit dem Learning Management (vgl. Kap. 20) und dem Vergütungsmanagement (vgl. Kap. 22) integrieren. Verbreitung

Derzeit geben mit 26% bereits etwas über ein Viertel der Unternehmen an, ein informationssystemgestütztes Performance Management zu betreiben (vgl. Kabst & Giradinni 2005, 41). Damit dürften Performance Management-Systeme eine Renaissance zielvereinbarungsbasierter Managementsysteme eingeläutet haben.

273

22

Vergütungsmanagementsysteme Vergütungsmanagementsysteme (»[Total] Compensation [Management]-Systems«, »Compensation- and Benefits-Systems«, »Reward Systems«) sind Systeme zur Konzeption, Kommunikation und Administration von ganzheitlichen Entgeltkonzeptionen (vgl. Dulebohn & Marler 2005, 167).

22.1

Architektur und Funktionalität von Vergütungsmanagementsystemen Idealtypisch verfügen Vergütungsmanagementsysteme zunächst über eine unterschiedlich umfangreiche Datenhaltungskomponente sowie eine Komponente zur Vergütungsplanung, -verwaltung und -analyse. Fakultativ können weitere Komponenten zur Stellenbewertung, zur Leistungsbeurteilung sowie zur Budgetierung vorhanden sein (vgl. Abb. 22.1). Vergütungsmanagementsystem Anwenderschnittstelle Stellenbewertung

Leistungsbeurteilung

Budgetierung

Vergütungsanalyse

Vergütungsplanung

Vergütungsverwaltung

Stellendaten

Personaldaten

Budgetdaten

Marktdaten

Vergütungsplan

Vergütungsdaten

Performance Management

Personal- Vergütungskostenplan. dienstleister

Personalabrechnung

Abb. 22.1: Idealtypische Architektur von Vergütungsmanagementsystemen Die Datenhaltungskomponente weist im Kern Personal- und Vergütungsplandaten auf, die je nach System fakultativ um weitere 275

22

Vergütungsmanagementsysteme vergütungsrelevante Daten zu Stellen, Budgets und Marktbedingungen ergänzt werden können. Eine Vergütungsplanungskomponente dient der Entscheidung über künftige Vergütungsstrukturen. Eine Analysekomponente ermöglicht die Auswertung der verfügbaren Vergütungs- sowie ggf. weiterer Daten. Eine fakultative Stellenbewertungskomponente ermöglicht die Bestimmung des Anforderungsniveaus von Stellen und daraus resultierender anforderungsbezogener Grundvergütungen. Eine fakultative Leistungsbeurteilungskomponente kann zur Bestimmung des Leistungsniveaus von Mitarbeitern und daraus resultierender leistungsbezogener variabler Vergütungsbestandteile herangezogen werden. Eine ebenfalls fakultative Budgetierungskomponente erlaubt die Steuerung der in einer Periode insgesamt verausgabten Mittel sowie deren zielgerechte Zuweisung auf einzelne Bereiche des Unternehmens.

Landesversionen

Viele Vergütungsmanagementsysteme sind inzwischen international einsetzbar. Dies bedingt i.d.R. zunächst korrespondierende Sprachversionen des Systems. Zusätzlich ist meist eine Mehrwährungsfähigkeit gegeben. Dies erlaubt das parallele Arbeiten mit verschiedenen Währungen. Etwa kann die Budgetierung zentral in einer gemeinsamen Referenzwährung vorgenommen (und dann in landesspezifische Währungen umgesetzt) werden, während die Vergütungsplanung dezentral in den jeweiligen Landeswährungen erfolgt. Weiter sind auch unterschiedliche Landesspezifika in der Vergütung, etwa das für Deutschland typische »13. Monatsgehalt«, abzubilden. Teils existieren auch unterschiedliche nationale Regelungen, etwa zur Gleichbehandlung in Vergütungsfragen, die in entsprechenden Landesversionen ebenfalls einer Abbildung im System bedürfen (vgl. Wright 2003, 57).

22.1.1

Datenhaltungskomponenten Die Datenhaltungskomponente weist je nach funktionalem Umfang des Systems unterschiedliche Teilbereiche auf. Im Kern sind vom System Personal- und Vergütungsplandaten zu halten, die je nach System fakultativ um vergütungsrelevante Daten zu Stellen, Personen, Budgets und Vergütungsstrukturen anderer Unternehmen angereichert werden.

Stellendaten

276

Stellendaten sind zunächst für stellenbezogene Vergütungsarten, insbesondere die anforderungsbezogene Grundvergütung notwendig. Entsprechend benötigen Systeme, die eine Stellenbewertung durchführen, neben allgemeinen Stammdaten zunächst Daten zur organisatorischen Einordnung sowie zu den Aufgaben

22.1 Architektur und Funktionalität von Vergütungsmanagementsystemen und Verantwortlichkeiten der Stelle und daraus abgeleiteten Anforderungen an mögliche Stelleninhaber. Solche Daten können teilweise auch aus Vorsystemen übernommen werden. Wird auf Basis dieser Daten eine spezifische Methode zur Stellenbewertung – intern durch eine Stellenbewertungskomponente oder extern durch eine Vergütungsberatung durchgeführt – müssen die angebotenen Daten bereits auf die entsprechende Methode zugeschnitten sein. Auf der Basis von Stellendaten erzielte Bewertungsergebnisse werden dann – etwa in Form von Teilund/oder Gesamtarbeitswerten – ebenfalls den Stellendaten hinzugefügt. Weiter sind aggregierte Stellendaten teils auch im Rahmen der Budgetierung notwendig, um Gruppen von Stellen mit Budgets zu versehen bzw. Budgetierungseinheiten zu bilden. Bietet das System weder Stellenbewertung noch Budgetierungsfunktionen an, werden entsprechend keine Stellendaten benötigt. Personaldaten

Eine Personaldatenkomponente enthält Daten derjenigen Mitarbeitersegmente, die in das Vergütungsmanagementkonzept einbezogen werden sollen. Neben Systemen, die sich umfassend auf den gesamten Personalbestand ausrichten, existieren aufgrund der spezifischen rechtlichen Situation der Entgeltgestaltung in Deutschland häufiger auch Systeme, die speziell auf das Vergütungsmanagement des außertariflichen Bereichs ausgerichtet sind. Neben den üblichen Personalstammdaten werden speziell vergütungsrelevante Daten wie Lebensalter, Dauer der Firmenzugehörigkeit, Einstufung und insbesondere aktuelle und historisierte Daten zur Vergütung des entsprechenden Mitarbeiters gehalten. Dies betrifft zunächst alle gewährten Vergütungsbestandteile. Entsprechend werden neben der monetären Vergütung durch Grundentgelt und der variablen Vergütung durch Prämien oder Einmalzahlungen auch Mitarbeiterbeteiligungen, Firmenwagen, betriebliche Altersversorgung und Varianten der aufgeschobenen Vergütung (»Deferred Compensation«) mit aufgenommen. Sind Stellendaten vorhanden, werden Mitarbeitern auch aktuelle und historische Stellen zugeordnet. Insbesondere um über leistungsabhängige Vergütungsbestandteile wie Prämien, Einmalzahlungen oder Varianten der Mitarbeiterbeteiligung entscheiden zu können, werden auch meist Ergebnisse einer internen oder externen Leistungsbeurteilung in der Personaldatei abgelegt. Personaldaten können dabei zunächst eingepflegt werden, wobei «unproblematische« Stammdaten im Rahmen webbasierter Vergütungsmanagementsysteme und eines Self Service-Konzeptes durch die Mitarbeiter selbst unter Verwendung von Browsersystemen (vgl. Kap. 28) erfasst werden können. Existieren entspre277

22

Vergütungsmanagementsysteme chende Personaldaten bereits in anderen personaldatenhaltenden Systemen, kann auch ein Import erfolgen. Speziell vergütungsrelevante Leistungsdaten können auch aus externen Performance Management-Systemen stammen (vgl. Kap. 21).

Budgetdaten

Eine Budgetdatei nimmt Daten zu historischen, aktuellen und insbesondere geplanten Budgets auf. Budgets repräsentieren dabei den Umfang der jeweils bereit zu stellenden Vergütungsbestandteile. Budgets müssen dabei nicht zwangsweise exklusiv aus monetären Mitteln bestehen, sondern können auch weitere Vergütungsbestandteile wie Aktien, Aktienoptionen, Firmenwagen o.ä. umfassen. Da Teilbudgets einzelnen Budgetierungseinheiten zugewiesen werden, die durch Segmente von Stellen oder Mitarbeitern gebildet werden, können auch Verbindungen zur Stellen- oder Mitarbeiterdatei bestehen. Budgetdaten können im Sinne hierarchischer Budgets weiter für unterschiedliche Budgetierungsebenen im Unternehmen gehalten werden. Damit nimmt die Budgetdatei zum einen die Ergebnisse einer möglichen Budgetierungskomponente auf. Zum anderen stellt die Budgetdatei auch historische Budgetdaten für die Budgetierungskomponenten bereit, um etwa das Budget des Vorjahres für das zu planende Jahr generell um einen gewissen Prozentsatz anzuheben u.a.m.

Marktdaten

Marktdaten bilden eine weitere wichtige Informationsgrundlage für die Planung einer marktgerechten Vergütung. Entsprechend weisen viele Vergütungsmanagementsysteme die Möglichkeit auf, entsprechende Vergleichsdaten zu halten. Solche Vergleichdaten können zunächst von externen Dienstleistern bezogen werden. Teilweise organisieren solche Dienstleister auch Vergleichstudien (»Benchmarking«), an denen Unternehmen teilnehmen können. An der Vergleichstudie teilnehmende Unternehmen reichen dann ihre anonymisierten und/oder aggregierten internen Vergütungsdaten an den Dienstleister weiter und erhalten im Gegenzug die zusammengeführten Vergütungsdaten aller Teilnehmer. Für die sinnvolle Nutzung solcher Vergleichdaten ist neben deren Reliabilität und Repräsentativität die grundlegende Übereinstimmung der Marktdatenstrukturen mit den internen Stellen- und Mitarbeiterkategorien des Unternehmens Voraussetzung. Im Ergebnis ermöglichen solche Marktdaten unter Rückgriff auf die Analysekomponente vergleichende Auswertungen, die interne Vergütungsstrukturen mit aktuellen externen Vergütungsstrukturen abgleichen.

278

22.1 Architektur und Funktionalität von Vergütungsmanagementsystemen Vergütungs(plan)daten

Eine zentrale datenhaltende Komponente umfasst schließlich Daten zu aktuellen und teils auch historisierten Vergütungsplänen. Als Ergebnis der mit der Planungskomponente durchgeführten Vergütungsplanung zeigen Vergütungspläne für einen festgelegten Planungszeitraum in einer festgelegten Zeitrasterung auf, welchem Vergütungsempfänger welche Vergütungsarten in welchem Umfang zugesprochen werden. In aller Regel sind dabei individuelle Mitarbeiter als Vergütungsempfänger vorgesehen, denen die bereits angesprochenen monetären sowie nicht-monetären Vergütungsbestandteile bewilligt werden. Neben individuellen Mitarbeitern können teils zusätzlich oder alternativ auch Organisationseinheiten als kollektive Vergütungsempfänger beplant werden. Zur Realisation und Verwaltung des Vergütungsgeschehens werden genehmigte Plandaten in eine administrative Datei überführt. Diese Datei nimmt im weiteren Ablauf Daten zum faktischen Vergütungsgeschehen auf. Entsprechend werden hier einzelne administrative Ist-Daten zu einzelnen Vergütungsempfängern, Vergütungsarten und Budgets abgelegt. Teils werden aber insbesondere monetäre Vergütungsarten auch komplett über externe Personalabrechnungssysteme (vgl. Kap. 13) realisiert und administriert. In diesem Fall können Plandaten oft an externe Abrechnungssysteme exportiert werden.

22.1.2

Stellenbewertungskomponente Um die Festlegung eines anforderungsabhängigen Grundentgelts zu unterstützen, verfügen Vergütungsmanagementsysteme vereinzelt über eigene Komponenten zur Stellenbewertung. Neben der Bewertung individueller Stellen ist aus Aufwandsgründen oft die Bewertung von Kategorien vergleichbarer Stellen vorgesehen. Methodisch sind hierzu oft Varianten der Stufenwertzahlmethode implementiert, die eine analytische Einstufung der Stelle bezüglich verschiedener Anforderungskriterien ermöglichen. Die einzelnen Anforderungskriterien können dabei meist auch gewichtet werden, um einen Gesamtarbeitswert zu erhalten. Neben vom System vorgegebenen Anforderungskriterien können im Rahmen der Systemimplementierung oft auch individuelle Kriterien festgelegt werden. Ebenso ist es möglich unterschiedliche Stellensegmente mit unterschiedlichen Kriteriensammlungen zu bewerten. Für die Validierung der Ergebnisse stehen dabei oft auch Quervergleiche zwischen verschiedenen bewertenden Personen und zwischen bewerteten Stellen zur Verfügung. Aufgrund der meist expliziten Ausrichtung am außertariflichen Stellensegment sind teils vorhandene tarifvertragliche Anforderungen an 279

22

Vergütungsmanagementsysteme die Stellenbewertung i.d.R. nicht berücksichtigt, können aber ggf. im Rahmen eines Customizing geschaffen werden. Gefundene Gesamtarbeitswerte können dabei meist automatisiert in ein Grundentgelt umgerechnet werden. Neben einer linearen Umsetzung existieren teils auch Möglichkeiten einer progressiven, degressiven oder gestuften Umsetzung von Arbeitswerten in Grundentgelt. Teils existiert – in gewissem Widerspruch zum Grundgedanken der Stellenbewertung – auch die Möglichkeit, ausgehend von Kostenüberlegungen gewisse Punktebudgets für einzelne Stellensegmente festzulegen, deren Einhaltung zur Einhaltung des vorgegebenen Budgets an anforderungsabhängigem Grundentgelt führt. Fehlt eine Stellenbewertungskomponente, können Stellenbewertungsdaten teils von extern übernommen werden. Ist auch dies nicht vorgesehen, muss die Bestimmung des Grundentgelts weitgehend losgelöst von Anforderungsüberlegungen auf der Basis von Konventionen und Plausibilitäten erfolgen.

22.1.3

Leistungsbeurteilungskomponente Um die Festlegung eines leistungsabhängigen variablen Entgelts zu unterstützen, verfügen Vergütungsmanagementsysteme vereinzelt über eigene Komponenten zur Leistungsbeurteilung. Methodisch werden häufig auf einem zyklischen Zielvereinbarungskonzept basierende Einstufungsverfahren angeboten (vgl. dazu Kap. 21). Damit erzielte Beurteilungsergebnisse werden in der Personaldatei abgelegt und können im Rahmen der Vergütungsplanung herangezogen werden, um über Zuteilung und Höhe möglicher variabler monetärer und nicht-monetärer Vergütungsbestandteile zu entscheiden. Alternativ können Leistungsbeurteilungsdaten auch von anderen Anwendungen, speziell Performance Management-Systemen (vgl. erneut Kap. 21) übernommen werden. Fehlt sowohl eine interne Komponente zur Leistungsbeurteilung als auch eine Schnittstelle zum Import von Leistungsbeurteilungsergebnissen, so muss im Rahmen der Vergütungsplanung individuell über die Bewilligung leistungsorientierter Vergütungsbestandteile wie die Zahlung von Prämien oder die Gewährung von Aktienoptionen entschieden werden, was einer Minimalvariante vergütungsorientierter Leistungsbeurteilung gleichkommt.

22.1.4

Budgetierungskomponente Eine fakultative Budgetierungskomponente dient grundsätzlich der Zuweisung von Vergütungsbestandteilen zu einzelnen Un-

280

22.1 Architektur und Funktionalität von Vergütungsmanagementsystemen ternehmensbereichen. Ziel ist die Steuerung der in einer Periode insgesamt ausgegebenen Mittel sowie deren zielgerichteter Verteilung auf einzelne Bereiche des Unternehmens. Als Voraussetzung einer Budgetierung sind zunächst Budgetierungseinheiten festzulegen. Budgetierungseinheiten sind gehaltspolitisch sinnvolle Segmente von Stellen oder Mitarbeitern. Budgetierungseinheiten können dabei mit Organisationseinheiten übereinstimmen. Häufig können jedoch auch beliebige andere Budgetierungseinheiten gebildet werden und Budgetzuweisungen über Organisationseinheiten hinweg – etwa für alle Mitarbeiter einer spezifischen Gehaltsgruppe – vorgenommen werden. Vielfach ist es dabei möglich, Budgetierungseinheiten – analog zu Organisationseinheiten – hierarchisch zu strukturieren, und etwa eine übergeordnete Budgetierungseinheit in mehrere untergeordnete Budgetierungseinheiten aufzuspalten. Dies erleichtert die Budgetverteilung, die dann in mehreren Schritten Budgetebene für Budgetebene erfolgen kann. Weiter ist eine Budgetperiode als ein sinnvoll erachteter Zeitraum festzulegen, für den das Budget vorgesehen ist. Häufig werden Budgetierungen für ein Jahr vorgenommen, meist sind Budgetperioden jedoch frei wählbar. Ebenso sind mittels der Budgetierungskomponente der Budgetumfang und die Budgetinhalte festzulegen. Entsprechend muss zunächst festgelegt werden, welche Budgetinhalte in welchem Umfang zur Verfügung gestellt werden sollen. Nach Festlegung dieser Eckdaten besteht der eigentliche Budgetierungsvorgang in der Zuweisung von Budgetbestandteilen zu einzelnen Budgetierungseinheiten. Hierbei sind zunächst retrograde Budgetierungen möglich, die Budgets über die einzelnen Budgeteinheiten und -ebenen hinweg zentral festlegen. Hierzu werden Funktionen wie Fortschreiben von Budgets aus der vorangegangenen Budgetierungsperiode, generelles Anheben des Budgetumfangs um einen gewünschten Prozentsatz u.a. unterstützt. (Unter Rückgriff auf die Analysekomponente können weiter Vergleiche der Budgetverteilung zwischen Abteilungen, Personengruppen, Budgetierungseinheiten etc. durchgeführt werden, um entscheidungsunterstützende Informationen zu erhalten). Teils sind aber auch progressive Budgetierungen möglich, bei denen für einzelne Budgeteinheiten Budgetverantwortliche bestimmt werden, die dann für eine Budgetierungsperiode Budgetwünsche anmelden. Solche Budgetanmeldungen werden dann geprüft und über einzelne Budgeteinheiten aggregiert, um zu einem Gesamtbudget zu gelangen. Insbesondere im zweiten Fall einer progressiven Budgetierung ist der Prozess der Budgetbeantragung, -überprüfung 281

22

Vergütungsmanagementsysteme und -freigabe oft im Sinne von Workflows hinterlegt. Die Budgetierung kann dann auch in größeren Unternehmen mit Budgetverantwortlichen auf unterschiedlichen hierarchischen Stufen strukturiert erfolgen, und der Fortgang des Budgetierungsprozesses kann systematisch nachverfolgt werden (»Tracking«). An dieser Stelle wird die Überschneidung zu Personalkostenplanungssystemen deutlich, die in analoger Weise Hochrechnungen von Kosten vornehmen (vgl. Kap. 10). Budgetierungsvorgänge können dabei unternehmensweit durchgeführt werden, ebenso sind regelmäßig »Teilbudgetierungen« für gewisse Teilbereiche des Unternehmens möglich.

22.1.5

Vergütungsplanungskomponente Als zentrale Komponente eines Vergütungsmanagementsystems ermöglicht eine Planungs- und Verwaltungskomponente die Festlegung, welche Vergütungsempfänger welche Vergütungsarten in welchem Vergütungsumfang innerhalb welchen Vergütungszeitraums und -zeitrasters erhalten. Als Vergütungsempfänger sind i.d.R. individuelle Mitarbeiter vorgesehen. Allerdings finden sich Systeme, die sich angesichts der tarifvertraglich bereits oft umfassend geregelten Vergütungsfindung explizit auf das Segment außertariflicher Mitarbeiter richten. Aus Aufwandsgründen werden meist nicht individuelle, sondern Cluster vergleichbarer Mitarbeiter gemeinsam verplant. Die Zuweisung entsprechender Vergütungsbestandteile erfolgt dann für alle Mitglieder eines Clusters gemeinsam. Mögliche Vergütungsarten können im Rahmen der Vergütungsplanung oft unternehmensindividuell festgelegt werden. Wie erwähnt können sowohl monetäre als auch nicht-monetäre Vergütungsarten aufgenommen werden. Im monetären Bereich können dabei unterschiedliche Arten von anforderungs- und leistungsbezogener Vergütungsarten aufgenommen werden. Nicht monetäre Vergütungsbestandteile beziehen sich im Wesentlichen auf Firmenfahrzeuge, Versicherungsleistungen und Mitarbeiterbeteiligungen. Firmenfahrzeuge können insbesondere im Führungskraftsegment unentgeltlich oder gegen eine gewisse Beteiligung an Leasinggebühren, Kraftstoffkosten o.ä. zur Verfügung gestellt werden. Versicherungsdienstleistungen sind insbesondere für Länder ohne gesetzlich geregelte Sozialversicherung interessant. I.w.S. können auch Varianten der betrieblichen Altersversorgung als Ergänzung einer gesetzlichen Rentenversicherung hier zugerechnet werden. Mitarbeiterbeteiligungen können das komplette Spektrum der Erfolgs- und oder Kapitalbeteiligungen abdecken. Sehr häufig wird

282

22.1 Architektur und Funktionalität von Vergütungsmanagementsystemen allerdings die Ausgabe von Aktien und Aktienoptionen unterstützt. In beiden Kategorien können dabei periodisch wiederkehrende wie auch einmalige Vergütungen berücksichtigt werden (vgl. Wright 2003, 53). Die Vergütungsplanung hat entsprechend zunächst festzulegen, welchem Mitarbeiter(cluster) welche Vergütungsart zusteht. In unmittelbarem Zusammenhang ist auch der Umfang der Gewährung einer Vergütungsart, d.h. etwa Höhe von Grundgehalt und Prämie, Kategorie und Ausstattung eines Firmenwagens, Umfang einer betrieblichen Altersversorgung oder die Anzahl der zu gewährenden Aktienoptionen festzulegen. Die Art und der Umfang der Gewährung hängen dabei je nach unternehmensindividueller Vergütungskonzeption oft von zahlreichen bedingenden Faktoren ab. Etwa kann neben den Anforderungen der Stelle und der Leistung des Mitarbeiters auch die Betriebszugehörigkeit, das Alter, Tätigkeitsbereich u.v.a. Bedingung für die Gewährung und den Umfang eines Vergütungsbestandteils sein. Wird die Vergütung budgetiert, ist regelmäßig auch die Abdeckung der vorgesehenen Vergütung durch das Budget eine Bedingung der Gewährung. Neben Systemen, die eine rein »manuelle« Vergütungsplanung durch menschliche Anwender vorsehen, finden sich Systeme, die die Vergütungsplanung über einen regelbasierten Ansatz unterstützen. Die grundsätzliche Idee besteht darin, die jeweilige Vergütungsstrategie bzw. -konzeption in einem Set von Regeln zu formulieren, die vom System dann automatisiert angewendet werden können. So könnte etwa die Gewährung der Vergütungsart »Fixe Leistungsprämie« über verschiedene Regeln wie »Gewährung nur an Mitarbeiter mit einem Leistungsbeurteilungsergebnis ab Stufe 2« sowie »Gewährung nur an Mitarbeiter, die mindestens ein Jahr Betriebszugehörigkeit aufweisen« u.a.m. konkretisiert werden. Regeln können dabei auch Berechnungsvorschriften enthalten, die es beispielsweise erlauben, aus einem Gesamtarbeitswert die Höhe der Grundvergütung oder aus einem Zielerreichungsgrad die Zahl der zu gewährenden Aktienoptionen zu berechnen. Teils kann auch die Einhaltung von Budgetierungsvorgaben über Regeln abgebildet werden. Entsprechend könnte die automatisierte Vergabe der Prämie davon abhängig gemacht werden, ob die Budgetierungseinheit des zu verplanenden Mitarbeiters grundsätzlich ein Prämienbudget aufweist und dieses derzeit auch noch nicht ausgeschöpft ist. Auf diese Weise können beliebige Daten aus Stellenbewertung, Leistungsbeurteilung, Budgetierung und Vergütungsvergleichstudien zur Formulierung von Regeln verwendet werden. Einzelne Regeln können dabei mit unter283

22

Vergütungsmanagementsysteme schiedlichen Operatoren verknüpft werden, entsprechend sind neben additiven auch alternative Regeln zur Gewährung und Höhe einer Vergütungsart möglich. In der Folge ermöglichen regelbasierte Ansätze die Abbildung beliebig komplexer Vergütungsstrategien und -konzeptionen. Der zentrale Vorteil liegt darin, dass Regeln einmal generell aufgestellt und dann auf alle Mitarbeiter automatisiert angewendet werden können. Insbesondere bei Verletzung des Budgets sind entsprechende automatisierte Hinweise an menschliche Anwender möglich, um eine »manuelle« Nachplanung im Sinne einer Anpassung von Budgets und/ oder Regeln zu veranlassen. Die Planungszeiträume einer Vergütungsplanung sowie deren Rasterung können meist individuell bestimmt werden. Aufgrund inhaltlicher Abhängigkeiten zu üblichen Auszahlungsperioden der Personalabrechnung (vgl. Kap. 13) dürfte häufig der Zeitraum eines Jahres in einem Monatsraster geplant werden. Als Ergebnis der mit der Planungskomponente durchgeführten Vergütungsplanung zeigen Vergütungspläne für einen festgelegten Planungszeitraum in einer festgelegten Zeitrasterung auf, welchem Vergütungsempfänger welche Vergütungsarten in welchem Umfang zugesprochen werden. Eine Variante der Vergütungsplanung besteht in einigen Systemen darin, dass man Vergütungsarten und -umfang nicht en detail vorgibt, sondern den Mitarbeitern Wahlmöglichkeiten belässt, die sie periodisch ausüben können, um sich einen individuellen »Vergütungsmix« zusammenzustellen (»Cafeteria-Ansatz«). Auch diese Variante kann Regeln verwenden, um die Planung zu unterstützen. Speziell werden Regeln verwendet, um aus Personal-, Leistungs-, Stellenbewertungs-, Markt- und Budgetdaten die Vergütungsansprüche einzelner Vergütungsempfänger zu bestimmen. Um allerdings die erwünschten Wahlmöglichkeiten zuzulassen, werden hier nicht Einzelansprüche bezüglich jeder Vergütungsart geplant, sondern Gesamtvergütungsansprüche, die etwa mittels eines Punktesystems abgebildet werden. Eine Umrechnungstabelle zeigt dann auf, wie die erzielten Vergütungspunkte in konkrete Vergütungsarten umgesetzt werden können, also etwa wie viele Punkte für 500,00 € Bruttogrundvergütung oder für einen Firmenwagen einer gewissen Kategorie aufgewendet werden müssen. I.d.R. können erworbene Vergütungspunkte von den Mitarbeitern allerdings nicht beliebig, sondern nur nach gewissen vorzugebenden Wahlmöglichkeiten auf einzelne Vergütungsarten umgelegt werden. Etwa ist es üblich einen gewissen Minimalbetrag als monetäre Vergütung oder einen Maximalbetrag für die Gewährung von Aktien vorzusehen. Grundsätzlich ist

284

22.1 Architektur und Funktionalität von Vergütungsmanagementsystemen auch die Festlegung von Art und Umfang der Wahlmöglichkeiten im Rahmen der vom System angebotenen Vergütungsarten frei. Entsprechend können auch hier unterschiedliche Varianten eines Cafeteria-Ansatzes realisiert werden (vgl. Ala & Brunaczki 2003, 63). Durch einen Cafeteria-Ansatz erhält die Vergütungsplanung einen teilweise stochastischen Charakter, da die faktische Ausübung von Wahlrechten durch die Mitarbeiter zunächst offen bleiben muss. Die Durchführung der Vergütungsplanung kann dabei zentral durch eine Fachabteilung »Personal« erfolgen. Teils ist aber auch eine Dezentralisierung der Vergütungsplanung möglich, bei der personalverantwortliche Führungskräfte im Sinne eines Manager Self Service die Vergütungsplanung für ihren Verantwortungsbereich übernehmen (vgl. Kap. 2).

22.1.6

Verwaltungskomponente Zur Realisierung geplanter Vergütungen existiert meist eine Verwaltungskomponente, die die faktischen Zuweisungen von Vergütungsbestandteilen im Zeitablauf administriert. Bezogen auf monetäre Vergütungsarten wie Grundentgelt, Leistungsprämien etc. beschränkt sich die Administration allerdings meist in der Weitergabe entsprechender Daten an ein Personalabrechnungssystem und die Aktivierung korrespondierender Abrechnungsund Auszahlungsfunktionalitäten (vgl. Kap. 13). Umfassendere Verwaltungsfunktionen finden sich dagegen für nicht-monetäre Komponenten wie Firmenwagen oder Mitarbeiterbeteiligungen, die in Abrechnungssystemen meist nicht berücksichtigt sind. Entsprechend kann die Zuweisung von Vergütungsarten zu Vergütungsempfängern im System administriert werden. Oft weisen Vergütungsmanagementsysteme dabei gewisse Schwerpunkte bezüglich der administrierbaren Vergütungsarten auf. So können Teile der Systeme dezidiert Konfigurations- und Leasingprozesse von Firmenwagen unterstützen. Ebenso finden sich Systeme, die spezielle Formen der Beteiligung wie etwa die Ausgabe von Belegschaftsaktien administrieren können. Einmalig wie periodisch gewährte Vergütungsarten werden dabei in der Vergütungsdatei protokolliert und auf Zulässigkeit, Einhaltung und Übereinstimmung mit möglichen Budgetvorgaben überprüft. Zur Administration eines Cafeteria-Ansatzes werden oft webbasierte Vergütungsmanagementsysteme präsentiert, die den Mitarbeitern zunächst personalisiert das spezifische Cafeteria-System mit seinen Optionen präsentieren und vorstellen (vgl. Cambern 285

22

Vergütungsmanagementsysteme 2006). Im Sinne eines Self Service kann dabei häufig die konkrete Auswahl des Vergütungsmix direkt durch den jeweiligen Mitarbeiter erfolgen. Dabei bietet das System individualisiert nur solche Wahlmöglichkeiten an, die dem entsprechenden Mitarbeiter zustehen, und prüft, ob die gewählte Zusammenstellung dem grundsätzlichen Vergütungsanspruch des jeweiligen Mitarbeiters sowie ggf. dem Budget der jeweiligen Budgetierungseinheit entspricht.

22.1.7

Analysekomponente Eine Analysekomponente ermöglicht die Erstellung vorgefertigter und individueller Abfragen und Berichte. Grundsätzlich dient sie damit zum einen der Unterstützung der Vergütungsplanung als auch einem umfassenden Vergütungscontrolling. So betreffen zentrale vorgefertigte Abfragen die Vergütungsstrukturanalyse. Hier kann die Vergütungsstruktur oft nach zahlreichen Kriterien wie Mitarbeiter, Standort, Funktionsbereichen vergleichend analysiert werden. Spezielle Analysen betreffen die Vergütungsgerechtigkeit, die teils auch vor dem Hintergrund von Gleichbehandlung und Vergütungsgerechtigkeit die Vergütungsstruktur nach soziodemographischen Mitarbeitermerkmalen vergleicht. Da Vergütungsdaten i.d.R. historisiert werden, sind auch Entwicklungen der Vergütungsstrukturen im Zeitablauf darstellbar. Weitere häufige Abfragen bilden etwa Marktkonformitätsanalysen, die die Vergütung einzelner Mitarbeiter oder Mitarbeitersegmente systematisch mit den am Markt gewährten Vergütungen vergleichen. Analog ermöglichen vorgefertigte Budgetkonformitätsanalysen, ob die für eine Budgetierungseinheit vorgegebenen Vergütungsbudgets eingehalten werden. Zusätzlich sind individuell erstellte Abfragen über alle Daten der Datenhaltungskomponente möglich. Teilweise bieten verfügbare Systeme ein integriertes OLAP im Sinne einer multidimensionalen und (dis-)aggregierenden Datenanalyse an (vgl. Kap. 11). Teilweise werden im Rahmen von Self Service-Konzepten auch Mitarbeitern Abfragen eigener Daten, wie etwa die eigene Vergütungshistorie, zugestanden.

22.2

Anwendung von Vergütungsmanagementsystemen Vergütungsmanagementsysteme zählen zu den Anwendungssystemen mit strategischem Potenzial im Personalmanagement. Die grundsätzliche Offenheit für unterschiedliche monetäre wie nicht-monetäre Vergütungsarten erlaubt es dabei, eine individu-

286

22.2 Anwendung von Vergütungsmanagementsystemen elle, auf die Unternehmens- sowie mögliche Funktionalstrategien ausgerichtete Vergütungsstrategie zu entwickeln bzw. eine bereits vorhandene Vergütungsstrategie umzusetzen. Um die Potenziale von Vergütungsmanagementsystemen umfassend zu nutzen, ist entsprechend eine adäquate, den Wettbewerb um Mitarbeiter differenzierende Vergütungsstrategie notwendig (vgl. Kurlander 2001). Dabei unterstützen einmal implementierte Vergütungsmanagementsysteme die Strategiefindung und -änderung auch durch die Möglichkeiten über die Analysekomponente entscheidungsunterstützende Informationen zu generieren. Eher operative Potenziale von Vergütungsmanagementsystemen liegen erneut in der Systematisierung und Rationalisierung von Vergütungsplanung wie -administration. Insbesondere durch Self Service-Konzepte können zentrale Aufgaben erneut ausgelagert werden. Die Anwendung von Vergütungsmanagementsystemen steht dabei in mittelbarer Konkurrenz zur Anwendung von Personalkostenplanungssystemen (vgl. Kap. 10), die ähnliche Aufgaben bearbeiten. Während Kostenplanungssysteme allerdings Vergütungsstrukturen als weitgehend konstant ansehen und auf der Basis absehbarer Änderungen im Stellen- bzw. Personalbestand auf die Planung und Steuerung direkter Personalkosten ausgerichtet sind, zielen Vergütungsmanagementsysteme gerade auf die strategiekonforme Gestaltung von Vergütungsstrukturen und betonen damit die Gestaltungsaufgabe. Insofern haben Vergütungsmanagementsysteme als die funktional breitere und gestaltungsorientiertere Kategorie zu gelten, die zentrale Aspekte einer kurz- bis mittelfristigen Personalkostenplanung und -steuerung im Sinne eines Kuppelproduktes bereitstellt. Obwohl teils explizit oder implizit auf das Segment außertariflicher Mitarbeiter ausgerichtet, existieren Möglichkeiten, ein Vergütungsmanagement auf größere Teile der tariflichen Mitarbeiter auszudehnen und entsprechende Vergütungsbestandteile – wenn nötig zusätzlich zur tariflichvertraglich determinierten Vergütung – zu gewähren. Verbreitung

Derzeit sind keine empirischen Studien zur Verbreitung von Vergütungsmanagementsystemen bekannt.

287

23

Enterprise Resource Planning-Systeme Enterprise Resource Planning-Systeme (ERP-Systeme, Unternehmenssysteme, »Enterprise [Wide] Systems [ES]«, »Business Systems«, »Enterprise Application [Packages]«) sind daten- und funktionsintegrierte unternehmensweite Anwendungen zur Unterstützung zentraler Unternehmensfunktionen, u.a. des Beschaffungs-, Produktions-, Finanz-, Vertriebs- und Personalmanagements.

Architektur und Funktionalität von ERP-Systemen Ein konventionelles ERP-System verfügt idealtypisch zunächst über eine Applikationskomponente, eine Datenhaltungskomponente, eine Workflowkomponente sowie eine Implementationsund Administrationskomponente (vgl. Abb. 23.1). Enterprise Resource Planning-System Anwenderschnittstelle Workflowkomponente

Workflow-Engine Applikationskomponente ...1 ...3

...2 ...n

FI1 FI3

FI2 FIn

HR1 HR3

HR2 HRn

SD1 SD3

SD2 SDn

...1 ...3

...2 ...n

Datenbankkomponente Datei1

Datei2

Datei3

Administrationskomponente

Workflow-Manager Implementationskomponente

23.1

Datein

Abb. 23.1: Idealtypische Architektur von ERP-Systemen Die Applikationskomponente stellt eine größere Anzahl integrierter betriebswirtschaftlicher Module aus unterschiedlichen Funktionsbereichen, darunter i.d.R. auch das Personalmanagement, zur 289

23

Enterprise Resource Planning-Systeme Verfügung. Eine (häufig externalisierte) Datenkomponente hält in einem umfassenden Datenmodell Daten für sämtliche Anwendungen des ERP-Systems vor. Die Workflowkomponente erlaubt (in Interaktion mit der Applikationskomponente) die Spezifikation und Steuerung von Geschäftsprozessen. Die Implementationskomponente bietet Werkzeuge zur individuellen Anpassung der Funktionen (Applikationskomponente), Daten (Datenkomponente) und Prozesse (Workflowkomponente). Eine Administrationskomponente ermöglicht die Verwaltung des Systems und seiner Anwendung. Teilweise existieren ERP-Systeme mit weiteren, hier nicht angesprochenen Komponenten, wie etwa integrierte Office- und Projektmanagement-Funktionen (vgl. Klaus et al. 2000).

Verteilte Systeme

Während frühe ERP-Systeme für Mainframe-Computer konzipiert waren, basieren spätere Systeme regelmäßig auf dem Client-Server-Modell, bei dem die angeführten Komponenten auf mehrere Rechner verteilt werden. Sehr häufig ist hier eine dreistufige Client-Server-Architektur in Anwendung, bei der ein Datenbankserver (Datenkomponente) und ein Applikationsserver (Applikations-, Implementations-, Workflow- und Administrationskomponente) zahlreiche Arbeitsplatz-Clients (GUI) bedienen. Mit der Notwendigkeit einer umfassenden Unterstützung des »e-Business«, ist man zunehmend auf Webserver und Webclients übergegangen (vgl. Gronau 2004, 16ff. und Kap. 28).

Branchenversionen

Aufgrund unterschiedlicher funktionaler Anforderungen werden umfassende ERP-Systeme häufig in zahlreichen unterschiedlichen Branchenversionen angeboten (n > 20). Neben der Berücksichtigung gängiger privatwirtschaftlicher Wirtschaftszweige werden auch Varianten für öffentliche Betriebe wie Krankenhäuser, Universitäten oder Kommunen angeboten. Speziell die Applikationsund die Datenkomponente sind dann bereits auf die Spezifika der entsprechenden Branche ausgerichtet. Entsprechend mindern solche Branchenversionen den individuellen Implementierungsaufwand.

Landesversionen

Im Gefolge der Globalisierung ist die Anwendung von ERP-Systemen in unterschiedlichen Ländern inzwischen eine unabdingbare Voraussetzung. Regelmäßig wird die Applikationskomponente von auf Großunternehmen ausgerichteten ERP-Systemen daher in zahlreichen Landesversionen angeboten (n > 30). Eine Landesversion bedingt i.d.R. zunächst eine korrespondierende Sprachversion des Systems. Allerdings wird für manche Länder oft lediglich die englische Sprachversion angeboten. Neben der

290

23.1 Architektur und Funktionalität von ERP-Systemen Mehrsprachigkeit ist für internationale Systeme weiter eine Mehrformatsfähigkeit erforderlich. Wert- und Mengenangaben des Systems müssen dabei in national unterschiedlichen Einheiten angegeben werden können. Beispielsweise ist für eine internationale Personalkostenplanung i.d.R. eine Mehrwährungsfähigkeit notwendig. Einzelplanungen an verschiedenen nationalen Standorten können dann in der jeweiligen Landeswährung vorgenommen werden. Eine Zusammenführung der Einzelplanungen kann dann in einer frei wählbaren Referenzwährung vorgenommen werden, wobei teilweise auf tagesspezifische Wechselkurse zurückgegriffen wird. Weiter sind aber auch funktionale Unterschiede in einzelnen Ländern abzubilden. Gerade administrative Funktionen wie die Personalabrechnung weisen aufgrund national unterschiedlicher rechtlicher und tariflicher Vorgaben oft stark abweichende Anforderungen auf. Entsprechend bedingt die Abbildung solcher nationalen Spezifika oft eine erhebliche Ausdehnung anzubietender Funktionalitäten. Mandanten

ERP-Systeme sind i.d.R. mandantenfähig. Mandantenfähigkeit impliziert, dass mittels desselben ERP-Systems mehrere Organisationen bzw. Organisationseinheiten parallel bearbeitet werden können, ohne dass die jeweils bearbeiteten Einheiten gegenseitig Einblicke in Daten, Ergebnisse etc. haben. Mandantenfähigkeit verhindert, dass bei der Notwendigkeit einer physisch getrennten Abrechung verschiedener Organisationen bzw. Organisationseinheiten Systemlizenzen mehrfach vergeben werden und Systeminstallationen mehrfach durchgeführt werden müssen.

23.1.1

Datenhaltungskomponente ERP-Systeme weisen im Auslieferungsumfang zunächst umfangreiche Referenzdatenmodelle auf, die unmodifiziert übernommen oder im Rahmen der Implementation auf betriebliche Belange angepasst werden können bzw. müssen, um die eigentliche Datenhaltungskomponente – häufig in Form eines externen Datenbanksystems (vgl. Kap. 4) – zu realisieren.

Datenumfang und -inhalte

Die meist erhebliche funktionale Breite von ERP-Systemen bedingt dabei einen oft ebenso beträchtlichen Umfang vorzuhaltender Daten. Das i.d.R. relationale Gesamtdatenmodell eines ERPSystems kann dabei aus mehreren zehntausend Einzeltabellen bestehen. Entsprechend erreichen auch die für das Personalmanagement relevanten Daten erhebliche Umfänge. Inhaltlich beziehen sich diese Daten dabei auf eine Vielzahl von Einzelsachverhalten. 291

23

Enterprise Resource Planning-Systeme

Abgeltung Urlaubsanspruch Abrechnungsergebnisse Abrechnungsstatus Abwesenheitsereignis Aktienerwerbspläne Altersteilzeit Andere/frühere Arbeitgeber Anschriften Ansprüche BAV Arbeitgeberleistung Arbeitgebernummer Arbeits-/Entgeltbestätigung Arbeitsunfälle Aufenthaltsstatus Ausbildung Ausbildungsbescheinigung Auslandsentsendung Bahnpräferenz Bankverbindung Basisbezüge Behinderung Belehrungen Berufsgenossenschaft Bescheinigungen BA Bescheinigungen Kommunen Bescheinigungen SV-Träger Betriebliche Funktion Betriebsräte Betriebsrenten Beurteilungen Darlehen Daten zur Person DEÜV Dienstalter Dienstwohnung Direktversicherung

Dokumente ESS-Einstellungen Extern Gehaltsbestandteile Familienzuschläge Familie/Bezugsperson Festsetzung Kindergeld Festzusagen BAV Firmenwagen Flugpräferenz Freistellungsbescheinigung Gehaltsumwandlung Gewinnbeteiligung Hotelpräferenz Info Familienangehörige Kindergeld Kommunikation Kostenverteilung Krankenscheine Krankenversicherungspläne Kreditpläne Kundenprogramm Kündigung Kurzarbeit/Winterausfall Leihgaben Mietwagenpräferenz Mitarbeiterbeteiligung Mitgliedschaften Mitteilungen Mutterschutz/Erziehungsurlaub Nebentätigkeit Pendlerpauschale Pensionspläne Personalunterkunft Pfändung Planung Personalkosten

Qualifikationen Rehabilitanden Reiseprivilegien Reiseprofil Rentenauskunft Rentenbasisbezüge BAV Schuldverschreibung Sollarbeitszeit Sonderregelungen Sonstige Pläne Sozialleistungen BAV Sozialversicherung Statistik Status Auslandsaufenthalt Steuerdaten Störfall SV-Zusatzversicherung Teilzeitarbeit/Elternzeit Terminverfolgung Urlaubsanspruch Verdienstsicherung Vergütungsanpassung Vergütungsbestandteil Vermögensbildung Versicherungen Versorgungsbezug Vertragsbestandteile Vollmachten Vorsorgepläne Wehr-/Zivildienst Werksärztlicher Dienst Wiederkehrende Be-/ Abzüge Zeitangaben/Dienstzeit Zusatzversorgung

Abb. 23.2: Ausgewählte Referenzdatensegmente (Quelle: SAP™ R/3 »Enterprise«) Abb. 23.2 zeigt lediglich eine Auswahl von Personaldatensegmenten, die im Rahmen eines umfassenden ERP-Systems zu pfle292

23.1 Architektur und Funktionalität von ERP-Systemen gen sind, wenngleich nicht jedes Datensegment für jeden Mitarbeiter relevant ist. Praktische Versuche der Dateneingabe ergeben Werte von bis zu einer Stunde für das Einpflegen der Stammdaten eines einzelnen Mitarbeiters durch eine geübte Person (vgl. Strohmeier 1996). Die den Personalbereich betreffenden Daten sind damit in ein komplexes bereichsübergreifendes Gesamtdatenmodell eingebunden, das Daten unterschiedlicher betrieblicher Funktionsbereiche integriert. Abb. 23.3 deutet diese bereichsübergreifende Datenintegration beispielhaft in einem Entity Relationship-Diagramm an.

Datenintegration

Bereich »Personal«

Bereich »Organisation«

Mitarbeiter

ID

Name

Planstelle

besetzt

...

Bereich »Accounting«

ID

Bezeich.

zugeordnet

...

Kostenstelle

ID

No.

...

Abb. 23.3: Bereichsübergreifende Datenintegration Aufgrund dieser Interdependenzen mit dem Gesamtdatenmodell können Änderungen am ausgelieferten Referenzdatenmodell im Rahmen der Implementierung nicht vollständig autonom vorgenommen werden, sondern bedürfen der Abstimmung mit anderen Bereichen. Datentemporalisierung

Zahlreiche Personaldaten sind ständigen Veränderungen im Zeitablauf unterworfen. Mitarbeiter nehmen im Zeitablauf unterschiedliche Stellen ein, beziehen ein verändertes Gehalt, ändern ihre Bankverbindung etc. Statt jeweils »nur« die aktuell gültigen Daten bezüglich dieser Attribute zu halten, werden Daten i.d.R. temporalisiert. Eine Temporalisierung findet häufig über die Vergabe von Gültigkeitszeiträumen statt, die über einen festen Anfangszeitpunkt und – falls absehbar – auch über einen festen Endzeitpunkt verfügen. So wird es zunächst möglich, Daten zu historisieren. Bei einer Veränderung, etwa dem Eintritt in eine neue Gehaltsgruppe, werden Daten zur alten Gehaltsgruppe nicht einfach gelöscht, sondern mit einem Gültigkeitsendzeitpunkt versehen. Zusätzlich wird ein neuer Datensatz mit der aktuellen Gehaltsgruppe angelegt. Sind künftige Entwicklungen, 293

23

Enterprise Resource Planning-Systeme wie etwa der Übergang in eine neue Gehaltsgruppe in drei Monaten, bereits zum Voraus bekannt, können Daten auch futurisiert werden. Dann wird der aktuelle Datensatz mit einem künftigen Gültigkeitsendzeitpunkt versehen und bereits im Voraus ein zusätzlicher Datensatz eingegeben, der erst in der Zukunft gültig sein wird. Entsprechend können neben einem aktuellen Datensatz einer Tabelle auch mehrere historisierte und/oder futurisierte Datensätze vorliegen (vgl. Abb. 23.4). ... Stelle1

Stelle2

Stelle4

Stelle3 Ehepartner1

Adresse1

Adresse2 Firmenwagen1

Gehalt1

Gehalt2

Eintritt

Firmenwagen2 Gehalt3 heute

Gehalt4 t

historisierte Datensätze aktuelle Datensätze futurisierte Datensätze

Abb. 23.4: Datentemporalisierung Eine Temporalisierung von Daten führt auf diese Weise zu teils erheblichen Ausdehnungen der Datenvolumina. Allerdings wird es so möglich, Auswertungen über die Gegenwart mit vergangenheits- und/oder zukunftsbezogenen Auswertungen anzureichern. Neben Informationen über das aktuelle Ist-Gehalt können so auch Informationen über die Gehaltsentwicklung in der Vergangenheit sowie über die künftig geplante Gehaltsentwicklung bereitgestellt werden. Ebenso wird es möglich, Daten nach Zeitpunkten oder Zeiträumen auszuwerten. Beispielsweise kann so ermittelt werden, wie viele Mitarbeiter eine Abteilung zu Jahresbeginn oder -ende umfasst (zeitpunktbezogene Auswertung) und wie viele Mitarbeiter diese Abteilung im ersten Halbjahr aufwies (zeitraumbezogene Auswertung).

294

23.1 Architektur und Funktionalität von ERP-Systemen

23.1.2

Applikationskomponente Grundsätzlich existiert für die Applikationskomponente von ERPSystemen kein feststehender Kanon an Funktionalitäten bzw. funktionalen Modulen. Häufig unterstützte Unternehmensbereiche sind neben dem Personalbereich der Beschaffungs-, Produktions-, Finanz-, Rechnungswesen- und Vertriebsbereich. Anders als der Begriff »Enterprise Resource Planning« suggeriert, handelt es sich bei ERP-Systemen allerdings generell eher um transaktionsorientierte d.h. administrative, also um planungsorientierte Systeme (vgl. Klaus et al. 2000, 143).

Personalmanagementfunktionen

Auch bezogen auf die personalwirtschaftlichen Funktionen von ERP-Systemen gilt, dass eine gewisse Varianz existiert. Nachweisbare personalwirtschaftliche Funktionen von ERP-Systemen beziehen sich etwa auf ƒ die Personalstammdatenhaltung und die Personalberichterstattung (vgl. Kap. 4), ƒ die Personaleinsatzplanung (vgl. Kap. 8), ƒ die Personalentwicklungsplanung (vgl. Kap. 9), ƒ die Personalkostenplanung (vgl. Kap. 10), ƒ die Personalabrechnung (vgl. Kap. 13), ƒ das Arbeitszeitmanagement (vgl. Kap. 14), ƒ das Beschaffungsmanagement (vgl. Kap. 16), ƒ das Seminarmanagement (vgl. Kap. 20), ƒ die Personalbeurteilung (vgl. Kap. 21) und ƒ das Vergütungsmanagement (vgl. Kap. 22). Die von ERP-Systemen bereitgestellten Funktionalitäten entsprechen – zumindest dem Grundsatz nach – den Funktionalitäten der Einzelsysteme bzw. Module. Beispielsweise vollzieht ein Personalabrechnungsmodul eines ERP-Systems notwendigerweise die Schritte der Brutto- und Nettoabrechnung und unterstützt das Melde- und Bescheinigungswesen (vgl. Kap. 13). Aus diesem Grund wird hier keine redundante Darstellung der jeweiligen Detailfunktionalitäten vorgenommen. Wesentlich ist, dass einzelne Module funktional integriert sind, d.h. gemeinsam eingesetzt werden können. Beispielsweise können Beurteilungsergebnisse direkt im Vergütungsmanagement umgesetzt werden. Obwohl solche personalwirtschaftliche Funktionalitäten zunehmend zum »Standardfunktionsumfang« von ERP-Systemen zählen, existieren – insbesondere für das Segment kleiner und mittlerer Unternehmen – allerdings auch ERP-Systeme, die gar keine personalwirtschaftlichen Funktionalitäten anbieten (vgl. etwa Andresen et al. 2005). Aufgrund der engen inhaltlichen Interdependenzen 295

23

Enterprise Resource Planning-Systeme werden teils zusätzlich auch Module zum Organisationsmanagement, die die Aufbauorganisation administrieren, dem personalwirtschaftlichen Bereich zugerechnet.

Architekturvarianten

Obwohl diese Funktionen auch im Rahmen konventioneller ERPArchitekturen herstellerseitig häufig als »Module« bezeichnet werden, weisen die Applikationskomponenten faktisch nur teilweise eine modulare Architektur auf. Häufig liegen hoch integrierte monolithische Architekturen vor, bei der einzelne Funktionsbausteine im physischen Sinne nicht von einander getrennt sind oder getrennt werden können (vgl. Kap. 1). Dies hat etwa bei einem selektiven Bedarf an Funktionalitäten zur Folge, dass anwendende Unternehmen zwar lediglich selektiven Zugang zu den Funktionen der Applikationskomponente erhalten, die sie faktisch benötigt (und bezahlt), physisch aber stets die komplette Applikationskomponente auf dem entsprechenden Server installiert werden muss. Gleichermaßen ist bei der Notwendigkeit, einzelne Funktionalitäten zu erneuern (»Update«), stets die gesamte Anwendung zu wechseln.

23.1.3

Workflowkomponente ERP-Systeme folgen i.d.R. einer prozessorientierten Perspektive des Unternehmensgeschehens (vgl. Klaus et al. 2000, 143). (Geschäfts-)Prozesse sind dabei definierte Folgen von Aktivitäten zur Erfüllung einer betrieblichen Aufgabe (vgl. Koch 2003). Zur Umsetzung dieser prozessorientierten Perspektive verfügen ERP-Systeme i.d.R. über eine Workflowkomponente. Ein Workflowmanager ermöglicht hierbei die Spezifikation und Administration von Prozessen, während eine Workflowengine die konkrete Ablaufsteuerung übernimmt.

Prozessspezifikation

296

Die Spezifikation von Prozessen stellt zunächst eine Implementierungsaufgabe. Sie ist daher i.d.R. vor der eigentlichen Anwendung des ERP-Systems und in Interaktion mit weiteren Implementierungsaufgaben abzuarbeiten. Zur Spezifikation individueller Prozesse verfügen Workflowkomponenten zunächst über i.d.R. grafisch orientierte Modellierungswerkzeuge. Aufbauend auf einer spezifischen Notation von Geschäftsprozessen – etwa die Business Process Modeling Notation (BPMN) oder ereignisgesteuerten Prozessketten (EPK) – lassen sich Prozesse in semi-formaler grafischer Weise abbilden (vgl. auch Kap. 24). Abb. 23.5 zeigt die ereignisorientierte Prozesskette eines Personalbeschaffungsprozesses. Dabei werden auf operativer Ebene einzelne Aktivitäten in ihrem geplanten Ablauf detailliert beschrieben. Pro-

23.1 Architektur und Funktionalität von ERP-Systemen zesse verfügen entsprechend über einen definierten Anfang (»Auslöseereignis«), einen definierten Ablauf und ein definiertes Ende (»Ergebnis«). Weiter sind auch die verantwortlichen maschinellen und/oder menschlichen Aufgabenträger festgelegt, die für die Bearbeitung des Prozesses oder einzelner Prozessschritte zuständig sind. Maschinelle Aufgabenträger sind hierbei konkret spezifizierte Teile der Applikationskomponente, menschliche Aufgabenträger entsprechend spezifizierte Anwender des ERPSystems. neue Bewerbung angelegt

š Eingangsbestätigung erstellen

Vorselektion Bewerber akzeptiert

Eingangsbestätigung erstellt

Ablehnungsschreiben erstellen

Vorbereitung Vorstellung

Eingangsbestätigung versenden

Ablehnungsschreiben erstellt

Vorstellung vorbereitet

Eingangsbestätigung versandt

Ablehnungsschreiben versenden

Einladungsschreiben versenden

Ablehnungsschreiben versandt

Einladungsschreiben versandt

Bewerber abgelehnt

XOR

Abb. 23.5: Ausschnitt eines Referenzprozesses in der Personalbeschaffung Prozesse können dabei personalwirtschaftsintern, bereichs- oder sogar unternehmensübergreifend ablaufen. Einzelne Prozesse können auch miteinander gekoppelt werden. Das Ergebnis eines Prozess1 bildet dann das Auslöseereignis eines Prozess2. Um die Prozessspezifikation zu vereinfachen und zu beschleunigen, verfügen größere ERP-Systeme regelmäßig über zahlreiche (n > 1.000) Referenzprozesse, darunter auch etliche personalwirtschaftliche (vgl. Shebab et al. 2004, 362). Solche Referenzprozesse werden als »Best Practice« zur unmittelbaren Anwendung empfohlen (vgl. Kumar & van Hillergersberg 2000). Entsprechend 297

23

Enterprise Resource Planning-Systeme existiert im Rahmen der Implementation die Möglichkeit, Referenzprozesse unverändert zu übernehmen, Referenzprozesse auf individuelle Belange anzupassen, oder neue Prozesse zu entwerfen. Sollen individualisierte Prozesse allerdings von Funktionalitäten der Applikationskomponente unterstützt werden, ist man stets an deren inhärente Anwendungs- und Ablauflogik der entsprechenden Teile der Applikationskomponente gebunden.

Prozesssteuerung

Die Kernaufgabe der Workflowkomponente liegt in der Ablaufsteuerung der implementierten Prozesse mittels einer Workflowengine. Tritt ein Auslöseereignis ein, sorgt die Workflowengine automatisch für die Abarbeitung des damit angestoßenen Prozesses: Bei rein maschinellen Aufgabenträgern werden entsprechende Bearbeitungsroutinen angestoßen. Bei menschlichen Aufgabenträgern wird ein Workflow-Eingang erzeugt, der dem Bearbeiter eine anstehende Aufgabe anzeigt. Beim korrespondierenden Bearbeitungsvorgang stellt die Workflowkomponente dem Bearbeiter auch die zur Bearbeitung notwendigen Teile der Applikationskomponente – etwa diverse Eingabemasken und Auswertungen – zur Verfügung. Auch die anschließende automatisierte Weiterleitung von Teilergebnissen entlang der Prozesskette (»Routing«) wird von der Workflowengine übernommen. Generell wird so eine systemgesteuerte integrierte Bearbeitung personalwirtschaftlicher (wie sonstiger) Prozesse ermöglicht.

Prozessadministration

Die Prozessadministration erfolgt meist ebenfalls über die Workflowkomponente. Die Prozessadministration zielt im Wesentlichen auf die Prozessüberwachung und kontinuierliche Prozessoptimierung. Die Prozessüberwachung (»Monitoring«) dient der Sicherstellung der systematischen, pünktlichen Prozessbearbeitung. Entsprechend können Stockungen im Prozessablauf lokalisiert, Prozesskosten und -durchlaufzeiten analysiert werden u.a.m. I.d.R. existiert zur Problembehebung auch ein Eskalationsmanagement, das – selbst als Prozess organisiert – die Lösung auftretender Probleme nach ihrer Schwere verschiedenen Bearbeitern zuweist. Die kontinuierliche Prozessoptimierung dient der Senkung von Prozesskosten und Durchlaufzeiten, etwa durch Eliminierung von Prozess(schritt)en, die sich als nicht erforderlich herausstellen u.a.m. (vgl. Koch 2003).

23.1.4

Implementationskomponente Als »Standard«-Software besteht bei ERP-Systemen sowohl die Möglichkeit, als auch die Notwendigkeit einer weit reichenden unternehmensindividuellen Anpassung (»Customizing«). Aufgrund

298

23.1 Architektur und Funktionalität von ERP-Systemen des erheblichen quantitativen Umfangs und der erheblichen qualitativen Komplexität dieser Tätigkeiten, wird gewöhnlich eine eigene Komponente zur Unterstützung der Implementation angeboten. Bereiche

Die Implementation bezieht sich dabei auf ƒ die Workflowkomponente, ƒ die Datenhaltungskomponente und ƒ die Applikationskomponente. Workflows können unter Rückgriff auf grafische Modellierungswerkzeuge in der beschriebenen Weise angepasst werden. Datenstrukturen können im Rahmen des relationalen Datenbankmodells (vgl. Kap. 4) durch die Modifikation von Datenfeldern, segmenten und -tabellen verändert werden. Die Applikationen können durch Parametrisierung und Modifikation geändert werden. Im Rahmen der Parametrisierung werden die gewünschten Funktionen, Rechenverfahren, Programme etc. durch das Setzen von Parametern konkretisiert, d.h. wählbare Parameter der Standardsoftware werden so eingestellt, dass das System den individuellen Bedürfnissen des Unternehmens entspricht. Deutlich weitergehende Anpassung ermöglicht die Modifikation. Zur Veränderung und Ergänzung von Funktionalitäten kann über – teilweise systemspezifische – Programmiersprachen der Quellcode modifiziert und ergänzt werden.

Methodik

Basierend auf Projektmanagement-Werkzeugen wird zur Implementierung oft eine systemspezifische Implementierungsmethodik vorgeschlagen und in Implementierungsleitfäden dokumentiert. Neben Anleitungen und Vorschlägen zur Vorgehensweise werden hier umfangreiche Möglichkeiten der Planung, Dokumentation und Überwachung einer arbeitsteiligen Implementierung angeboten. Vorgenommene Anpassungen werden dabei akribisch dokumentiert, so dass stets nachvollziehbar ist, wer wann welche Anpassung des Systems vorgenommen hat. Umfangreiche Testwerkzeuge, die die Lauffähigkeit und Fehlerfreiheit angepasster Systeme überprüfen, runden die Funktionalität ab (vgl. Klaus et al. 2000, 143).

23.1.5

Administrationskomponente Eine Administrationskomponente zielt auf die Verwaltung von ƒ Anwendern, ƒ Applikationen, ƒ Prozessen und ƒ Daten. 299

23

Enterprise Resource Planning-Systeme ERP-Systeme sind notwendigerweise Mehrbenutzersysteme, und in größeren Unternehmen finden sich auch für die Personalmanagementfunktionen oft sehr große Anwenderzahlen. Eine regelmäßig vorhandene Anwenderverwaltung zielt daher auf die effiziente Abbildung von Anwendern und deren Zugriffsrechten sowie die Überwachung von Anwenderaktivitäten im System. Oft werden hierbei Anwenderrollen verwendet. Anwenderrollen definieren die Aufgaben, Eigenschaften und vor allem die Zugriffsrechte eines Einzelanwenders, meist aber einer spezifischen homogenen Subgruppe von Anwendern (z.B. »Personalabrechner«, »Recruiter«, »Linienmanager« etc.) Letztere Variante verhindert, dass einzelnen Anwendern in aufwändiger Weise jeweils individuelle Rechte zugesprochen werden müssen. Dies erleichtert die Rechteverwaltung beim Anlegen von Anwenderrechten, aber insbesondere auch bei Änderungen, da dann nur die Rechte der Anwenderrolle geändert werden müssen. Einzelne Anwender können durchaus mehrere Rollen haben, die Gesamtheit der zu erfüllenden Rollen bestimmt dann die Zugriffsmöglichkeiten eines einzelnen Anwenders auf das ERP-System. Über Monitoringbzw. Trackingfunktionen wird es weiter möglich, Anwenderaktivitäten im System differenziert zu überwachen. Die Verwaltung der Applikationskomponente zielt insbesondere auf die Sicherstellung der notwendigen Release-Wechsel. Aufgrund häufiger gesetzlicher und tariflicher Veränderungen ist gerade das Personalmanagement oft ein aktiver Treiber von Release-Wechseln. Entsprechend sind notwendige Release-Wechsel zu antizipieren, durchzuführen und zu überprüfen. Wie bereits angedeutet, sind auch Daten und Workflows in entsprechender Weise zu administrieren.

23.2

Anwendung von ERP-Systemen Die Anwendung von ERP-Systemen im Personalmanagement verspricht zunächst eine umfassende Unterstützung zahlreicher verschiedener personalwirtschaftlicher Funktionen sowie deren interne und externe Abstimmung mit dem Unternehmensgeschehen. In beiden Architekturvarianten lassen sich die (reale oder virtuelle) Integration von Funktionen, Daten und Prozessen realisieren. Damit liefern ERP-Systeme eine technische Infrastruktur, um Personalfunktionen sowohl intern als auch extern mit weiteren Funktionen abzustimmen. Intern sind beispielsweise Arbeitszeitmanagement und Personaleinsatzplanung aufeinander abstimmbar, die Personaleinsatzplanung kann so AnwesenheitsSoll-Vorgaben für das Arbeitszeitmanagement liefern. Umgekehrt

300

23.2 Anwendung von ERP-Systemen bilden die Ist-Anwesenheitsdaten des Arbeitszeitmanagements Kontrollinformationen zur Planeinhaltung. Ebenso sind personalwirtschaftliche Funktionen mit weiteren Unternehmensfunktionen abgestimmt. Bspw. stehen Daten einer Personalkostenplanung unmittelbar zur weiteren Verwendung im Rahmen einer Gesamtkostenplanung bereit. Diese integrierte Anwendung entspricht insofern konzeptionellen Forderungen nach einer doppelten (internen und externen) Integration des Personalmanagements (vgl. Strohmeier & Kabst 2007). Vor dem Hintergrund von Datenschutz und betrieblicher Mitbestimmung (vgl. Kap. 3) wird diese Integration von Personalsystemen in unternehmensweite Anwendungen aber auch kritisch gesehen. Teilweise werden daher für Personalbereich und »Rest-Unternehmen« auch bewusst nicht-kompatible Systeme eingesetzt, um gemeinsame Auswertungen von Personal- und Unternehmensdaten sowie Zugriffe von außerhalb des Personalbereichs bereits auf grundsätzlicher Ebene auszuschließen. Notorisch sind allerdings Aufwand, Dauer, Komplexität und Kosten der vor jeder Anwendung notwendigen Implementation von ERP-Systemen. Trotz anders lautender Versprechungen von Beratern und Anbietern kann die Implementation zwischen zweiund fünf Jahren in Anspruch nehmen und das drei- bis siebenfache der reinen Softwarekosten betragen (vgl. Shebab et al. 2004, 367). Je nach System sind vorgenommene Individualeinstellungen auch bei jedem Upgrade des Systems jeweils neu vorzunehmen. Angesichts der sich oft rasch ändernden Anforderungen an das Personalmanagement und der daraus resultierende UpgradeHäufigkeit bedeutet dies faktisch eine Vervielfachung des Aufwands. Vor dem Hintergrund dieser Problemlage entscheiden sich viele Unternehmen für die Implementierung der vom Hersteller vorgegebenen »Standardinstallation«, d.h. Referenzprozesse, Referenzdaten und Applikationen werden (weitgehend) unverändert übernommen. Damit ist eine individuelle Anpassung von ERP-Systemen zwar technisch möglich, aber ökonomisch oft nicht ratsam, was einem kleinen Implementationsparadox gleich kommt. Verbreitung

Es sind derzeit keine empirischen Studien zur Verbreitung von ERP-Systemen im Personalmanagement bekannt. Gleichwohl ist mit der generell weiten Verbreitung von ERP-Systemen davon auszugehen, dass ERP-Systeme auch im Personalmanagement eine erhebliche Verbreitung erfahren haben und eine der zentralen Systemkategorien darstellen. Mehrere zentrale Anbieter von (monolithischen) ERP-Systemen bereiten derzeit den Übergang zu 301

23

Enterprise Resource Planning-Systeme serviceorientierten Architekturen (vgl. Kap. 1) und damit den Abschied von großen monolithischen Unternehmenssystemen vor.

302

Teil D Integrations- und Präsentationssysteme

24

Business Process Management-Systeme Business Process Management (BPM)-Systeme (Geschäftsprozessmanagementsysteme, Workflow[management]systeme [WFMS]) sind Anwendungen zur Gestaltung, Ausführung und Steuerung von Geschäftsprozessen über verschiedene Anwendungssysteme und Anwender hinweg.

24.1

Architektur und Funktionalität von BPM-Systemen Die idealtypische Architektur eines BPM-Systems besteht aus einer Prozessdesignkomponente, einer Prozess-Engine mit verschiedenen Integrationsdiensten und einer Prozessanalysekomponente. Daneben existieren Datenhaltungskomponenten zur Abspeicherung definierter und durchgeführter Prozesse (vgl. Abb. 24.1). Business Process Management-System Anwenderschnittstelle

Prozessdesign

Prozessdefinitionen

Prozessengine Integrationsdienste

Prozessanalyse

Prozessdurchführungen

Anwendungssysteme

Abb. 24.1: Idealtypische Architektur von BPM-Systemen Mittels der Prozessdesignkomponente werden die Geschäftsprozesse aus fachlicher und technischer Sicht modelliert. Diese werden in einer Prozessdatei abgelegt. Die Prozess-Engine greift die technische Prozessmodellierung auf und führt die entsprechenden Prozesse aus. Der Aufruf von im Prozess spezifizierten Diensten und Transaktionen externer Systeme erfolgt dabei über Inte305

24

Business Process Management-Systeme grationsdienste. Daten der Prozessdurchführung werden in einer weiteren Datenhaltungskomponente abgelegt. Eine Analysekomponente dient der Auswertung definierter wie durchgeführter Prozesse.

Varianten

Der Markt an BPM-Systemen gestaltet sich derzeit heterogen und ist nach wie vor in Bewegung. Entsprechend unterschiedlich fallen die angebotenen Systeme in Aufbau und Funktionalität aus. Nach ihrer Herkunft und funktionalen Schwerpunktsetzung können mit ƒ systemintegrierenden BPM-Systemen und ƒ anwenderkoordinierenden BPM-Systemen derzeit grob zwei Varianten unterschieden werden (vgl. dazu Vollmer & Peyret 2006 sowie Moore 2006). Systemintegrierende BPM-Systeme nehmen ihren Ursprung im »Enterprise Application Integration (EAI)«-Segment. Zentraler funktionaler Schwerpunkt dieser Subkategorie ist entsprechend die geschäftsprozessbasierte Integration heterogener Anwendungssysteme entlang einer (anwendungssystemintensiven) Prozesskette. Anwenderkoordinierende BPM-Systeme nehmen ihren Ursprung dagegen im Segment »Computer Supported Cooperative Work (CSCW)«. Zentrale Zielsetzung dieser Kategorie ist entsprechend die geschäftsprozessbasierte Koordination menschlicher Prozessteilnehmer entlang einer (personalintensiven) Prozesskette. Oft wird speziell für die zweite Subkategorie auch der Begriff »Workflow(management)systeme (WFMS)« verwendet (vgl. Mülder 2003a). Ohne Frage weisen beide Subkategorien zahlreiche Überschneidungen und enge funktionale Abhängigkeiten auf. Entsprechend finden sich bereits umfassende BPM-»Suiten« die beide Bereiche gleichzeitig abdecken. Die beiden Subkategorien wachsen damit zunehmend zusammen. Dementsprechend kann trotz unterschiedlicher Herkunft und nach wie vor existenter heterogener Schwerpunktsetzung zunehmend von einer Kategorie »BPM-Systeme« ausgegangen werden (vgl. Vollmer & Peyret 2006, 5).

24.1.1

Datenhaltungskomponenten

Prozessspezifikationen

In einer ersten Datenhaltungskomponente werden die mit der Prozessdesignkomponente spezifizierten Prozessmodelle gespeichert (»Process Respository«). Je nach Ausgestaltung der Prozessdesignkomponente können hier parallel fachliche, fachlich-technische und technische Beschreibungen der Prozesse abgelegt werden. Zur Unterstützung einer kontinuierlichen Verbesserung der Prozesse können auch verschiedene Versionen desselben Prozesses parallel gespeichert sein. Neben unternehmensindivi-

306

24.1 Architektur und Funktionalität von BPM-Systemen duell spezifizierten Prozessen können weiter auch extern vorkonfigurierte Prozessvorlagen (Referenzprozesse) importiert und abgelegt werden. Teilweise bieten auch die BPM-Systeme bereits vorkonfigurierte Prozesse an. Prozessdurchführungen

Eine weitere Datenhaltungskomponente speichert zur Laufzeit des Prozesses von der Prozess-Engine automatisch generierte Daten zur Prozessdurchführung. Hier werden etwa systembezogene Daten wie Durchlaufzeit, aufgerufene Anwendungssysteme, Rechnerperformanz sowie anwenderbezogene Daten wie Zahl und Dauer der durchgeführten Funktionen oder Status aktuell bearbeiteter Prozesse abgespeichert. Solche system- und anwenderbezogenen Prozessdurchführungsdaten dienen grundsätzlich der Analyse und Steuerung faktisch durchgeführter Prozesse.

24.1.2

Prozessdesignkomponente Die Prozessdesignkomponente unterstützt die Administratoren des BPM-Systems sowohl bei der fachlichen als auch bei der technischen Spezifikation derjenigen Prozesse, die vom BMP-System unterstützt werden sollen. Häufig ist hierzu eine mehrstufige Vorgehensweise notwendig, bei der nacheinander ƒ ein fachliches, ƒ ein fachlich-technisches und dann ƒ ein technisches Prozessmodell spezifiziert werden (vgl. Thomas et al. 2007).

Fachliche Spezifikation

Die fachliche Spezifikation eines Prozesses dient zunächst der Abbildung logischer Abläufe aus fachlicher Sicht. Hierzu existieren verschiedene Vorschläge meist grafischer Notationen zur Abbildung des entsprechenden Prozesses. Weit verbreitet ist die Ereignisgesteuerte Prozesskette (EPK) (vgl. Keller, Nüttgens & Scheer 1992). Ereignisgesteuerte Prozessketten stellen gerichtete Graphen dar, die sich als Folge von Ereignissen (Sechsecke), Funktionen (Rechtecke) und Verknüpfungsoperatoren (AND, OR, XOR) ergeben. Die Beziehungen zwischen Ereignissen und Funktionen werden als Kontrollflüsse (Pfeile) dargestellt. Ellipsen zeigen die Stellen oder Organisationseinheiten auf, denen die Abarbeitung einer Funktion übertragen wird. Prozesse können dabei auf unterschiedlichen Aggregationsebenen abgebildet werden (vgl. detailliert Keller, Nüttgens & Scheer 1992). Abb. 24.2 modelliert einen einfachen, bereichs- und unternehmensübergreifenden personalwirtschaftlichen Prozess, der im Anschluss an einen Abrechungsprozess entsteht (vgl. auch Kap. 13). Im Anschluss an die von der Fachabteilung »Personal« durchgeführte 307

24

Business Process Management-Systeme Personalabrechnung muss die Fachabteilung »Finanzbuchhaltung« einen entsprechenden Verbuchungsprozess abarbeiten. Gleichzeitig sind von der Fachabteilung »Personal« Zahlungsanweisungen für die Hausbank des Unternehmens zu erstellen. Mitarbeiter der Hausbank müssen diese dann überprüfen und entsprechende Überweisungen an die Kreditinstitute der Mitarbeiter vornehmen.

FA »Personal«

Abrechnung

š FA »FiBu«

Entgeltverbuchung

Zahlungsanweisung erstellen

FA »Personal«

Zahlungsanweisung erstellt Zahlungsanweisung prüfen

Sachbe. Bank

Zahlungsanweisung geprüft Entgelt überweisen

Sachbe. Bank

Engelt überwiesen

Abb. 24.2: Fachliche Prozessspezifikation (»EPK«) Mit dieser oder ähnlichen Vorgehensweisen lässt sich der rein fachliche Ablauf des vom BPM-System abzubildenden Prozesses darstellen. Zur Erstellung solcher grafischen Prozessmodelle bieten die Prozessdesignkomponenten i.d.R. grafisch orientierte Werkzeuge, die eine Zusammenstellung von Prozessketten über »Drag & Drop« ermöglichen. So erstellte Prozessmodelle werden im Prozessrepository abgelegt. Fachlich-Techn. Spezifikation

308

Zur sukzessiven Überführung solcher fachlichen in technische Prozessbeschreibungen sind diese zunächst um technische Aspekte anzureichern, was hybride fachlich-technische Prozessbeschreibungen zur Folge hat. Als derzeit verbreitete Modellierungsmethode hat dabei die »Business Process Modelling Notati-

24.1 Architektur und Funktionalität von BPM-Systemen

Unternehmen Bank

FinanzPersonalbuchhaltung management

on (BPMN)« zu gelten (vgl. White 2004). BPMN ist zum einen eine aus fachlicher Sicht leicht verständliche, grafisch orientierte Methode der Beschreibung von Geschäftsprozessen. Zum anderen kann BPMN direkt in eine ausführbare, technische Prozessbeschreibung überführt werden. Beide Eigenschaften bedingen den hybriden Charakter einer Prozessbeschreibung mit BPMN. Auch BPMN besteht aus grafischen Notationen, die die Abbildung eines Prozesses ermöglichen. Grundsätzlich werden dabei einzelne Prozessteilnehmer in verschiedene, so genannte »Pools« und »Lanes« eingeteilt. Die Aktivitäten eines Prozessteilnehmers werden daher stets in seinem Pool bzw. seiner Lane abgebildet. Der eigentliche Prozess wird dann analog über die Objekte Start, Zwischen- und Endereignisse (Kreise), Aktivitäten (Rechtecke) und Gateways (Rauten) abgebildet. Diese Objekte werden über Sequenz- und Nachrichtenflüsse verbunden (vgl. detailliert White 2004). Abb. 24.3 zeigt den oben beschriebenen Prozess in der BPMN-Darstellung.

Abrechnung

Zahlungsanweisung empfangen

+

+

Zahlungsanweisung erstellen

Zahlungsanweisung senden

Entgeltverbuchung +

Zahlungsanweisung prüfen

Entgelt überweisen

Abb. 24.3: Fachlich-technische Prozessspezifikation (»BPMN«) Zunächst existieren die beiden Pools »Unternehmen« und »Bank«, wobei das Unternehmen noch in die Lanes »Personalmanagement« und »Finanzbuchhaltung« aufgeteilt wird. Der Prozess beginnt mit einem Startereignis und umfasst zur fachlichen Beschreibung analoge Schritte. Als Spezifikum weist BPMN Nachrichtenflüsse zwischen den Lanes auf. Entsprechend muss ein Nachrichtenfluss zwischen Unternehmen und Bank abgebildet 309

24

Business Process Management-Systeme werden. Abrechung und Entgeltverbuchung enthalten dabei eingebettete Unterprozesse (»+«). Diese Beschreibung erfolgt über grafisch orientierte Werkzeuge mittels »Drag & Drop«-Funktionalitäten. Um diese zunächst ebenfalls rein fachliche Prozessbeschreibung mit technischen Aspekten anzureichern, ist ein Abgleich der fachlichen Beschreibung mit zur Verfügung stehenden Diensten oder Systemtransaktionen notwendig. Stehen etwa auf der Aggregationsebene des modellierten Prozesses keine adäquaten Dienste (»Services«) oder Systemtransaktionen zur Verfügung, ist der Prozess weiter zu verfeinern, bis die Granularitäten von Prozess und Diensten oder Transaktionen korrespondieren. Damit einzelne Aktivitäten des Prozesses von korrespondierenden Diensten oder Transaktionen unterstützt werden können, sind die Aktivitäten in allen erforderlichen technischen Attributen, wie etwa zuständiger Service, ein- und ausgehende Nachrichten etc. zu spezifizieren. Diese zusätzlichen technischen Spezifikationen sind in der grafischen Darstellung nicht zu sehen. Insgesamt gilt, dass die Überführung einer rein fachlichen in eine fachlich-technische Prozessbeschreibung eine kreative Aufgabe darstellt, da Konzepte der fachlichen Ebene wie Funktionen, Organisationseinheiten und Ressourcen auf Konzepte der technischen Ebene wie Daten, Dienste, Transaktionen und Schnittstellen übersetzt werden müssen (vgl. Thomas et al. 2007). So wird die fachliche Beschreibung um technische Beschreibungen des Prozesses angereichert, was den hybriden Charakter von BPMN-Beschreibungen bedingt. Da fachliche Aspekte auch in der hybriden Beschreibung meist ausreichend abgedeckt werden können, existieren auch Systeme, die auf die rein fachliche Beschreibung verzichten und direkt mit der fachlich-technischen Beschreibung des Prozesses, etwa auf BPMN-Basis, starten. Fertige BPMN-Abbildungen werden dabei als Business Process Diagramme (BPD) bezeichnet. Auch solche BPD werden im Prozessrepository abgelegt.

Technische Spezifikation

310

Trotz des Aufgreifens technischer Aspekte ist ein so beschriebener Prozess noch nicht von der Prozess-Engine ausführbar. Die Beschreibung muss entsprechend in eine rein technische Beschreibung im Sinne eines von der Prozess-Engine ausführbaren Codes überführt werden. Eine weit verbreitete Lösung besteht mit der »Business Process Execution Language (BPEL)«. BPEL ist eine XML-basierte Sprache, die insbesondere internetbasierte Prozessdurchführungen ermöglicht. Ein BPEL-Prozess besteht dabei aus einer Menge von Service-Aufrufen, die einer logischen und zeitlichen Reihenfolge unterliegen. Das BPEL-Modell ist da-

24.1 Architektur und Funktionalität von BPM-Systemen mit das informationstechnische Gegenstück zur fachlichen Prozessbeschreibung. Existiert als Ergebnis einer fachlich-technischen Beschreibung ein BPD, können Transformationsregeln zur automatisierten Übersetzung des BPD in BPEL verwendet werden. Dabei sorgen deterministische Regeln für die jeweilige Transformation. Diese Transformation von BPMN zu BPEL ist allerdings (derzeit noch) nicht vollständig spezifiziert. Daher ist noch keine vollautomatisierte Übertragung möglich. Teilweise erkennen die Systeme auch Lücken oder Widersprüche im BPELCode und ermöglichen ein assistentengestütztes Vervollständigen oder Korrigieren des Codes (vgl. Thomas et al. 2007, 16ff.). Mit der nur unvollständigen Transformierbarkeit entsteht das Problem, dass sowohl Änderungen im BPD als auch in BPEL gegenseitig »bekannt« gemacht werden müssen, um so eine konsistente Geschäftsprozessbasis für die Abwicklung bereitzustellen. BPEL ist im Sinne systemintegrierender BPM-Systeme weiter ausschließlich auf die Interaktion zwischen Systemen ausgerichtet. Es unterstützt entsprechend nicht die Einbindung und Koordination menschlicher Anwender im Sinne der Subkategorie anwenderkoordinierender BPM-Systeme. Daher wird mit der Erweiterung »BPEL4People« versucht, dies zu ermöglichen. Analog wird teils auch die (teil-)automatisierte Transformation von BPD in andere Prozessausführungssprachen – wie etwa in »XML Process Definition Language (XPDL)« – unterstützt. Im Gegensatz zu BPEL sind hier die Integration von Personen und die Einbindung manueller Aktivitäten möglich. Auch solche technischen Beschreibungen ausführbarer Prozesse in Prozessausführungssprachen werden als Prozessdefinition abgelegt. Weiterhin erfolgt über die Designkomponente in Verbindung mit der Datenbank für Prozessdefinitionen gleichzeitig auch die Dokumentation von Geschäftsprozessvarianten. Neben und nach der Erstspezifikation von Prozessen erlaubt die Prozessdesignkomponente auch die Änderung und Optimierung der Prozesse auch für Geschäftsprozessanalysten auf fachlicher Ebene.

24.1.3

Prozessanalysekomponente Eine Prozessanalysekomponente dient grundsätzlich der Auswertung der Prozessdefinitionen und -durchführungen. Sie verfügt insbesondere über die Funktionalität ƒ der Prozesssimulation, ƒ des Prozessmonitoring und ƒ des Business Activity Monitoring.

311

24

Business Process Management-Systeme Über Simulationen von Prozessen werden Schwachstellen und Engpässe spezifizierter Prozesse identifiziert, um das korrespondierende Prozessmodell zu verbessern (vgl. Newcomer & Lomow 2005, 224). Die Simulation kann dabei oft sowohl in fachlicher Ebene (z.B. zur Ermittlung der Anzahl an Service Center Agenten zu den Hauptgeschäftszeiten) als auch auf technischer Ebene (z.B. zur Überprüfung der Serverperformanz) stattfinden. Das Prozessmonitoring zielt auf die aktive, vom Anwender ausgehende Analyse der Prozessdurchführungsdaten ab. Dies umfasst etwa die Erstellung von Übersichten über laufende Prozesse, Übersichten über abgeschlossene Prozesse, Statusanzeigen aktuell laufender Prozesse, Aussetzen und Wiederaufnahmen von Prozessen u.a.m. (vgl. Newcomer & Lomow 2005, 227). Das Business Activity Monitoring stellt dagegen eine zeitnahe, weitgehend automatisierte Variante der Prozessüberwachung dar. Nach Definition gewisser prozessbezogener Bedingungen kann das System bei Eintreten dieser Bedingungen automatisch eine Warnmeldung generieren. Beispielsweise kann das Verletzen eines definierten Service Level Agreements eine entsprechende Meldung an zuständige menschliche oder maschinelle Instanzen generieren. Solche Meldungen können ihrerseits auch wieder weitere Prozesse auslösen (vgl. Chang 2005, 181f.). Beispielswiese könnten im oben aufgeführten Entgeltzahlungsprozess Termine für die späteste Übermittlung der Zahlungsanweisung an die Bank festgelegt werden. Ein Überschreiten des Termins würde dann eine entsprechende Meldung generieren, die einen verantwortlichen Anwender informiert und/oder das Abrechnungssystem zu einer erneuten Sendung der Zahlungsanweisung veranlasst. Die Prozessanalysekomponenten werden zunehmend auch durch Business Intelligence-Funktionalitäten ergänzt, die eine vertiefte Analyse von Prozessdaten mittels OLAP (vgl. Kap. 11) und Data Mining (vgl. Kap. 12) auch auf der Basis von Prozesscockpits ermöglichen.

24.1.4

Prozess-Engine und Integrationsdienste Die Prozess-Engine dient der Ausführung und Steuerung des gesamten Prozessablaufs über alle beteiligten Anwender und Systeme hinweg. Dazu greift sie auf den ausführbaren Code der technischen Prozessspezifikation zurück. Tritt ein definiertes Auslöseereignis ein, sorgt die Prozess-Engine automatisch für die logisch und zeitlich korrekte Abarbeitung des damit angestoßenen Prozesses. Dazu werden einzelne Services und Transaktionen

312

24.1 Architektur und Funktionalität von BPM-Systemen gemäß dem Prozessablauf aufgerufen und automatisiert durch das jeweilige System abgearbeitet oder einem verantwortlichen und autorisierten Anwender zur Abarbeitung in Interaktion mit dem jeweiligen System vorgelegt. Die dabei erzielten Teilergebnisse werden automatisiert entlang der Prozesskette weitergeleitet (»Routing«), bis der Prozess vollständig abgearbeitet ist. Regelmäßig wird dabei der Prozessstatus nachverfolgt, die Prozesseinführung überwacht und die Einhaltung von Geschäftsregeln kontrolliert (vgl. Newcomer & Lomow 2005, 226). Die implementierten Integrationsdienste dienen dem Aufruf und der Verbindung der unterschiedlichen Systeme. Im oben beschriebenen Prozess könnten neben einem Personalabrechnungssystem (vgl. Kap. 13) etwa auch ein Buchhaltungssystem und ein kreditwirtschaftliches System involviert sein. Ob eine Anbindung eines Systems möglich ist, hängt damit sowohl von der Ausgestaltung des Integrationsdienstes wie von der Ausgestaltung des jeweiligen Anwendungssystems ab. BPEL basierte Prozesse ermöglichen speziell die Anbindung von Web Services. Web Services sind Systeme, die den direkten internetbasierten Austausch mit anderen Webservices über spezifizierte Schnittstellen ermöglichen (vgl. Newcomer & Lomow 2005, 20). Dabei dient die XML-basierte Beschreibungssprache »Web Service Description Language (WSDL)« der Beschreibung von Funktionen und Daten eines Web Service. Werden also Web Services als Integrationstechnologie verwendet, sorgt WSDL für ein einheitliches Austauschformat für die ansonsten proprietären Daten, in dem das Services nachfragende System (»Service Requester«) mit dem Service anbietenden System (»Service Provider«) kommunizieren kann. In obigem Prozessbeispiel könnte also beispielsweise das Personalabrechnungssystem die Ausgabe von Zahlungsanweisungen als Web Service anbieten. Die Prozess-Engine könnte diesen Service dann im Rahmen des Entgeltzahlungsprozesses aufrufen und die Daten dem ebenfalls als Web Services realisierten Banksystem zur Verfügung stellen. Auf diese Weise könnten zwei heterogene Systeme mit proprietärer Datenhaltung zur integrierten Abarbeitung eines unternehmensübergreifenden Prozesses verwendet werden. Entsprechend zur Ausrichtung von BPEL richten sich Webservices als Integrationsdienst derzeit allerdings ausschließlich auf die Kommunikation zwischen Systemen. Sie bieten damit keinen wirklich umfassenden Ansatz zur Integration aller Personen und Systeme eines Prozesses. Daher sind derzeit weitere Integrationsdienste und Schnittstellentechnologien zu nicht webservice-fähigen Anwendungen nötig, um der Vision 313

24

Business Process Management-Systeme von BPM-Systemen als umfassende prozessorientierten Integrationssysteme näher zu kommen.

24.2

Anwendung von BPM-Systemen Je nach funktionaler Schwerpunktsetzung variieren auch die Anwendungspotenziale von BPM-Systemen im Personalmanagement. Übergreifend lassen sich jedoch mit ƒ dem Management der Ablauforganisation, ƒ der Integration von Anwendungssystemen und ƒ der Realisierung einer serviceorientierten Architektur drei mögliche Anwendungsszenarien für BPM-Systeme finden. Insbesondere die letzten beiden Szenarien dokumentieren den Integrationssystemcharakter von BPM-Systemen.

Ablauforganisation

314

Mit der Möglichkeit, alle wesentlichen Prozesse des Personalmanagements zu spezifizieren, durchzuführen und zu kontrollieren, weisen BPM-Systeme umfangreiche Unterstützungspotenziale bei der Organisation des Personalmanagements auf. So können zunächst bestehende Prozesse evaluiert und optimiert werden. Als Nebenprodukt erhält man damit auch eine umfassende Dokumentation der personalwirtschaftlichen Ablauforganisation. Dass anschließend der komplette Prozessablauf über das System gesteuert wird, ermöglicht ein beschleunigtes und systematischeres Abarbeiten aller anstehenden Teilaufgaben in logisch richtiger Reihenfolge. Die angesprochenen Monitoringmöglichkeiten erlauben es weiter, Echtzeitinformationen über den aktuellen Stand der Prozessbearbeitung zu erhalten und ermöglichen so ein permanentes »Tracking« des Prozessfortschritts. Ebenso wird es möglich, die Arbeitsmenge und -güte einzelner Prozessteilnehmer zu evaluieren. Damit stellen BPM-Systeme Anwendungen zur umfassenden Gestaltung, Durchführung und Kontrolle der gesamten personalwirtschaftlichen Ablauforganisation dar, die deutlich mehr leisten als die bloße Koordination heterogener Anwender (gruppen) bei der Bearbeitung personalwirtschaftlicher Prozesse. Allerdings stellen zahlreiche funktionale Anwendungssysteme im Personalmanagement - darunter etwa Beschaffungsmanagement(vgl. Kap. 16), Learning Management- (vgl. Kap. 20), Performance Management- (vgl. Kap. 21), Vergütungsmanagement- (vgl. Kap. 22) oder ERP-Systeme (vgl. Kap. 23) - bereits integrierte Workflowfunktionen zur Verfügung. Ein Einsatz von BPM-Systemen ist dann nur sinnvoll, wenn Prozesse unterstützt werden sollen, die diese Systeme überschreiten.

24.2 Anwendung von BPM-Systemen Systemintegration

Systemseitig besteht ein zweites Anwendungsszenario aus der (partiellen) Integration von vertikal heterogenen Systemarchitekturen mit per se nicht kompatiblen Einzelsystemen (vgl. auch Kap. 1). Wären in obigem Prozessbeispiel etwa das Personalabrechnungssystem und das bankwirtschaftliche System nicht kompatibel, bestünde ein Medienbruch bei der Bearbeitung des Auszahlungsprozesses. Entsprechend müssten auf der Basis von ausgedruckten Überweisungsträgern oder Listen manuelle Eingaben in das bankwirtschaftliche System getätigt werden. Daher eignen sich BPM-Systeme zur Realisierung einer Integrationsschicht, die Medienbrüche einer fragmentierten Architektur behebt. Als positiver Begleiteffekt solcher Integrationsbemühungen ist hier auch die Möglichkeit der Optimierung der korrespondierenden Prozesse zu nennen. Allerdings bilden der Aufwand und die Komplexität von BPM-basierten Integrationsprojekten in technischer wie in organisatorischer Hinsicht Barrieren einer wirklich umfassenden abteilungs- wie unternehmensübergreifenden Integration aller für das Personalmanagement relevanten Prozesse und Systeme. Realistischer ist daher das Szenario einer selektiven Integration wesentlicher Prozesse und Systeme auf der Basis von BPM-Systemen bei Tolerierung gewisser nicht-integrierter »Inselsysteme« im Rahmen einer fragmentierten Architektur.

Serviceorientierung

Generell werden BPM-Systeme auch zur Realisierung einer serviceorientierten Architektur vorgeschlagen (vgl. Ließmann & Wetzke 2006 und Thomas et al. 2007 sowie Kap. 1). Speziell soll die notwendige Integrationsinfrastruktur durch integrationsorientierte BPM-Systeme ermöglicht werden. Bei exklusiver Verwendung von Web Services können insbesondere integrationsorientierte BPM-Systeme zur Realisierung der SOA-Integrationsschicht herangezogen werden. Das BPM-System »orchestriert« dann die im Rahmen eines personalwirtschaftlichen Prozesses notwendigen Services und die Interaktionen von Anwendern. Eine »Mix & Match«-Strategie, bei der die Gesamtarchitektur flexibel aus heterogenen internen und externen Services zusammengestellt wird, wäre eine mögliche Folge. Ein solches Projekt bedeutet allerdings eine langfristige strategische Neuausrichtung der personalwirtschaftlichen oder gar unternehmensweiten Systemarchitektur mit korrespondierenden Folgen für Aufwand, Kosten und Zeitbedarf.

Verbreitung

Derzeit sind keine empirischen Studien zur Verbreitung und spezifischen Verwendung von BPM-Systemen im Personalmanagement bekannt.

315

25

Portalsysteme Portalsysteme (»Portal«, »Enterprise [Information] Portal [EIP]«, HRPortal, Mitarbeiterportal) sind Integrations- und Präsentationsplattformen, die unternehmensinternen und -externen Anwendern alle benötigten Anwendungen, Informationen und Interaktionen personalisiert und anforderungsgerecht zur Verfügung stellen.

25.1

Architektur und Funktionalität von Portalsystemen Generell umfassen Portalsysteme ähnliche Komponenten, wobei je nach Herkunft und Ausrichtung des Anbieters allerdings unterschiedliche Schwerpunkte möglich und üblich sind.

....

....

....

e-Shop

Dokumentenmang.

Groupware

WWWBrowser Bereitstellungskomponente

Struktur & Layout

Contentmanagement

Prozessunterstützung

Suchfunktion

Personalisierung

Anwenderverwaltung

»single sign on« Workflow

...

Portalschnittstelle (API) Portalanwendungen

externe Dienste

Integrationskomponente

externe Daten

Transaktionskomponente

BackendSysteme

Portalbasisdienste

Portalsystem

WAPBrowser

...

Abb. 25.1: Idealtypische Architektur von Portalsystemen (in Anlehnung an Gurzki & Hinderer 2003, 157) Üblicherweise können eine Integrations- und Transaktionskom317

25

Portalsysteme ponente, diverse Portalbasisdienste, diverse Portalanwendungen, eine Bereitstellungskomponente, sowie eine interne Portalschnittstelle (»Application Programming Interface [API]«) unterschieden werden (vgl. Abb. 25.1). Die Integrations- und Transaktionskomponente dient der strukturierten Anbindung und Integration von internen Anwendungen und externen Diensten. Portalbasisdienste umfassen grundlegende Funktionen zu Erstellung und Betrieb von Portalen wie etwa Benutzerverwaltung und Personalisierungsfunktionen. Weitere mitgelieferte oder individuell erstellte Portalanwendungsmodule ergänzen die Funktionalität eines Portals. Die Bereitstellungskomponente dient der visuellen Darstellung von Portalanwendungen im Portal und der Bereitstellung der Inhalte für Browsersysteme und mobile Endgeräte. Die Portal-API sorgt als Anwendungsschnittstelle dafür, dass Portalanwendungen vom Portal aufgerufen werden können, und umgekehrt, dass Portalanwendungen die Basisdienste des Portals nutzen können (vgl. Gurzki & Hinderer 2003).

25.1.1

Integrations- und Transaktionskomponente Portale sind Integrationssysteme, d.h. eine Vielzahl von Anwendungen, Diensten und Informationen unterschiedlicher Herkunft sollen den Anwendern unter einer einheitlichen Oberfläche integriert zur Verfügung gestellt werden. Dass diese Systemkategorie sich für den Anwender damit wie ein großes »Tor« zu allen benötigten Anwendungen und Daten gestaltet, erklärt die Bezeichnung »Portal«. Entsprechend besteht die Möglichkeit und Notwendigkeit der Anbindung oft vielfältiger interner und externer Systeme und Dienste, die übergreifend als »Backend«-Bereich des Portals bezeichnet werden. Je nach Anwendungsintention des Portals können solche Systeme in generellen betriebswirtschaftlichen Anwendungen des Unternehmens, Anwendungen von Application- und Service-Providern im Rahmen eines Outsourcings sowie weiteren externen Quellen bestehen. Die Integrationskomponente bildet daher die notwendige Schnittstelle zu solchen »Backend«-Systemen und -Daten. Die Bandbreite der von der Integrationskomponente erfüllten Funktionen kann hier von einfachen Datenbankschnittstellen bis hin zu komplexen Funktionen des »Enterprise Application Integration (EAI)« bzw. eines systemintegrierenden »Business Process Management (BPM)« reichen (vgl. Gurzki & Hinderer 2003, 159). Während Datenbankschnittstellen eine einfache Übernahme von Daten in das Portal ermöglichen, zielen weitergehende systemintegrierende Funktionen auf eine prozessorientierte Integration von heterogenen au-

318

25.1 Architektur und Funktionalität von Portalsystemen tonomen Anwendungssystemen (vgl. Kap. 24). Diese Art der Anbindung ermöglicht eine Geschäftsprozessintegration über verschiedene Anwendungen hinweg, ohne die Detailprozesse der jeweiligen Anwendungen verändern zu müssen. Transaktionsdienste gewährleisten dann insbesondere die Transaktionssicherheit über die verschiedenen angebundenen Systeme hinweg.

25.1.2

Portalbasisdienste Portalbasisdienste stellen mit der Single Sign On-Komponente, der Anwenderverwaltung, der Personalisierungskomponente, der Suchfunktion, der Prozessunterstützungskomponente, der Content Management-Komponente sowie der Struktur- und LayoutKomponente grundlegende Funktionen zum generellen Betrieb eines Portals bereit. Allerdings können diese Dienste wie etwa die Benutzerverwaltung oder das Content Management zumindest teilweise alternativ auch von extern angebundenen Systemen übernommen werden (vgl. Gurzki & Hinderer 2003).

Single Sign On

Die »Single Sign On«-Komponente (»SSO«, »Single Sign In«, Einmalanmeldung) ermöglicht es einem Anwender nach einer einmaligen Authentifizierung am Portal auf alle Anwendungen, Dienste und Daten, für die er Berechtigungen aufweist, zuzugreifen. Nach dieser Erstanmeldung muss der Anwender beim portalbasierten Zugriff auf Anwendungen oder Dienste zwar nach wie vor jeweils authentifiziert werden, allerdings übernimmt dies die Single Sign On-Komponente im Hintergrund. Solche Einmalanmeldungen führen für den Anwender zur Vereinfachung des Zugriffs auf verschiedene Systeme und damit zu Zeitersparnis. Aus Unternehmenssicht kann die gesamte Authentifizierungsinfrastruktur zusammengefasst werden und die Kosten für die Administration und Implementation dieser Komponenten gesenkt werden.

Anwenderverwaltung

In Abstimmung mit der Single Sign On-Komponente zielt die Anwenderverwaltung analog zu anderen Anwenderverwaltungen auf die effiziente Abbildung von Portalanwendern und deren Zugriffsrechten sowie die Überwachung von Anwenderaktivitäten im Portal. Oft werden hierbei Anwenderrollen verwendet. Anwenderrollen definieren die Aufgaben, Eigenschaften und vor allem die Zugriffsrechte eines Einzelanwenders, meist aber einer spezifischen homogenen Subgruppe von Anwendern innerhalb des Portals. Letztere Variante verhindert, dass einzelnen Anwendern in aufwändiger Weise jeweils individuelle Rechte zugesprochen werden müssen. Dies erleichtert die Rechteverwaltung 319

25

Portalsysteme beim Anlegen von Anwenderrechten, aber insbesondere auch bei Änderungen, da dann nur die Rechte der Anwenderrolle geändert werden müssen. Einzelne Anwender können dabei durchaus mehrere Rollen haben, die Gesamtheit der zu erfüllenden Rollen bestimmt die Zugriffsmöglichkeiten eines einzelnen Anwenders auf die Portalinhalte.

Personalisierung

Die Personalisierungskomponente dient der individualisierten Bereitstellung von Anwendungen, Diensten und Informationen durch das Portal. Ziel der Personalisierung ist die Anpassung des Portals an die persönlichen Interessen, Fähigkeiten und Bedürfnisse unterschiedlicher Anwender. Personalisierungen beziehen sich dabei insbesondere auf die Navigation, die Präsentation und die Interaktion im Portal (vgl. Vlachakis et al. 2005, 31f.). Personalisierungen der Navigation zielen auf die Bereitstellung individualisierter Navigationsstrukturen im Portal. Personalisierungen der Präsentation dienen der individuellen Gestaltung von Layout und Formatierung. Personalisierungen der Interaktion beziehen sich auf die individuelle Ausgestaltung portalbasierter Interaktion und Kommunikation zwischen verschiedenen Anwendern. Solche individuellen Ausgestaltungen können dabei grundsätzlich durch den Portalanwender selbst oder aber durch die Personalisierungskomponente durchgeführt werden. Im ersten Fall wählt der Anwender aus verschiedenen Gestaltungsmöglichkeiten die seinen Präferenzen entsprechende Ausgestaltung selbst aus. Im zweiten Fall sorgen »Personalisierungsengines« für die individuelle Ausgestaltung. Weit verbreitet ist hier etwa eine regelbasierte Personalisierung, die die Ausgestaltung unter Rückgriff auf ein Regelwerk durchführt. Beispielsweise könnte sich eine Regel auf die gemeinsame Präsentation zweier Informationen beziehen: Ein Anwender, der Information A im Portal abfragt, erhält dann regelbasiert automatisch auch Information B geliefert. Angesichts einer mit Portalen einhergehenden drohenden Informationsüberlastung, bietet die Personalisierung neben dem Konzept der Anwenderrollen eine wichtige Möglichkeit zur zielgerichteten Bereitstellung von Anwendungen und Inhalten (vgl. Brooks 2001).

Suchfunktion

Eine integrierte Suchfunktion ermöglicht es dem Anwender, die heterogenen Quellen und Systeme des Backendbereiches gemeinsam und übergreifend nach bestimmten Begriffen oder Kriterien abzusuchen. Neben einer Volltextsuche werden meist weitere komplexere Suchfunktionen wie etwa ein Suchbaum angeboten (vgl. Vlachakis et al. 2005). Aufgrund der Heterogenität und Anzahl angebundener Quellen und Systeme bieten solche Suchfunktionen erhebliche Erleichterungen für die Anwender.

320

25.1 Architektur und Funktionalität von Portalsystemen Prozessunterstützung

In enger Interaktion mit der Integrations- und Transaktionskomponente steuert die Prozessunterstützungskomponente solche Prozesse, an denen mehrere Backend-Systeme beteiligt sind und die entsprechend (auch) zwischen diesen Systemen ablaufen. Solche eher auf die technische Integration von Systemen ausgerichteten Dienste können im Rahmen der Portalanwendungen durch Workflow- und Groupware-Systeme von organisatorischer Seite her abgerundet werden.

Content Management

Analog zu im Backendbereich ebenfalls anbindbaren externen Content Management-Systemen ermöglichen interne Content Management-Komponenten die strukturierte Speicherung, Verwaltung, Archivierung, Aufbereitung und Publikation von Daten und Dokumenten, die den Anwendern über das Portal zur Verfügung gestellt werden sollen. Diese Möglichkeit richtet sich insbesondere auch auf solche Daten und Dokumente, die nicht von den Systemen des Backend bereitgestellt werden können. Entsprechend können zusätzliche Inhalte in strukturierter und unstrukturierter Form zur Verfügung gestellt werden. Aufgrund der oft eingeschränkten Content Management-Funktionen der Basisdienste sind insbesondere bei umfangreicheren Projekten oft externe Backend Content Management-Systeme vorzuziehen (vgl. Gurzki & Hinderer 2003, 160).

Struktur- u. Layoutmanagement

Das Struktur- und Layoutmanagement übernimmt die Zusammenstellung und Formatierung der vom Anwender abgefragten Portalseiten. Das Strukturmanagement dient zunächst der Definition des personalisierten strukturellen Aufbaus des Portals und damit der Anordnung verschiedener Anwendungen im Rahmen der Portalstruktur. Weiter werden auch personalisierte Navigationsstrukturen durch das Strukturmanagement festgelegt. Das Layoutmanagement stellt dann die vom Anwender angefragten Seiten aus den einzelnen Backend-Anwendungen zusammen und erzeugt eine entsprechend formatierte Ausgabe auf dem Endgerät des Anwenders. Dies schließt die Übernahme genereller Aufgaben der Formatierung wie farbliche Gestaltung etc. ein (vgl. Vlachakis et al. 2005, 30f.).

25.1.3

Portalanwendungen Portalanwendungen stellen zusätzlich zu den angebundenen Systemen des Backendbereichs erwünschte Funktionalitäten zur Verfügung. Dabei können diese zusätzlichen Komponenten grundsätzlich vom Portalanbieter integriert mit angeboten werden, von Drittanbietern angebotene Systeme sein oder vom por321

25

Portalsysteme talanwendenden Unternehmen individuell erstellte Komponenten darstellen. Oft handelt es sich allerdings um bereits vorgefertigte Module oder Anwendungen, die auch außerhalb von Portalen eingesetzt werden. Solche Portalanwendungsmodule haben zum einen zur Folge, dass der Funktionsumfang von Portalsystemen nicht abschließend beschrieben werden kann. Je nach implementierten Portalanwendungen kann die Funktionalität von Portalsystemen entsprechend erheblich variieren. Zum anderen wird mit Blick auf die Unterscheidung von Anwendungs- und Präsentationssystemen auch der hybride Charakter von Portalen deutlich, da sie eben nicht nur der reinen Präsentation von BackendSystemen dienen, sondern mit den Portalanwendungen in mehr oder minder ausgeprägtem Umfang auch eigene Anwendungen integrieren (können). Generell bilden etwa Workflowmanagementsysteme, Groupwaresysteme, Dokumentenmanagementsysteme oder e-Shop-Systeme häufig von Portalanbietern mitgelieferte Portalanwendungen (vgl. Vlachakis et al. 2005, 32ff.).

Workflow

Workflowsysteme (oder auch anwenderkoordinierende Business Process Management-Systeme) erlauben die Steuerung von Geschäftsprozessen über zahlreiche verschiedene, am Prozess beteiligte Anwender hinweg (vgl. detailliert Kap. 24).

Groupware

Im Unterschied zu Workflowsystemen richten sich Groupwaresysteme (kollaborative Systeme, »Work Group Computing«) auf die Unterstützung der Bearbeitung schlecht strukturierter Aufgaben durch i.d.R. raum-zeitlich getrennte Portalanwender. Dabei stellt Groupware keine homogene Kategorie von Systemen dar, sondern zerfällt selbst wiederum in eine heterogene Reihe von Subkategorien. So werden beispielsweise Electronic Mail-Systeme (elektronische Post, »Electronic Mail«) zur Groupware gerechnet. Solche Systeme ermöglichen es, innerhalb kurzer Zeiträume Textnachrichten zwischen den Portalanwendern auszutauschen. Darüber hinaus lassen sich beliebige Dateien und Dokumente als Anhang (»Attachment«) der Mail mit versenden. Eine weitere mögliche Komponente stellen Mehrbenutzereditoren zur gemeinsamen Daten- und Dokumentenbearbeitung dar, wobei entsprechende Zugriffsmechanismen die Datenintegrität bei simultaner Bearbeitung eines Dokuments durch mehrere Anwender sicherstellen. Diskussionsforen (»Bulletin Boards«) sind virtuelle Räume zum Austausch von Informationen zwischen den Portalanwendern. Die Kommunikation findet dabei asynchron statt: Ein Portalanwender hinterlässt einen Diskussionsbeitrag (»Posting«) im Forum, wo ihn andere Portalanwender lesen und darauf antworten können. Mehrere Beiträge zum selben Thema werden dann

322

25.1 Architektur und Funktionalität von Portalsystemen jeweils zu einem Thema (»Topic«) zusammengefasst. Auf diese Weise können Portalanwender Kontakte knüpfen, Ansprechpartner für Probleme finden sowie Antworten auf offene Fragen erhalten. Konferenzsysteme ermöglichen synchrone virtuelle Treffen von räumlich getrennten Portalanwendern. Speziell Videokonferenzen ermöglichen dabei ausgeprägte Interaktionen zwischen den beteiligten Anwendern. Neben diesen Subkategorien können weitere Groupware-Anwendungen in Portale integriert werden. Portale können entsprechend eine umfassende Interaktions- und Kommunikationsinfrastruktur für die Anwender bereitstellen. Dokumentenmanagement

Dokumentenmanagementsysteme sind Anwendungen zur datenbankgestützten Speicherung, Verwaltung und Bereitstellung beliebiger elektronischer Dokumente, wie beispielsweise einer digitalen Personalakte (vgl. detailliert Kap. 6).

e-Shop

Ein e-Shop (Onlineshop, Webshop) ist eine Anwendung, die Produkte zum Verkauf im Internet bereitstellt. I.d.R. weisen solche Systeme zunächst eine Katalogfunktion auf, in der die angebotenen Produkte in Aussehen, Funktionalität und Preis vorgestellt werden. Häufig sind neben reinen Produktabbildungen auch audio-visuell animierte Vorstellungen der entsprechenden Produkte möglich. Teilweise sind auch Produktkonfiguratoren implementiert, mit denen variantenreiche Produkte vom Anwender individuell zusammengestellt werden können. Warenkorbfunktionen ermöglichen es dem Anwender, verschiedene Produkte zunächst zu sammeln, bevor ein Kauf bzw. eine Bestellung vorgenommen wird. Bestell- und Bezahlfunktionen ermöglichen schließlich die konkrete Abwicklung des Kaufvorganges. Obwohl sie generell fraglos dem Vertriebs- und nicht dem Personalmanagement zuzuordnen sind, lassen sich e-Shops im Rahmen des Personalmanagements auch zur Realisierung von Mitarbeiterverkäufen einsetzen (vgl. Brooks 2001).

25.1.4

Bereitstellungskomponente Bereitstellungskomponenten stellen die Portalinhalte in verschiedenen Formaten für die Endgeräte der Anwender zur Verfügung. Portalinhalte werden dabei i.a.R. über Browsersysteme (vgl. Kap. 28) zugänglich gemacht, wobei neben Arbeitsplatzrechnern auch Browser mobiler Kleingeräte bedient werden können (vgl. Vlachakis et al. 2005). Die Verwendung von Browsersystemen als Portalendgeräte erbringt die bekannten Vorteile webbasierter Anwendungen. Die Installation von speziellen Anwenderschnittstel323

25

Portalsysteme len entfällt. Browsersysteme haben geringe Hardwareanforderungen, sind weit verbreitet und einfach zu bedienen. In der Folge können Anwender die Portalinhalte von beliebigen Rechnern mit Webzugang nutzen. Speziell bei Verwendung mobiler Endgeräte wird ein (nahezu) ubiquitärer Zugriff auf Portalinhalte möglich.

Portlets

Ähnlich der von Browsern bekannten Aufteilung in »Frames«, die verwendet wird, um mehrere Einzeldokumente auf einer Webseite simultan darzustellen (vgl. Kap. 28), finden auf Portalseiten so genannte »Portlets« Anwendung. Portlets sind Unterfenster der Portalseite, in denen die jeweiligen Inhalte der unterschiedlichen Quellen und Anwendungen präsentiert und auf einer Portalseite zusammengefasst werden (vgl. Abb. 25.2). Die Portlets können individuell minimiert oder entfernt werden und verfügen oft auch über eigene Hilfe- und Konfigurationsmenüs.

ERP

extern

x x

x

Portlet2 x

Portlet1

Portlet...

Abb. 25.2: Portlet-Struktur einer Portalseite im Browsersystem Ebenso können individuelle Portlets vom Anwender i.d.R. personalisiert werden. Neben Browsersystemen existieren weitere mögliche Endgeräte, für die Portalinhalte bereitgestellt werden können. Beispielsweise ermöglichen Braillezeilen blinden oder sehbehinderten Anwendern den Zugriff auf das Portal. Die Braillezeile wird in Form eines Ausgabegerätes an den Rechner angeschlossen und stellt die Zeichen, die sich auf dem Bildschirm befinden, in Brailleschrift dar.

25.2

Anwendung von Portalsystemen Portalen kommt damit zunächst der Charakter umfassender Integrationssysteme zu. Sie integrieren alle für einen Anwender re-

324

25.2 Anwendung von Portalsystemen levanten Prozesse, Daten und Systeme unter der einheitlichen Oberfläche eines einzigen Systems. Der Anwender gibt am Portal Daten ein, wertet diese aus, stößt Transaktionen an, ohne dass er im Detail wissen muss, mit welchen unterschiedlichen Anwendungen des Backend- oder des Portalanwendungsbereichs er gerade arbeitet, wie man diese startet oder darin navigiert. Hier können auch anwendungsübergreifende Prozesse abgebildet werden und verschiedene Anwender in die für sie jeweils relevanten Prozesse einbezogen werden. Dabei nutzen individuelle Anwender keineswegs das gesamte Portal, sondern nur jeweils den für sie spezifischen relevanten Ausschnitt an Daten, Anwendungen und Prozessen, der ihnen über Personalisierung und Anwenderrollen zur Verfügung gestellt wird. Mit der Möglichkeit, im Rahmen der Portalanwendungen auch Anwendungssysteme zu integrieren, sind Portale allerdings nicht nur der Integrations-, sondern gleichermaßen auch der Anwendungsschicht einer Architektur zuzuordnen. Für Anwender bietet sich damit zunächst die Möglichkeit einer umfassenden Deckung ihrer Informationsbedarfe, die je nach Anwenderkategorie von Managementinformationen aus einem Data Warehouse (bei Anwendung durch Führungskräfte) bis zur Visualisierung des künftigen Arbeitsplatzes (bei Anwendung durch Bewerber) reichen können. Zusätzlich zu dieser Informationsfunktion leisten Portale aus Anwendersicht auch eine Kommunikationsfunktion, die in umfangreichen Möglichkeiten des Austauschs und der Interaktion verschiedener, räumlich getrennter Portalanwender besteht. Eine Aktionsfunktion bezieht sich dann auf konkrete Handlungsoptionen von Portalanwendern, die unter Rückgriff auf die entsprechenden Anwendungen Aufgaben erledigen können. Anwendungsszenarien

Die generelle Ausrichtung von Portalen führt zu breiten Anwendungsmöglichkeiten dieser Systemkategorie in Unternehmen. Unter dem Oberbegriff »Unternehmensportal« bilden speziell das Beschaffungs- (»Lieferantenportale«) und das Vertriebsmanagement (»Kundenportale«) prominente Anwendungsbereiche (vgl. Vlachakis et al. 2005, 1ff.). Mit ƒ Self Service, ƒ HR-Portalen und ƒ Mitarbeiterportalen finden sich auch im Personalmanagement drei umfangreiche, allerdings überlappende Anwendungsszenarien für Portalsysteme. Unter Anbindung entsprechender Anwendungssysteme aus dem Backendbereich (oder unter Einbeziehung solcher Systeme als Portalanwendung) eignen sich Portalsysteme zunächst zur Reali325

25

Portalsysteme sierung von Varianten eines Self Service (vgl. auch Kap. 2). Etwa kann mit der Kombination aus einem (per se nicht webfähigen) Beschaffungsmanagementsystem (vgl. Kap. 16) im Backendbereich und einem Portal ein Self Service für Bewerber realisiert werden, der interessierte Bewerber über Vakanzen informiert, eine selbstständige Bewerbung mit Eingabe der Bewerberdaten ermöglicht, sowie Kommunikationsmöglichkeiten mit den zuständigen HR- und Linienkräften anbietet. In analoger Weise können vielfältige Anwendungen auch im Bereich des Mitarbeiter- oder Manager Self Service realisiert werden. Die umfassenden Potenziale der Portal-Technik werden von solchen isolierten Anwendungen allerdings nur ansatzweise ausgeschöpft. Entsprechend bieten integrierte HR-Portale für Bewerber, Manager, Mitarbeiter, aber auch HR-Fachleute übergreifenden Zugang zu den jeweils relevanten Informationen, Diensten und Anwendungen des Personalmanagement. Basierend auf entsprechenden Anwenderrollen, Zugriffsrechten und Personalisierungen kann ein solches Portal die unterschiedlichen Interessengruppen und Prozesse des Personalmanagement zielgerichtet unterstützen. Natürlich wird auch die Zusammenarbeit und Kommunikation innerhalb und zwischen diesen Anwendergruppen ermöglicht. Eine besonders umfangreiche Nutzung der Potenziale findet im Rahmen von Mitarbeiterportalen (»Business-to-Employee-Portal«, »B2E-Portal«, »Workplace«) statt. Mitarbeiterportale ermöglichen Managern und Mitarbeitern nicht nur Zugriff auf Funktionalitäten des Personalbereichs entsprechend ihrer Rolle, sondern integrieren zusätzlich auch den jeweiligen Arbeitsbereich des Portalanwenders. Anwendungen, Dienste und Informationen, die ein Anwender zur Erledigung seiner täglichen Aufgaben benötigt, werden damit gleichfalls integriert, was die ebenfalls verwendete Bezeichnung »Workplace« erklärt. Strittig ist, ob neben dem Personal- und dem Arbeitsbereich auch der Privatbereich (»Personal Services«) in ein Portal aufgenommen werden soll. Solche privaten Leistungen können Unternehmen in vielfältigen Ausprägungen, wie etwa Sportnachrichten, Mitarbeiterverkauf etc., anbieten. Grundsätzlich sollen solche Dienste Anreize zur Portalnutzung schaffen und die Bildung einer portalbasierten virtuellen (Arbeits-)Gemeinschaft unterstützen. Kritiker verweisen dagegen auf die Kosten und den möglichen Verlust von Arbeitszeit aufgrund solcher Dienste. Abb. 25.3 zeigt exemplarische Informations-, Kommunikations- und Aktionsmöglichkeiten im Arbeits-, Personal- und Privatbereich eines Mitarbeiters aus dem Vertriebsbereich.

326

25.2 Anwendung von Portalsystemen Information

Kommunikation

Aktion

CRM-KnowledgeManagement Kundeninformation Produktinformation ...

e-Mail an ServiceAußendienst Conferencing mit Abteilungsleiter ...

Annahme Retour Veranlassung Reparatur Versand Ersatzgerät ...

Personalbereich

Seminarangebot Stellenbörse Kantinenangebot Einsatzplan ...

e-Mail an Personalreferent Shared Browsing im Seminarkatalog ...

Seminarbuchung interne Bewerbung Reiseantrag E-Learning ...

Privatbereich

Sportergebnisse Nachrichten Kulturangebote Kleinanzeigen ...

Sport-Chat Forum zum lokalen Kindergarten ...

Buchen einer (Privat-)Reise E-Shopping E-Banking ...

Arbeitsbereich

Abb. 25.3: Anwendungsfunktionen und Anwendungsbereiche eines Mitarbeiterportals Unabhängig von der konkreten Anwendungsvariante bilden Portale damit ohne Frage eine zentrale Basistechnik des e-HRM, die die Leistungsfähigkeit reiner Browsersysteme erheblich ausdehnt. Entsprechend werden auch zentrale Vorteile wie die Reduzierung manueller Aktivitäten, Reduktion der Datenredundanz, effiziente Informationsverteilung, Integration von Geschäftsprozessen mit kürzeren Prozesslaufzeiten u.a.m. erwähnt. Verbreitung

Die besondere Bedeutung der Portaltechnik belegen auch empirische Untersuchungen zur Verbreitung von Mitarbeiterportalen, die einen Diffusionsgrad von 40-60% ergeben, während viele Unternehmen eine Anwendung von Portalsystemen zumindest planen (vgl. Gurzki & Özcan 2003). Gleichzeitig zeigt eine weitere Studie eine bemerkenswert positive Beurteilung von Portalen durch Mitarbeiter (vgl. Schäffer-Külz 2005). Die Bedeutung von Portalsystemen dürfte im Personalmanagement in Zukunft daher noch zunehmen.

327

26

Voice Response-Systeme (Interactive) Voice Response (IVR)-Systeme ([interaktives] Sprachantwort-System) sind Anwendungen, die Telefone als Endanwendergeräte mit Anwendungssystemen verbinden. Neben einfacheren Voice Response-Systemen, die in Interaktion mit einem Anwendungssystem enger begrenzte, strukturierte Aufgaben – etwa das Buchen von Arbeitszeiten per Telefon – unterstützen, wird derzeit auch die Variante umfassenderer Voice-Portale (Sprachportal, »Enterprise Voice Portal«) propagiert.

Architektur und Funktionalität von Voice Response-Systemen Voice Response-Systeme umfassen üblicherweise eine Sprachanwenderschnittstelle, eine Spracherkennungs- sowie eine Sprachausgabekomponente, eine Ablaufsteuerung und gegebenenfalls verschiedene interne Services (vgl. Abb. 26.1). Voice Response-System

Festnetz

Mobilnetze

Spracherkennung

Sprachausgabe

Ablaufsteuerung

(Grafische) Anwenderschnittstelle Sprachanwenderschnittstelle

26.1

ServicesKomponente

BackendSystemn Internet ... BackendSystem1

Abb. 26.1: Idealtypische Architektur von Voice Response-Systemen Die Sprachanwenderschnittstelle dient der Interaktion des Systems mit den Telefonen der Anwender. Die Spracherkennungskomponente setzt die empfangenen Sprachnachrichten in eine maschinenlesbare Form um. Die Ablaufsteuerung ordnet die erhaltenen Inputs ein, leitet sie an korrespondierende Backendsysteme und/oder interne Services weiter, empfängt Rückmeldungen aus diesen Komponenten und leitet diese wiederum an die 329

26

Voice Response-Systeme Sprachausgabekomponente weiter. Die Sprachausgabekomponente setzt das empfangene Signal in eine Sprachnachricht um, die von der Sprachanwenderschnittstelle dann an das entsprechende Telefon übermittelt wird. Aufgrund der engen Interaktionen werden Spracherkennungs- und Sprachsynthesekomponente teilweise auch der Sprachanwenderschnittstelle zugerechnet. In umfassenderen Sprach-Portalen bietet die Service-Komponente verschiedene zusätzliche Dienste wie etwa ein sprachbasiertes Browsen an. Eine zusätzliche grafische Anwenderschnittstelle ermöglicht schließlich Anwendern und Administratoren den nichtsprachbasierten Zugang zum System.

26.1.1

Sprachanwenderschnittstelle Die Sprachanwenderschnittstelle (in Anlehnung an den Begriff »GUI« auch »Voice User Interface [VUI]«) bezeichnet die (Haupt-) Schnittstelle des Systems zum Anwender, die den einheitlichen Zugriff auf interne oder extern angebundene Informationen, Dienste oder Anwendungen ermöglicht (vgl. Goldmann et al. 2001, 230f.). Nachdem ein Anrufer von der VUI identifiziert wurde, produziert die VUI unter Verwendung der Sprachsynthesekomponente eine natürlichsprachige Eingabeanforderung und wartet auf einen korrespondierenden Input des Anrufers. Dieser Input kann per Tastatursteuerung und/oder Sprachsteuerung erfolgen.

Tastatursteuerung

Analog zur Rechnertastatur ermöglicht zunächst die Verwendung der Telefontastatur entsprechende Eingaben in das System. Auf natürlichsprachige Eingabeaufforderungen mit Erläuterung der jeweiligen Tastenbelegung reagiert der Anwender durch Drücken der entsprechenden Taste(n). Dass Standardtastaturen inzwischen neben reinen Ziffern zunehmend auch mit drei bis vier Buchstaben belegt sind, erweitert dabei das Spektrum möglicher Eingaben auch auf den Textbereich. Werden Voice ResponseSysteme dabei ausschließlich per Tastatur bedient, entfällt die Notwendigkeit einer Spracherkennungskomponente. Allerdings bleiben die Eingabemöglichkeiten per Tastatur im Vergleich zu einer Sprachsteuerung eingeschränkt. Weiter kann bei reiner Tastatursteuerung nicht von einem vollwertigen Voice ResponseSystem ausgegangen werden, da das System gar nicht auf die Sprache des Anwenders reagiert.

Sprachsteuerung

Eine Sprachsteuerung erlaubt dagegen letztlich beliebige natürlichsprachige Ausdrücke zur Bedienung des Systems zu verwenden. Insbesondere die Verwendung »sprechender« bzw. selbster-

330

26.1 Architektur und Funktionalität von Voice Response-Systemen klärender Terminologie führt dabei zu einer Vereinfachung für den Anwender. Das notorisch unkomfortable »Abarbeiten« verzweigter, verbal präsentierter Menühierarchien per Tastendruck entfällt dann, weil ein Anwender durch Sprechen eines entsprechenden Befehls, wie etwa »Kommt-Buchung«, direkt zur entsprechenden Transaktion springen kann. Neben der Eingabe übernimmt das Voice User Interface auch die Übermittlung von Ergebnissen der Sprachsynthesekomponente an den Anwender, die dann regelmäßig in natürlichsprachiger Form erfolgt.

26.1.2

Spracherkennungskomponente Die Spracherkennungskomponente (»Automatic Speech Recognition [ASR]«, »Speech Recognition Engine«) dient der Umwandlung der gesprochenen Sprache des Anwenders in maschinenlesbare Zeichenketten.

Umfang

Nach dem Umfang der erkennbaren Sprache kann zwischen diskreter und kontinuierlicher Spracherkennung unterschieden werden. Die diskrete Spracherkennung bezieht sich auf die Erkennung einzelner feststehender Worte oder mehrerer feststehender Worte, zwischen denen deutliche Pausen eingehalten werden. Neuere Spracherkennungssysteme richten sich auch auf die kontinuierliche Spracherkennung, die sich auf fließende Sprache richten. Neben der rein technischen Erkennung bilden allerdings die Kontextabhängigkeit der Bedeutung einzelner Begriffe, der möglicherweise sehr große Umfang des Anwender-Wortschatzes sowie die Existenz von Homophonen (gleiche Aussprache von Worten verschiedener Bedeutung) Probleme der kontinuierlichen Spracherkennung. Zur Vermeidung hoher Fehlerquoten findet daher oft die diskrete, auf einen kleinen Befehlswortschatz beschränkte Spracherkennung Anwendung.

Anwenderbezug

Nach dem Bezug zum individuellen Anwender können Spracherkennungskomponenten sprecherunabhängig (statisch) oder sprecherabhängig (dynamisch) ausgestaltet sein (vgl. Goldmann et al. 2001, 231). Statische Spracherkennungskomponenten verfügen über einen feststehenden nicht veränderbaren Wortschatz, der für alle Anwender gleich ist. Dynamische Spracherkennungskomponenten erlauben es Anwendern und/oder Systemadministratoren dagegen, die Spracherkennung an individuelle Bedarfe anzupassen, indem das System beispielsweise auf individuelle Befehle und/oder benutzerspezifische Aussprachen hin »trainiert« werden kann. Im letzteren Fall steht dem Vorteil einer individuellen Anpassbarkeit und einer i.d.R. besseren Erkennungsquote 331

26

Voice Response-Systeme ein deutlich höherer Aufwand bei der Implementierung gegenüber. Neben einer eher kleineren Anzahl von Anwendern setzt die dynamische Spracherkennung damit auch voraus, dass potenzielle Anwender vorab bekannt sind. So ist etwa eine dynamische Spracherkennung im Rahmen der Vorauswahl von Bewerbern aus beiden Gründen von vornherein ausgeschlossen.

Kontextsensitivität Schließlich lässt sich nach dem Ausbaustand der Spracherkennung nicht-kontextsensitive und kontextsensitive Spracherkennung unterscheiden (vgl. Bamberger & König 2004, 263). Als ausgereiftere Variante setzt eine kontextsensitive Spracherkennung empfangene Sprachnachrichten in Relation zu zuvor stattgefundenen Erkennungsvorgängen. Hat ein Anwender etwa die Veranstaltungstermine für eine spezifische Sprachschulung im Mai abgefragt verwendet ein kontextsensitives System diese Information, um eine weitere Frage »Und im Juni?« als Frage nach den Veranstaltungsterminen für die fragliche Schulung im Monat Juni zu kategorisieren. Bei nicht kontextsensitiven Systemen hätte ein Anwender die Anfrage entsprechend komplett neu zu stellen.

26.1.3

Sprachausgabekomponente Die Sprachausgabekomponente dient der Ausgabe einer Sprachnachricht, die von der Sprachanwenderschnittstelle dann an das entsprechende Telefon übermittelt wird. Generell kann eine Sprachausgabe durch Sprachwiedergabe und/oder Sprachsynthese erfolgen (vgl. Bamberger & König 2002, 262f.).

Sprachwiedergabe Die Sprachwiedergabe bedient sich vorweg produzierter Spracheinheiten (»Voice Prompts«), die von Sprechern gesprochen und aufgezeichnet und dann von der Sprachausgabekomponente an entsprechender Stelle wiedergegeben werden. Dies setzt voraus, dass alle notwendigen Sprachausgaben bereits im Voraus bekannt sind. Entsprechend kommt die reine Sprachwiedergabe eher für einfache und begrenzte Anwendungen in Frage. Anwendungen, die die sprachliche Wiedergabe von vorab unbekannten Inhalten implizieren – etwa das »Vorlesen« empfangener e-Mails – können durch Sprachwiedergabe daher nicht unterstützt werden, sondern bedürfen einer Sprachsynthese. Sprachsynthese

332

Die Sprachsynthese (»Text to Speech [TTS]-System«) verwendet zunächst Algorithmen, die Texte in kleinste Lauteinheiten (»Phoneme«) zerlegen und diese dann zu Wörtern und Sätzen zusammenfügen und ausgeben. Neben künstlich erzeugten Lauten können Phoneme dabei auch auf aufgenommener menschlicher

26.1 Architektur und Funktionalität von Voice Response-Systemen Sprache beruhen. Die Menge so aneinander gereihter Phoneme ist dann mittels zusätzlicher Algorithmen mit einer geeigneten Sprachmelodie und einem Sprachrhythmus zu versehen, um für den Anwender verständlich zu werden. Einfache Algorithmen ordnen gebildete Worte beispielsweise unterschiedlichen Kategorien zu, die dann unterschiedlich betont werden. Komplexere Algorithmen bemühen sich mittlerweile, die komplette Satzstruktur zu erfassen und diese zur Grundlage für die Bildung von Rhythmus und Melodie zu machen (vgl. Bamberger & König 2002, 262). Die Verwendung der Sprachsynthese ermöglicht entsprechend die Umwandlung auch längerer und vorab unbekannter Texte bzw. strukturierter Daten in Sprache.

26.1.4

Ablaufsteuerung Die Ablaufsteuerung dient generell der internen Koordination der übrigen Komponenten des Voice Response-Systems sowie der externen Koordination der Komponenten mit Backendsystemen (vgl. Goldmann et al. 2001). Beispielsweise sind die internen Komponenten Spracherkennung und Sprachausgabe zu koordinieren, um das System in die Lage zu versetzen auf Einwände bzw. sprachliche Unterbrechungen (»Barge-In«) des Anwenders zu reagieren. In diesem Fall empfängt die Spracherkennungskomponente via VUI einen entsprechenden Sprachimpuls, setzt diesen um und übermittelt ihn an die Ablaufsteuerung. Diese nimmt eine Kategorisierung der entsprechenden Daten als Unterbrechung vor, stoppt die laufende Sprachausgabe und stößt entsprechende weitere Reaktionen an (vgl. Bamberger & König 2002, 264). Des Weiteren übernimmt die Ablaufsteuerung die externe Koordination des Voice Response-Systems mit einem oder mehreren Backendsystemen. Werden Voice Response-Systeme z.B. im Arbeitszeitmanagement eingesetzt, dann hat die Ablaufsteuerung eine telefonisch übermittelte und erkannte »KommtBuchung« als solche zu klassifizieren und an ein im Backendbereich angebundenes Arbeitszeitmanagementsystem (vgl. Kap. 14) weiterzuleiten. Ebenso sind Meldungen oder Anfragen aus dem Backendbereich wie etwa »Kommt-Buchung gespeichert« von der Ablaufsteuerung aufzunehmen und an die Sprachausgabekomponente weiterzuleiten, die diese in Sprache umsetzt und via VUI an den Anwender weiterleitet. Sind im Rahmen komplexerer Sprachportale mehrere Backendanwendungen und oder interne Services simultan in einen Prozess eingebunden, sind entsprechend alle beteiligten internen Komponenten und externen Systeme zu koordinieren. 333

26

Voice Response-Systeme

26.1.5

Serviceskomponente Mit der Weiterentwicklung einfacher Voice Response-Systeme in Richtung Voice-Portale werden zusätzlich unterschiedliche interne Dienste angeboten, die hier unter der Sammelkomponente »Services« zusammengefasst werden (vgl. z.B. Goldmann et al. 2001). Mit »VoiceXML« existiert inzwischen eine standardisierte Beschreibungssprache und Schnittstelle für solche Dienste (www.voicexml.org). Verbreitete Dienste sind beispielsweise ƒ das sprachbasierte Browsen, ƒ das sprachbasierte Mailen, ƒ das sprachbasierte persönliche Informationsmanagement oder ƒ das sprachbasierte Wählen von Telefonnummern (vgl. Goldmann et al. 2001). Ein sprachbasiertes Browsen im Intra- oder Internet (»Voice Browsing«, »Speech Browsing«) ermöglicht den Zugang zu entsprechenden Inhalten über Telefon. Eine erste Variante sprachbasierten Browsens bezieht sich auf spezifische »Sprachseiten«, die bereits aus Sprachdateien bestehen, die explizit für eine Anwendung in Sprachportalen konzipiert wurden und dann über die Serviceskomponente und VUI an den Anwender weitergeleitet werden. In einer zweiten Variante ist aber auch das Abhören konventionell-visueller Internetseiten möglich. Dieser Dienst führt den Anrufer über bestimmte Schlüsselbegriffe zu den entsprechenden Webseiten. Die Textinhalte dieser Seiten werden dann per Sprachsynthesekomponente in gesprochene Worte umgewandelt. Lange Texte bedingen dabei allerdings entsprechend lange Abhörzeiten, während Grafiken und Animationen generell nicht übertragen werden können. Sprachbasiertes Mailen (»Voice Mail«) ermöglicht das Senden und Empfangen von Textnachrichten. So können Sprachnachrichten umgewandelt und an spezifizierte Empfänger als Textnachricht übermittelt werden. Umgekehrt können auch empfangene Textnachrichten in gesprochener Form ausgegeben werden. Auch die persönliche Informationsverwaltung wie Adressbücher und Terminkalender können sprachbasiert verwaltet werden. Dies bezieht sich auf das Vornehmen von Eintragungen und das Abhören entsprechender Einträge. In Verbindung mit solchen Diensten wird weiter auch das sprachbasierte Wählen von Telefonnummern (»Voice Activated Dialing«) angeboten. Mit der Integration solcher interner Dienste nehmen Voice Response-Systeme bzw. Sprachportal ebenfalls ei-

334

26.2 Anwendung von Voice Response-Systemen ne hybride Stellung zwischen reinem Präsentations- und eigenständigem Anwendungssystem ein.

26.1.6

Grafische Anwenderschnittstelle Obwohl die Sprachanwenderschnittstelle die »Hauptschnittstelle« zu Voice Response-Systemen darstellt, existiert üblicherweise zusätzliche auch eine konventionelle grafische Anwenderschnittstelle in Form eines Webbrowsers. Sie bietet Anwendern, aber auch Administratoren Möglichkeiten alternativ zur Sprach-Anwenderschnittstelle individuelle Einstellungen und Abfragen vorzunehmen (vgl. Goldmann et al. 2001, 233f.). Gehen die Funktionalitäten dieser grafischen Anwenderschnittstelle über die reine Konfiguration und Anpassung des Systems hinaus, werden die Grenzen zu einem Portalsystem (vgl. Kap. 25) fließend.

26.2

Anwendung von Voice Response-Systemen Die Anwendung von Voice Response-Systemen im Personalmanagement ermöglicht mit der Etablierung personalwirtschaftlicher Self Service-Konzepte und der automatischen Weiterleitung von Anrufern (»Routing«) zwei zentrale Anwendungsszenarien, die auch kombiniert zum Einsatz kommen können.

Self Service

Eine erste Anwendungsvariante liegt in der Etablierung eines sprachbasierten personalwirtschaftlichen Self Service-Konzeptes. Analog zu Portalsystemen (vgl. Kap. 25) oder Browsersystemen (vgl. Kap. 28) können Voice Response-Systeme als sprachbasierte Schnittstellen für verschiedene Anwendergruppen dienen. Grundlegende Anwendungen binden zunächst ein Backendsystem an, um einfache Dateneingabe- und Datenausgabeaktivitäten abzubilden. Beispielsweise hat die Anbindung von Arbeitszeitmanagementsystemen (vgl. Kap. 14) zur Durchführung telefonischer Zeitbuchungen eine gewisse Verbreitung erfahren. Allerdings lassen sich insbesondere in den Vereinigten Staaten auch anspruchsvollere voice response-basierte Self Service-Varianten wie etwa die Vorauswahl geeigneter Bewerber oder das individuelle Zusammenstellen von Vergütungsbestandteilen mittels Voice Response abgebildet werden (vgl. Guy 2000). Mit der inzwischen bestehenden Möglichkeit zur Bildung von Sprachportalen gilt grundsätzlich, dass zumindest von technischer Seite der Aufbau umfassender sprachbasierter Self Service-Systeme, die auf der Basis mehrerer angebundener Backendsysteme und interner Services zentrale Funktionen anbieten, nichts im Wege steht.

335

26

Voice Response-Systeme

Routing

Eine zweite Anwendungsvariante besteht in der Weiterleitung (»Routing«) von Anrufern in Service Centern (vgl. Kap. 2 und 27) bzw. in konventionellen Personalabteilungen. Zentrale Funktionen liegen dann in der Identifikation von Anrufern und deren automatisierter Weiterleitung an geeignete und zuständige Sachbearbeiter im Service Center bzw. in der Fachabteilung »Personal« (»Skill Based Routing«). Ebenso können bei Überlast des Service Centers oder bei Anrufen außerhalb der Geschäftszeiten Voice Response-Systeme als »intelligente Anrufbeantworter« verwendet werden. Die Anwendungsvarianten als Self Service-System und Zubringer für ein Service Center können selbstverständlich auch kombiniert werden, wenn einfachere Aufgaben automatisiert abgearbeitet werden und eine Weiterleitung an einen entsprechenden HR Sachbearbeiter erst beim Auftreten von Problemen oder der Bearbeitung komplexerer Aufgaben erfolgt. Besondere Vorteile von Voice Response-Systemen liegen in der ubiquitären Erreichbarkeit, speziell bei Verwendung von Mobiltelefonen. Entsprechend können so auch Mitarbeiter mit ständig wechselnden Einsatzorten oder Mitarbeiter ohne Zugang zu einem Arbeitsplatzrechner in ein Self Service-Konzept integriert werden. Allerdings muss die entsprechende Umgebung frei von störenden Hintergrundgeräuschen sein und je nach Anwendung ggf. auch vertrauliche Spracheingaben zulassen. Weiter sind an die Ausgestaltung der Sprachschnittstelle hohe Anforderungen zu stellen. Erfahrungen mit unkomfortablen Anwendungen, bei denen umfangreiche Hierarchiebäume durch Sprechen von Zahlen oder Drücken entsprechender Telefontasten langwierig »abzuarbeiten« sind, dürften verbreitet zu Unzufriedenheit mit einfachen Voice Response-Systemen geführt haben (vgl. Schuhmacher et al. 1995). Gerade von umfangreicheren Sprachportalen mag man sich durch gesteigerte Funktionalität und komfortablere Anwenderführung eine Verbesserung der Akzeptanz erwarten. Funktional dürfte jedoch stets eine gewisse Lücke zu »grafischen« Portalen verbleiben, da visuelle Information – etwa die Darstellung eines individuellen Monatseinsatzplans per Gantt-Diagramm (vgl. Kap. 8) – nur eingeschränkt und umständlich in Sprache umgesetzt werden kann.

Verbreitung

336

Derzeit existiert kein empirischer Aufschluss über die Verwendung von Voice Response-Systemen in Deutschland. Regional dürften Voice Response vor allem in den Vereinigten Staaten angewendet werden, wenngleich auch dort auf eher verhaltenem Niveau (vgl. Florkowski & Olivas-Luján 2006). Inwieweit die Ausdehnung des Funktionsumfangs im Übergang auf Sprachportale

26.2 Anwendung von Voice Response-Systemen zu einer (regionalen) Ausdehnung der Anwendung beiträgt, bleibt abzuwarten.

337

27

Service Center-Systeme (HR-) Service Center-Systeme (Shared Service Center [SSC]-Systeme, »[Employee] Interaction Center [EIC]-Systeme«) sind Systeme, die spezialisierte Organisation(seinheit)en zur mediatisierten Bearbeitung administrativer Personalfunktionen systematisch unterstützen.

27.1

Architektur und Funktionalität von Service Center-Systemen Service Center-Systeme umfassen üblicherweise Datenhaltungskomponenten mit Service Center-Agenten, eine Wissensdatenbank und eine Anfragehistorie. Zu den Funktionen dieser Systemart gehören eine Kommunikations-, eine Ablaufsteuerungsund eine Analysekomponente (vgl. Abb. 27.1). Service Center-System Anwenderschnittstelle Schnittstelle Telekommunikation

Kommunikation

Agenten

Ablaufsteuerung

Wissensdatenbank

Analyse

Anfragehistorie

Anwendungssysteme

Abb. 27.1: Idealtypische Architektur von Service Center-Systemen Die Datenhaltungskomponente enthält Daten zu Service CenterAgenten, eine Wissensdatenbank und eine Abfragehistorie. Eine Kommunikationskomponente vereint verschiedene zur Verfügung stehende Telekommunikationsdienste zu einem »Contact Center« und unterstützt so die Kommunikation zwischen den Agenten und den anfragenden Personen. Eine Ablaufsteuerungskomponente steuert die Verteilung und die Abarbeitung der ein339

27

Service Center-Systeme gehenden Anfragen. Eine Analysekomponente ermöglicht die Auswertung eingegangener Anfragen und deren Bearbeitung und damit die Kontrolle der Service Center-Organisation.

27.1.1

Datenhaltungskomponenten

Agentendatei

Zunächst sind Daten zum Personal des Service Centers, den so genannten »Agenten« notwendig, die in einer Datenhaltungskomponente abzulegen sind. Insbesondere wird hierbei auf das Qualifikationsprofil einzelner Agenten abgezielt. Dies beinhaltet aufbauend auf spezifischen personalbezogenen Kenntnissen und Fähigkeiten insbesondere die generelle Einsatzfähigkeit des Agenten auf verschiedenen Positionen und »Leveln« des Service Centers. Anhand dieser Daten können die eingehenden Anfragen automatisiert an den bestmöglich qualifizierten, freien Agenten für diese Anfrage weitergeleitet werden.

Wissensdatenbank

Eine zentrale datenhaltende Komponente besteht dann in einer Wissensdatenbank. In ihr werden elektronische Leitfäden und Lösungsskizzen (»Skripte«) abgelegt, die eine systematische Bearbeitung unterschiedlicher Anfragen ermöglichen. Solche Skripte steuern den Ablauf einer Anfrage und sind im Sinne vorbereiteter Bildschirmmasken häufig interaktiv realisiert. Etwa kann ein Agent bei einem Anruf eines Mitarbeiters, der Probleme mit seiner Abrechnung hat, ein entsprechendes interaktives Skript aufrufen, das ihn strukturiert durch die Bearbeitung führt und dabei ggf. auch entsprechende Eingaben von ihm verlangt. Skripte weisen damit eine enge Korrespondenz zu den zugrunde liegenden personalwirtschaftlichen Prozessen und entsprechend zu angebundenen personalwirtschaftlichen Systemen auf. Dementsprechend sind standardisierte personalwirtschaftliche Geschäftsprozesse eine Voraussetzung für den Service Center-Betrieb. Häufig werden daher bei Einführung von Center-Konzepten die abzuarbeitenden Geschäftsprozesse bei der Einrichtung eines Service Centers analysiert und reorganisiert sowie gegebenenfalls sogar an die Service Center-Arbeitsorganisation angepasst. Insbesondere wenn Service Center-System und Anwendungssystem vom selben Hersteller stammen, können Skripte auch direkt aufgerufene Masken des entsprechenden Anwendungssystems umfassen. Skripte stellen damit neben der Unterstützung des Agenten und der Vermeidung möglicher Fehler auch die einheitliche Bearbeitung gleichartiger Anfragen sicher. In Ergänzung der Skripte werden im Rahmen von Wissensdatenbanken i.d.R. auch Textvorlagen bzw. -bausteine angeboten, die bei der Bearbeitung von Standardabfragen notwendig sind. Zusätzlich denkbare allgemeine Richtli-

340

27.1 Architektur und Funktionalität von Service Center-Systemen nien informieren über Abläufe wie etwa das Führen von Telefonaten. Such- und Hilfefunktionen erleichtern das Auffinden relevanter Informationen in der Wissensdatenbank. Die Wissensdatenbank ist daher im Rahmen eines Customizing zu »befüllen«. Teilweise werden auch vorgefertigte Referenzskripte angeboten, die modifiziert oder unmodifiziert übernommen werden können. Die Bestände der Wissensdatenbank können dann im weiteren Verlauf korrigiert, verbessert und ergänzt werden. Anfragehistorie

Die Anfragehistorie stellt einen weiteren Teil der Datenhaltungskomponente dar. Dieser speichert sowohl technische als auch inhaltliche Daten der eingegangenen Anfragen. Aus technischer Sicht werden hier z.B. Angaben zum Kontaktmedium, zum Zeitpunkt der Anfrage und zur Dauer der Bearbeitung festgehalten. Wird zur Bearbeitung einer Anfrage auf weitere Anwendungssysteme zugegriffen, wird auch das entsprechende Anwendungssystem sowie Art und Dauer des Zugriffs protokolliert. Diese Daten dienen der zeitgleichen oder zeitversetzten Analyse und Steuerung der Service Center-Organisation im Allgemeinen und einzelner Agenten bzw. Gruppen von Agenten im Besonderen. Aus inhaltlicher Sicht werden neben der Person des Anfragenden, Art und Inhalt des Anliegens, der zugehörige Service Level, der aktuelle Bearbeitungsstatus inklusive bereits abgearbeiteter und noch abzuarbeitender Aufgaben und Bearbeitungskommentare abgelegt. Die entsprechenden Daten müssen dabei i.d.R. nicht eigens durch den Agenten abgespeichert werden, sondern können im Sinne einer Protokollierung des Service Center-Geschehens durch die Ablaufsteuerung automatisiert erzeugt und abgelegt werden. Anhand dieser Anfragehistorie kann der ganze Prozess einer Anfrage verfolgt und bei Bedarf auch arbeitsteilig durch verschiedene Agenten des Service Centers bzw. zusätzlich durch Spezialisten der Fachabteilung »Personal« bearbeitet werden. Auf diese Weise entsteht eine komplette Kontakthistorie für jeden Anfragenden, die auch Doppelbearbeitungen von Anfragen aufgrund von »Answer Shopping« vermeidet.

27.1.2

Kommunikationskomponente Service Center sollen Mitarbeitern Kontakte zum Personalbereich über verschiedene »Kanäle« (z.B. per Telefon, Fax und e-Mail) ermöglichen. Entsprechend ist eine Kommunikationskomponente notwendig, die im Sinne eines »Multi Channel-Management« eine einheitliche Kommunikation über heterogene Kanälen ermöglicht. Idealerweise werden dazu dem Agenten alle Anfragen bzw. Kontakte unabhängig vom gewählten Kanal durch das Service 341

27

Service Center-Systeme Center-System auf einer einheitlichen Oberfläche angezeigt und verwaltet. Dieses Zusammenfassen verschiedener Kommunikationskanäle erlaubt Mitarbeitern, sich auf unterschiedlichen Wegen an das Service Center zu wenden. Gleichzeitig erlaubt es den Agenten trotz heterogener Kanäle stets den Überblick über alle Kontakte zu behalten. Hierzu sind nicht nur Schnittstellen zur Hard- und Software der jeweiligen Telekommunikationsdienste notwendig, sondern auch eine Verbindung zur Ablaufsteuerungskomponente des Systems, welche die informationstechnische und medienbruchfreie Verknüpfung von Informationsund Kommunikationstechnologie ermöglicht (vgl. Helber et al. 2004). Vorfindbare Systeme unterscheiden sich nach Anzahl und Art anbindbarer Kommunikationskanäle. Neben der in Service Centern zentralen ƒ Telefonie werden teils weiter auch ƒ Telefax, ƒ Interactive Voice Response, ƒ e-Mail und ƒ Self Service unterstützt. Die Unterstützung weiterer Kommunikationskanäle wie etwa von »Chats« oder »SMS« lässt sich dagegen nur sehr vereinzelt belegen.

Telefonie

Da Service Center-Systeme historisch oft Weiterentwicklungen ehemaliger Call Center-Systeme darstellen, kommt der Telefonie als Kontaktmedium wesentliche Bedeutung zu. Ermöglicht wird der Telefonkontakt über Computer Telephony Integration (CTI), die es dem Agenten ermöglicht, aus dem Service Center-System heraus Telefongespräche entgegenzunehmen oder zu führen. Entsprechend können eingehende (»Inbound«) und i.d.R. auch ausgehende (»Outbound«) Telefonate realisiert werden, wobei Inbound-Anrufe die vorherrschende Variante darstellen dürften. Outbound-Telefonaktionen zu Marketing- oder Forschungszwecken dürften im Personalmanagement eher selten sein. Weiter sind auch Rückruffunktionalitäten, insbesondere zum Abbau von Anrufspitzen oder zur Bearbeitung von Anfragen durch Spezialisten üblich.

IVR

Interactive Voice Response (IVR) ermöglicht im Zusammenhang mit eingehenden Anrufen einen computergesteuerten Sprachdialog mit dem Anrufer. Dabei kann ein Anrufer über Sprache und/oder Tastatur im Sinne eines telefonbasierten Self Service gewisse Eingaben machen oder einfachere sprachbasierte Auskünfte automatisiert erhalten. Ebenso kann IVR verwendet wer-

342

27.1 Architektur und Funktionalität von Service Center-Systemen den, um Anrufer über Spracherkennung oder Tastatureingabe im Vorfeld eines Telefonats mit einem Agenten zu identifizieren und einem für die konkrete Anfrage zuständigen Agenten weiterzuleiten (vgl. vertieft Kap. 26). Telefax

Ähnlich wie telefonische Anfragen können auch eingehende Telefaxe bearbeitet werden. Eingehende Faxnachrichten werden in ein Graphikformat transferiert und stehen dem Anwender dann zur Anzeige am Bildschirm zum Ausdruck oder zur Weiterleitung per e-Mail zur Verfügung. Neben dem Empfang können Faxe auch versendet werden, um dem Mitarbeiter entsprechende Dokumente zu übermitteln. Neben von Agenten angestoßenen, ausgehenden Faxnachrichten können über »Fax on Demand« oder »Fax Back«-Funktionen auch durch den Mitarbeiter per Telefonanruf oder Aufruf aus einem Self Service-System Faxnachrichten abgerufen werden.

Self Service

Entstehen im Rahmen webbasierter Self Service-Anwendungen Fragestellungen, die nicht in der direkten Interaktion zwischen Mitarbeiter und Self Service-Anwendung geklärt werden können, kann die Bearbeitung der entsprechenden Aufgabe an das Service Center-System weitergeleitet werden. Dazu können in der Self Service-Anwendung Telefonnummern, Faxnummern und/ oder e-Mail Adressen bekannt gegeben oder ein »Call-Back-Button« für einen gewünschten Rückruf seitens des Service Centers angeboten werden. Teilweise können aus dem Self Service-System heraus automatisierte Meldungen an das Service Center generiert werden. Eine so realisierbare Kombination von Self Service und Service Center kann das Service Center entlasten und entsprechend Kosten sparen (vgl. auch Kap. 2).

e-Mail

Die e-Mail-Funktion trägt der Tendenz zur intensiven Nutzung internet-basierter Kommunikation Rechnung. E-Mail-Anfragen an das Service Center haben gegenüber telefonie- oder telefaxbasierten eingehenden Anfragen den Vorteil, dass sie direkt in elektronischer Form vorliegen und ebenso ausgewertet, bearbeitet und weitergeleitet werden können. Dabei können über Anhänge beliebige Dokumente mit geliefert werden.

Schriftverkehr

Konventioneller, aus papierbasierten Briefen und Dokumenten bestehender Schriftverkehr muss zunächst eingescannt werden und kann in einigen Systemen als elektronisches Dokument verfügbar gemacht werden (vgl. auch Kap. 6).

343

27

Service Center-Systeme

27.1.3

Ablaufsteuerungskomponente Die Ablaufsteuerung verbindet die Telekommunikationskomponenten, die im System hinterlegten Datenhaltungskomponenten sowie die an das System angebundenen Personalsysteme. In Interaktion mit diesen Komponenten dient die Ablaufsteuerung ƒ der Identifikation von anfragenden Personen, ƒ der Zuordnung von Anfragen zu Agenten sowie speziell ƒ der Steuerung des Bearbeitungsprozesses.

Identifikation

Gehen über die Kommunikationskomponente Anfragen ein, so zielt die Ablaufsteuerung zunächst auf eine automatisierte Identifikation der anfragenden Person. Im Falle von Telefonie und Telefax kann eine solche Identifikation – je nach verwendetem Netz – über die Telefon- bzw. Faxnummer erfolgen. Entsprechend ist bei e-Mails eine Identifikation über die Mailadresse des Absenders möglich. Konventionelle papierbasierte Anfragen müssen dagegen beim Einscannen indexiert oder bei der Dateneingabe einer entsprechenden Person zugeordnet werden. Wie erwähnt, werden teils auch IVR-Komponenten zur Identifikation per Sprachdialog oder Tastatureingabe vorgeschaltet. Nach einer automatisierten Identifikation zeigt die Ablaufsteuerung zunächst die identifizierte Person an. Ist eine automatisierte Identifikation nicht möglich, so ist dies vom Agenten etwa durch mündliche Abfrage der Personalnummer o.ä. vorzunehmen.

Zuordnung

Um im Service Center eingehende Anfragen zeitnah und qualifiziert bearbeiten zu können, unterstützt die Ablaufsteuerung die Zuordnung eingehender Anfragen zu den Agenten des Centers. Diese Zuordnungsaufgabe ist insbesondere bei telefonischen Anfragen relevant. Entsprechend werden Anrufe über »Automatic Call Distribution (ACD)« (auch Automatic Call Sequencer [ACS] oder Incoming Call Management [ICM]) auf die Agenten verteilt. Die Zuordnung eingehender Anrufe erfolgt nach bestimmten einstellbaren Regeln. Etwa vermittelt das »Longest Idle«-Prinzip einen eingehenden Anruf an den Agenten, dessen letztes Telefonat am längsten zurückliegt u.a.m. Sind in einem Center heterogene Agenten tätig – etwa Generalisten für allgemeine Anfragen und Spezialisten für spezielle Aufgaben – dann kann eine Verteilung unter Rückgriff auf die Agentendatei zusätzlich auch nach Eignung erfolgen (»Skill Based Routing«). Dazu ist allerdings erneut per vorgeschaltetem IVR eine Vorkategorisierung nach Anliegen notwendig (vgl. auch Kap. 26). Bei vollständiger Auslastung übernimmt die Ablaufsteuerung auch ein Warteschleifenmanagement (»Queing«). Um entstehende Wartezeiten für den Anru-

344

27.1 Architektur und Funktionalität von Service Center-Systemen fer zu überbrücken, können ihm Musik, Informationen und Zwischenansagen (z.B. Stelle in der Warteliste, noch zu wartende Zeit) präsentiert werden. Eine teure und daher seltene Variante bilden so genannte »Queue Jockeys«, die ein Life-Programm mit Musik und Ansagen bieten (vgl. Wiencke & Koke 1997). Eine weitere Möglichkeit, eingehende Anrufe bei hoher Auslastung aufzufangen, ist die Voice Mail-Funktion. Diese hat wie ein Anrufbeantworter die Aufgabe, die eingehenden Anfragen aufzuzeichnen. Dabei werden auch Datum, Uhrzeit, gewählte Rufnummer und die Rufnummer des Anrufers automatisch registriert. Die aufgezeichneten Nachrichten können den Agenten später über Telefon oder über den Bildschirm übermittelt werden. Letzteres bietet den Vorteil, dass anstehende Anfragen aufgelistet und nach Priorität abgearbeitet bzw. an freie Agenten verteilt werden können. Weitere Funktionen steuern die Zuordnung neuer Aufgaben nach Beenden des Telefonats, wobei grundsätzlich zwischen sofortiger Wiederverfügbarkeit oder der Notwendigkeit von Nachbearbeitungszeiten unterschieden wird. Ist ein Agent zur Bearbeitung einer Nachfrage bestimmt, werden gleichzeitig mit der Zuordnung die Kontakthistorie der identifizierten Person (soweit vorhanden) sowie gegebenenfalls zugehörige Daten aus angebundenen Anwendungssystemen geladen und dem Agenten angezeigt. Dies ermöglicht es einem Agenten, etwa im Fall eines Telefonanrufs sich noch vor oder während der Annahme des Anrufs über die Person, bisherige Kontakte und ggf. noch laufende Anfragen zu orientieren. Der Agent ist damit sofort auskunftsfähig, auch wenn er selbst bisher nicht mit der entsprechenden Person und Anfrage betraut war. Neben der Zuordnung von Telefonaten können teils auch eingehende e-Mails über Text Mining (vgl. Kap. 12) nach Inhalten kategorisiert und einem entsprechenden Agenten bzw. einer Agentenkategorie zugeordnet werden. Steuerung

Insbesondere wird der Prozess der Abarbeitung der eingehenden Anfragen durch die Ablaufsteuerung unterstützt. Zu diesem Zweck wird sowohl auf Skripte und Inhalte der Wissensdatenbank als auch auf angebundene personalwirtschaftliche Anwendungssysteme zurückgegriffen. Art und Ausgestaltung der einzubeziehenden Skripte und externen Anwendungssysteme hängt dabei von der funktionalen Ausrichtung des Service Centers ab. Entsprechende Skripte (sowie weitere Inhalte der Wissensdatenbank) und personalwirtschaftliche Anwendungssysteme sind dabei aufeinander abgestimmt, wobei zwischen einem integrierten

345

27

Service Center-Systeme und parallelen Betrieb von Service Center-System und Anwendungssystem(en) zu unterscheiden ist. Beim integrierten Betrieb arbeiten Agenten ausschließlich mit dem Service Center-System, dessen Ablaufsteuerung entsprechende Anwendungssysteme automatisiert aufruft und entsprechende Ein- und Ausgaben im Rahmen des Skripts ermöglicht. Ein einfaches Beispiel besteht in der telefonischen Meldung eines privaten Umzugs durch einen Mitarbeiter und einer damit einhergehenden Änderung seiner Adresse. Ein Agent ruft hierzu zunächst ein entsprechendes interaktives Skript zur Adressänderung aus der Wissensdatenbank auf, das ihn strukturiert durch die Bearbeitung führt und ein Übergehen von Punkten verhindert. Im Skript eingefügte Felder ermöglichen dabei die direkte Eingabe bzw. Veränderung der entsprechenden Daten, die dann automatisiert auch im korrespondierenden Anwendungssystem so abgelegt werden. Eine alternative Lösung besteht im Einsatz eines Portalsystems zur Realisierung einer Integrationsschicht. Agenten greifen dabei von einer einheitlichen Browseroberfläche auf das Center System sowie weitere angebundene Systeme zu (vgl. Kap. 25). Insbesondere wenn mehrere Anwendungssysteme und/oder externe Dienstleistungen zu integrieren sind, werden Portalsysteme zur Realisierung einer Integrationsschicht eingesetzt. Indiziert eine Anfrage Aufgaben, die nicht (ausschließlich) im Service Center sondern (auch) durch eine zusätzliche Fachabteilung »Personal« oder durch einen externen Dienstleister abgearbeitet werden müssen, kann die Ablaufsteuerung auch entsprechende Workflows in korrespondierenden Anwendungssystemen anstoßen. Ein integrierter Betrieb ist insbesondere für zeitkritische und direkt bearbeitbare Anfragen sinnvoll, die – wie eine Adressenänderung – noch im Laufe eines Anrufes erledigt werden können. Beim parallelen Betrieb arbeitet ein Agent parallel am Service Center-System und einem oder mehreren personalwirtschaftlichen Anwendungssystemen. Die Ablaufsteuerung präsentiert auch in diesem Fall entsprechende Skripte bzw. Richtlinien zur Fallbearbeitung, wobei die jeweiligen in den Anwendungssystemen notwendigen Aktionen beschrieben werden. Allerdings sind Eingaben direkt im jeweiligen Anwendungssystem vorzunehmen und können nicht vom Service Center-System aus erledigt werden. Diese Variante kann vor allem bei nicht unmittelbar zeitkritischen Anfragen, die einen längeren, ggf. auch arbeitsteilig zu handhabenden Prozess auslösen, wie ihn etwa der Eingang einer Bewerbung in einem Beschaffungsservicecenter darstellt. Auch

346

27.1 Architektur und Funktionalität von Service Center-Systemen hier können Workflows, die externe Stellen wie ein weiteres Service Center, einen externen Dienstleister und/oder die Fachabteilung »Personal« einbeziehen, vom Agenten angestoßen werden.

27.1.4

Analysekomponente Alle über die Kommunikationskomponenten eingehenden und über die Ablaufsteuerung zugeordneten oder (teil-)bearbeiteten Anfragen werden in der Abfragehistorie protokolliert. Die Analysekomponente ermöglicht es, zur taktischen wie operativen Steuerung des Service Center-Geschehens aus diesen Daten Abfragen und Berichte zu generieren. Hierbei können wichtige Kennzahlen generiert werden, wie etwa Verteilung der Anfragen auf Kontaktkanäle, Zahl der Anrufe, (mittlere) Gesprächs- und Nachbearbeitungsdauer, (mittlere) Wartezeiten in der Warteschleife, abgebrochene Anrufe, Anrufe außerhalb der Betriebszeiten, Auslastungsgrade und Pausenzeiten von Agenten, aktueller Status von Agenten (frei vs. belegt) usw. Im taktischen Center-Management können solche Kennzahlen von der Leitung des Service Centers etwa herangezogen werden, um die Dienstgüte zu überprüfen. Für einzelne vom Center angebotene Dienste werden dazu meist Dienstgütevereinbarungen getroffen (»Service Level Agreements [SLA]«), die die Inhalte, Umfang und Ausprägung der durch das Center zu erbringenden Dienstleistung(en) detailliert spezifiziert. Entsprechend können Kennzahlen wie Anteil der in eine Warteschleife geleiteten Anrufer, Wartezeiten in der Warteschleife, Dauer der Bearbeitung einer spezifischen Anfrage zur Überprüfung der Servicequalität herangezogen werden. Die im Zeitablauf eingehenden Anrufe können auch zur Grundlage einer Personalbedarfs- und -einsatzplanung für das Center gemacht werden (vgl. auch Kap. 7 und 8). Weiter können anhand solcher Daten auch eventuelle Trends in den eingehenden Anfragen erkannt sowie die Leistung einzelner Agenten überprüft werden. Im operativen Center-Management versorgt die Analysekomponente so genannte »Supervisoren«, die die Arbeit einer Gruppe von Agenten inhaltlich überwachen und das Anfragevolumen steuern, mit Echtzeitinformationen zum aktuellen Anfragevolumen. Eingehende Anrufe und e-Mails können so permanent überwacht werden. Bei Überschreiten gewisser Schwellenwerte – wie z.B. Maximalwartezeiten in der Warteschleife – können Gegenmaßnahmen wie Einsatz zusätzlicher Agenten oder Weiterlei347

27

Service Center-Systeme tung an eine andere, derzeit nicht vollständig ausgelastete Agentengruppe getroffen werden. Insbesondere solche Informationen werden nicht nur auf entsprechende Arbeitsplatzrechner von Supervisoren und Leitern geliefert, sondern auch auf großen Wandmonitoren (»Digital Wallboards«) angezeigt. Agenten, Supervisoren und Leiter des Centers haben so stets Echtzeitinformationen zur aktuellen Anfrage- und Bearbeitungslage des Centers.

27.2

Anwendung von Service Center-Systemen Service Center stellen eine neuere Variante der Organisation der Personalarbeit dar, die auf Konzepten, Erfahrungen und Systemen des Customer Relationship-Managements (CRM) beruht. Nicht selten stellen für das Personalmanagement angebotene Service Center-Systeme daher adaptierte Systeme des Vertriebsbereiches dar. Service Center-Systeme bilden in diesem Sinne die technische Voraussetzung, die solche Organisationsvarianten erst ermöglichen. Sie präsentieren den Anwendern neben entsprechenden Anfragen auch die Inhalte und Funktionalitäten korrespondierender Anwendungssysteme, ohne selbst über umfassendere personalwirtschaftliche Funktionalitäten zu verfügen. Entsprechend lassen sich Service Center-Systeme als schichtspezifische personalwirtschaftliche Systeme der Präsentationsebene verstehen. Neben der Intensivierung der Serviceorientierung, der Verbesserung der Erreichbarkeit, der Beschleunigung der Vorgangsbearbeitung und der Sicherstellung eines einheitlichen Qualitätsstandards, dürften weiter auch Kosteneinsparungen durch Skalenund Verbundeffekte ein erhebliches Potenzial von Service Center-Systemen darstellen. Durch die mögliche raumzeitliche Entkopplung von Agent und nachfragender Person ist auch die Verlagerung von Centern an kostengünstigere Standorte möglich (»Off- bzw. Nearshoring«). Im Rahmen von »Shared« Service-Centern ergibt sich ein fließender Übergang zum Outsourcing, wenn Dienstleistungen nicht nur für das eigene Unternehmen, sondern auch für Kundenunternehmen angeboten werden. Entsprechend sind Service Center auch eine geeignete Organisationsform für Anbieter eines personalwirtschaftlichen reinen Outsourcing (vgl. Kap. 2). Funktional eignen sich Service Center vor allem für die Bearbeitung administrativer personalwirtschaftlicher Aufgaben, die in Interaktion zwischen Personalmanagement und Mitarbeitern, Führungskräften und/oder Bewerbern entstehen. Typischerweise

348

27.2 Anwendung von Service Center-Systemen umfasst dies neben der eigentlichen Anfragebearbeitung auch eine Informations-Hotline und ein Beschwerdemanagement. Service Center können dabei auf einen Funktionsbereich beschränkt werden, wie etwa ein spezifisches Personalabrechnungscenter, oder generell alle anfallenden administrativen Aufgaben des Personalmanagement bearbeiten. In jedem Fall sind – wie dargestellt – korrespondierende personalwirtschaftliche Anwendungssysteme notwendig, da Service Center-Systeme i.d.R. keine eigene personalwirtschaftlichen Funktionalitäten zur Verfügung stellen. Die Beschränkung auf administrative personalwirtschaftliche Funktionen bedingt i.d.R. weitere organisatorische Einheiten, die eine Übernahme aller personalwirtschaftlichen Funktionen ermöglichen. Entsprechend werden Service Center oft in ein umfassenderes, mehrstufiges »Service Delivery«-Modell eingebettet, das grundsätzlich die Stufen »Self Service«, »Service Center« und »Fachabteilung« vorsieht (vgl. Kap. 2). Teils werden Service Center dabei nochmals in Generalisten- und Spezialistenebene und die Fachabteilung in Experten- und Businesspartnerebene untergliedert (vgl. Jäger 2006). Die Abstimmung solcher mehrstufigen Organisationsformen kann dabei durch Service Center-Systeme zumindest unterstützt werden, wenn etwa in der geschilderten Weise Anfragen aus Self Service-Anwendungen automatisiert übernommen oder vom Center nicht bearbeitbare Aufgaben automatisiert an die Fachabteilung übergeben werden können. Verbreitung

Spezifische empirische Studien zur Verbreitung von Service Center-Systemen sind derzeit nicht bekannt. Jedoch zeigen verschiedene generelle Studien eine durchaus weit fortgeschrittene Diffusion der Service Center Idee im Personalmanagement (vgl. Ackermann 2005). Entsprechend dürften Service Center-Systeme ebenfalls verbreitet eingesetzt werden.

349

28

Browsersysteme Browsersysteme (Browser, Webbrowser, WWW-Browser, Internetbrowser) sind Anwendungen, die das Aufrufen, Anzeigen und Verwenden der Dienste und Anwendungen von Internet-Servern ermöglichen (vgl. Meinel & Sack 2004, 11f.).

28.1

Architektur und Funktionalität von Browsersystemen Idealtypisch besteht der Kern eines Browsers aus einer Ablaufsteuerung (»Controller«) und einer WWW-Komponente. Im Rahmen der Auseinandersetzungen diverser Anbieter um eine Vormachtstellung am Markt (»Browser War«) werden Browser sukzessive mit weiteren Komponenten bestückt, die zusätzliche Funktionalitäten integrieren. Entsprechend weisen Browser teils zusätzlich Multimedia-, Kommunikations- und Autorenkomponenten auf (vgl. Abb. 28.1). Browsersystem Anwenderschnittstelle Ablaufsteuerung

WWW

MultiMedia

Kommunikation

Autorenwerkzeug

Schnittstellen Webserversysteme (WWW, FTP, Anwendungen ...)

Abb. 28.1: Idealtypische Architektur von Browsersystemen (in Anlehnung an Meinel & Sack 2004, 24) Die Ablaufsteuerung dient der Verwaltung und Organisation aller Browser-Komponenten und -Funktionen. Die WWW-Komponente dient der Eröffnung einer Verbindung mit einem WWW-Server, sowie dem Einlesen, Aufbereiten und Anzeigen der angefragten Hypermedia-Dokumente. Mögliche Kommunikations351

28

Browsersysteme komponenten ermöglichen die browserbasierte Nutzung von eMail, Chat- und/oder Instant Messaging-Diensten. Multimediakomponenten ermöglichen insbesondere das browsergestützte Abspielen von Audio- und Videodateien. Autorenkomponenten ermöglichen das Erstellen eigener Hypermedia-Dokumente.

»Plug Ins«

Solche von Browsern zur Verfügung gestellten Funktionalitäten können entweder als integrierter Bestandteil eines Browsers oder aber über »Plug Ins« realisiert werden. Plug Ins stellen Hilfsprogramme dar, die die Funktionalität des Browsers in verschiedene Richtungen erweitern. Häufig werden beispielsweise Systeme zum Abspielen von Multimedia-Dateien als »Media Plug In« realisiert. Oft wird die Funktionalität von Plug Ins dabei in die Browseroberfläche integriert. Nach Beendigung der Plug In-Anwendung verschwinden die zusätzlichen Menüpunkte etc. Plug InSysteme können vielfach per Download von den jeweiligen Herstellern kostenlos installiert werden. Plug Ins werden dabei i.d.R. fest auf dem Client-Rechner installiert (vgl. Turau 1999, 7f.).

Hardwarebasis

Weiter existieren Browsersysteme für unterschiedliche Arten von Hardware. Konventionelle Webbrowser sind zunächst auf eine Anwendung auf stationären oder mobilen Arbeitsplatzrechnern ausgerichtet, die als Clients entsprechende Inhalte und Anwendungen von Webservern präsentieren. Mit der zunehmenden Verbreitung von mobilen Kleingeräten existieren inzwischen auch Browser für Personal Digital Assistants («PDA», »Handheld«, »Organizer«) und Smart-Phones. Aufgrund der deutlich kleineren Bildschirmgrößen, den langsameren Übertragungsraten im Mobilfunk und den geringeren Rechnerleistungen dieser Geräte sind allerdings sowohl andere Techniken (z.B. Übertragungsprotokolle wie WAP) als i.d.R. auch eine andere Gestaltung der Inhalte und Anwendungen notwendig. Sollen Inhalte und Anwendungen gleichzeitig für verschiedene Endgerätekategorien angeboten werden, sind diese meist für unterschiedliche Browsertypen parallel zu erstellen.

28.1.1

Ablaufsteuerung und WWW-Komponente In Interaktion mit der Ablaufsteuerung dient die WWW-Komponente zunächst der Lokalisierung, Interpretation, Aufbereitung und korrekten Darstellung der aufgerufenen Hypermedia-Dokumente des WWW. Bei Anbindung webbasierter Anwendungen kann die WWW-Komponente auch zur Kommunikation mit diesen Anwendungen eingesetzt werden. Browsersysteme können

352

28.1 Architektur und Funktionalität von Browsersystemen dann als Anwenderschnittstelle dieser Systeme verwendet werden (vgl. z.B. Zalud 2000). WWW

Im allgemeinen Sprachgebrauch werden World Wide Web (»WWW«, »Web«) und Internet oft synonym verwendet. Das World Wide Web ist jedoch nur ein Dienst bzw. ein Teil des Internet. Generell stellt das WWW eine mächtige Daten- und Informationssammlung dar, die früher in Form von Hypertext-Dokumenten, inzwischen aber durch die zunehmende Anreicherung von Texten mit Grafiken, Audio- oder Videodateien in Form von Hypermedia-Dokumenten existiert. Ein Einzeldokument wird als »Page« bezeichnet. Start- oder Wurzeldokumente nennt man »Homepage«. Solche Hypermedia-Dokumente können über (Hyper-) Links miteinander verbunden werden. Dementsprechend kann durch Verfolgen von Links zwischen verschiedenen HypermediaDokumenten gewechselt werden. Die Hypermedia-Dokumente sind auf zahlreichen WWW-Servern abgelegt. Entsprechend stellt das Internet ein mächtiges verteiltes Hypermedia-System dar (vgl. Meinel & Sack 2004, 17ff.).

HTML und XML

Die Hypermedia-Dokumente des WWW werden dabei in einer speziellen Beschreibungssprache, der Hypertext Markup Language (»HTML«) beschrieben. HTML ermöglicht es, die Struktur (d.h. Gliederung, Tabellen, Absätze) und die Formatierung eines Dokumentes festzulegen. Auch die Einbindung multimedialer Dateien oder das Setzen von Hyperlinks wird unterstützt. Inzwischen wird HTML zunehmend durch die Extensible Markup Language (»XML«) ergänzt. XML kann z.B. zur Beschreibung von beliebigen Datenstrukturen verwendet werden, die über das WWW ausgetauscht werden sollen, und unterstützt auch den plattformunabhängigen Austausch von Daten (vgl. Turau 1999).

HTTP

Damit Hypermedia-Dokumente zwischen WWW-Komponente und Web-Server Daten austauschen können benötigt man ein identisches Kommunikationsprotokoll, das Hypertext Transfer Protocol (»HTTP«). Generell schreibt das Protokoll die Prozeduren fest, nach denen ein Informationsaustausch zwischen Browser und Web-Server stattzufinden hat. Die Interaktion erfolgt dabei nach dem Client Server-Prinzip. Die WWW-Komponente baut die Verbindung vom Client zum Server auf (»Connection«). Danach fordert es die Daten an (»Request«). Der Server stellt die Daten bereit (»Response«). Die Verbindung wird danach durch den Server abgebaut (»Close«), wenn alle Daten übertragen sind. Alternativ wird die Verbindung bei Abbruch durch das Browsersystem abgebaut (vgl. Turau 1999). Inzwischen existieren auch zahl353

28

Browsersysteme reiche sinnvolle Erweiterungen von HTTP wie etwa Secure Socket Layer (»SSL«), ein Verfahren, das eine zusätzliche Schicht zur Verschlüsselung und sicheren Übertragung von sensiblen Daten verwendet. In diesem Fall verändert sich das Protokoll in HTTPS (»Secure HTTP«).

URL

Die auf verschiedenen WWW-Servern abgelegten HypermediaDokumente können von der WWW-Komponente mittels eines Uniform Resource Locator (»URL«) eindeutig identifiziert und lokalisiert werden. Eine URL besteht aus einer Zeichenkette, die im einfachsten Fall die Bestandteile Zugangsprotokoll://Server[:Port]/Pfad aufweist. Das Zugangsprotokoll (Übertragungsprotokoll, »Transfer Protocol«) bildet einen Standard der Kommunikation zwischen verschiedenen Computern. Wie erwähnt bildet HTTP das zentrale Zugangsprotokoll des WWW. Der Server ist derjenige Rechner, von dem die entsprechenden Daten angefordert werden sollen. Zur Bezeichnung des Servers werden neben dem Servernamen (z.B. www.uni-saarland.de) auch damit korrespondierende IP (Internet Protocol)-Adressen (z.B. 231.45.7.87) herangezogen. IPAdressen dienen als normierte Ziffernfolge der eindeutigen Identifikation eines Rechners in TCP/IP-Netzwerken. Servernamen haben allerdings meist den Vorteil, »sprechende« Namen darzustellen und entsprechend eingängiger und verständlicher zu sein als eine bloße Ziffernfolge. I.d.R. werden daher Servernamen den IP-Adressen vorgezogen. Port-Nummer bezeichnen, welche konkreten Dienste oder Anwendungen auf dem Host aufgerufen werden sollen. Allerdings kann die Portnummer beim HTPP-Protokol (und bei einigen anderen Protokollen) weggelassen werden. Der Pfad bezeichnet schlicht den Zugriffpfad, über den auf die Datei zugegriffen wird (vgl. Turau 1999).

CGI

354

Für die Verwendung von Browsern als Anwenderschnittstelle von personalwirtschaftlichen Anwendungen ist die Common Gateway Interface (»CGI«)-Schnittstelle von WWW-Servern von zentraler Bedeutung. Browsersysteme waren zunächst auf einen einseitigen Informationstransfer von Server zum Client ausgelegt. Entsprechend konnten zunächst nur Daten vom Server bezogen werden, aber keine Daten an den Server übermittelt werden. CGI bildet eine standardisierte Schnittstelle, die die Kommunikation zwischen Webservern und Anwendungssystemen regelt. Anwendungssysteme, die die CGI-Schnittstelle benutzen (oft auch »CGISkripts« genannt) können prinzipiell in beliebigen Programmiersprachen erstellt sein, häufig werden allerdings spezifische Spra-

28.1 Architektur und Funktionalität von Browsersystemen chen eingesetzt. CGI ist zusätzlich auch unabhängig von der Serversoftware des HTTP-Servers. HTML und CGI können dann in beide Richtungen »kommunizieren«. Auf diese Weise wird es möglich, mit einer HTML-Datei des Browsers ein CGI-Skript aufzurufen. Umgekehrt kann ein CGI-Skript HTML-Code erzeugen, der dann an die WWW-Komponente des Browsers weitergeleitet und im Browser angezeigt werden kann. Das Anwendungssystem kann dabei entweder auf dem Rechner des WWW-Servers laufen oder aber auf einem eigenen Anwendungsserver unter der Kontrolle der WWW-Servers (vgl. Meinel & Sack 2004, 1030ff.). Die Interaktion von Browser- und Anwendungssystem kann am einfachen Beispiel der webbasierten Änderung der eigenen Personalstammdaten durch einen Mitarbeiter (»Self Service«) dargestellt werden (vgl. Abb. 28.2). WWW-Client

WWW-Server

Formulardaten senden

Ausgabe Client

HTTP

Weiterleitung

Anwendungssystem

Browser-System

Formular

HTTP-Server

Formularanforderung

Ausgabe Server

CGI

Abb. 28.2: Interaktion von Browser- und Anwendungssystem (in Anlehnung an Meinel & Sack 2004, 1081) Nach der Auswahl einer URL und dem Einloggen in das entsprechende Anwendungssystem kann der Mitarbeiter über einen entsprechenden Link ein Formular zur Änderung seiner Daten anfordern. Nachdem entsprechende Daten im Formular eingegeben bzw. geändert wurden, werden diese an den HTTP-Server weitergegeben, der sie per CGI-Schnittstelle einem personalwirtschaftlichen Anwendungssystem weiterreicht. Dort werden die Daten gespeichert und eine Bestätigung des Speichervorgangs wird erneut über den HTTP-Server an die WWW-Komponente 355

28

Browsersysteme des Browsers weitergereicht. Diese Möglichkeiten, Anwendungssysteme zu steuern, machen Browsersysteme zu besonders interessanten Präsentationssystemen für sämtliche personalwirtschaftlichen (und sonstigen) Anwendungen.

28.1.2

Autorenkomponente Teilweise vorhandene Autorenkomponenten werden meist als HTML- bzw. XML-Editoren realisiert. Diese dienen dem Erstellen und Verändern von Internetseiten. Umfassendere Editoren enthalten überdies auch Funktionen zur Verwaltung von Hyperlinks (»Link-Management«) und einzelnen Websites (»Site-Management«). Grundsätzlich kann dabei zwischen text- und grafikbasierten Editoren unterschieden werden. Bei textbasierten Editoren wird direkt der entsprechende Quellcode angezeigt bzw. eingegeben oder verändert. Solche Editoren verlangen daher Programmierkenntnisse in der entsprechenden Beschreibungssprache. Grafikbasierte Editoren zeigen die jeweilige Seite dagegen beim Erstellen und Bearbeiten bereits so, wie sie im Browser nach Fertigstellung erscheinen wird. Solche Editoren arbeiten damit nach dem WYSIWYG(»What You See Is What You Get«)Prinzip. Regelmäßig können grafikbasierte Anwendungen, die entsprechenden Webseiten auch in textueller Form anzeigen und sind damit beides, grafik- und textbasiert.

28.1.3

Kommunikationskomponente Zusätzlich vorhandene Kommunikationskomponenten dienen im Wesentlichen der Ermöglichung von internetbasierten e-Mail-, Chat- und Instant Messaging-Diensten.

e-Mail

E-Mail-Systeme (elektronische Post, »Electronic Mail«) bilden eine erste kommunikative Komponente. Solche Systeme ermöglichen es innerhalb kurzer Zeiträume, Textnachrichten zwischen verschiedenen Browseranwendern auszutauschen. Darüber hinaus lassen sich beliebige Dateien und Dokumente als Anhang (»Attachment«) der Mail mit versenden. Einzelne Anwender erhalten dann einen e-Mail-Account mit einer e-Mail-Adresse, wie etwa die Adresse [email protected] E-Mail-Adressen bestehen dabei aus einem Bestandteil, der den Empfänger bezeichnet, dem »@«-Zeichen und dem Namen des entsprechenden e-Mail-Servers. Neben Browsern, die integrierte e-Mail-Dienste aufweisen, finden sich auch Systeme, die externe Mailsysteme aufrufen können.

356

28.1 Architektur und Funktionalität von Browsersystemen Chat

Auch beim Chat (»Plauderei«) besteht die Art der Kommunikation grundsätzlich aus Text, der von einem Anwender eingegeben wird. Allerdings können diese Nachrichten von anderen Anwendern nahezu zeitgleich gelesen und ebenfalls durch Texteingabe beantwortet werden. Die Konversation zwischen Chat-Teilnehmern erfolgt damit weitgehend synchron und interaktiv. Die einzelnen Chats werden thematisch nach Chaträumen (»Chatrooms«) bzw. Kanälen (»Channels«) geordnet. Chaträume können von den Anwendern individuell generiert, betreten und verlassen werden. Entsprechende Funktionalitäten erlauben zunächst die i.d.R. beliebige Generierung neuer Chaträume. Zur Teilnahme an einem Chat muss sich ein Anwender zunächst per Passwort einloggen. Dabei muss der Anwender i.d.R. seinen Nutzernamen angegeben. Häufig wird dazu ein selbst gewählter (Spitz-)Name (»Nickname«) verwendet. Der Chat-Dienst prüft die jeweils im Chat aktiven »Spitznamen« und verhindert bei der Anmeldung, dass zwei Anwender denselben Namen verwenden. Durch die Verwendung dieser Namen erfolgt die Kommunikation daher i.a.R. anonym bzw. pseudonym. Allerdings gibt es teilweise Dienste, die auf der Basis des »Spitznamens« nach der IP-Adresse eines Chatteilnehmers suchen. Üblicherweise gibt ein Anwender seinen Input dabei über ein Webformular ein. Jeder dieser Inputs steht dann allen anderen Teilnehmern des entsprechenden Chatraums unmittelbar zur Verfügung.

Instant Messaging Als »Variante zwischen Chat und e-Mail« bieten Instant Messaging-Dienste (»Sofortbenachrichtigung«) die Möglichkeit, kurze Nachrichten an zuvor spezifizierte Teilnehmer zu senden. Dazu sind zunächst Kontaktlisten (»Buddy Lists«) mit für einen Anwender individuell besonders interessanten Personen anzulegen. I.d.R. bedarf die Übernahme auf eine Liste der Zustimmung dieser Personen. Das System meldet dann automatisch, welche dieser Personen gerade »online« sind. Umgekehrt meldet das System auch die eigene Anwesenheit im Internet. Anwender können dann Kurznachrichten an diese weiteren aktiven Teilnehmer versenden. Die Kommunikation mit einem spezifischen Kommunikationspartner kann dann ohne vorherige Absprache von Chatraum und Termin erfolgen. Im Unterschied zum reinen Chat kann mit dem Instant Messaging je nach Antwortverhalten auch eine asynchrone Variante der Kommunikation vorliegen (vgl. Dewes et al. 2003, 53f.).

357

28

Browsersysteme

28.1.4

Multimediakomponente Multimediakomponenten (»Mediaplayer«) ermöglichen das Einlesen und Wiedergeben von Mediadateien, insbesondere von Audio- und Videodateien. Daneben finden sich auch administrative Funktionen wie etwa die Verwaltung mehrerer Mediadateien auf so genannten Abspiellisten. Multimediakomponenten werden oft als »Plug In« realisiert. Ob Multimediadateien abspielbar sind, hängt allerdings nicht nur von der Art der Multimediakomponente ab, sondern auch von gewissen physischen Eigenschaften des Client-Rechners. So ist bspw. zum Abspielen von Audiodateien eine Ausstattung mit Soundkarte und Lautsprechern notwendig (vgl. Turau 1999).

28.1.5

Anwenderschnittstelle

Text- vs. Grafikorientierung

Nach der Art der vom Browser verwendeten Anwenderschnittstelle können text- und grafikorientierte Browser unterschieden werden. Textbasierte Browser stellen nur die textuellen Teile von Webseiten dar. Entsprechend werden andere Inhalte, speziell Bilder, gar nicht oder lediglich als Dateinamen oder als Hyperlink angezeigt. Solche Dateien können dann ggf. mit einem weiteren, browser-externen Programm geöffnet werden. Deutlich weiter verbreitet dürften Browser mit grafischer Oberfläche sein, die Texte und Bilder (bei Einbezug einer Multimedia-Komponente auch weitere Dokumenttypen) präsentieren können. Über »Point & Click« (Zeigen und Klicken)-Funktionen erlauben grafikorientierte Browser die Navigation zwischen verschiedenen, durch (Hyper-)Links verbundenen Dokumenten. In Folge der weiten Verbreitung und Akzeptanz von Browsersystemen werden auch nicht-browserbasierte Anwenderschnittstellen »browser-ähnlich« ausgestaltet (vgl. Zalud 2000).

Frames

Die meisten grafikorientierten Browser unterstützen die Darstellung von so genannten »Frames« (Rahmen). Mit Hilfe von Frames lässt sich die Anwenderoberfläche des Browsers in beliebige Teilsegmente aufgliedern (vgl. Abb. 28.3). Die konkrete Aufteilung einer Browserseite in mehrere Frames wird dabei durch eine eigene Datei, das so genannte »Frameset« durchgeführt. Einzelne Frames können dabei unterschiedliche HTML-Dokumente anzeigen. Dies wird oft als Vorteil gesehen, da so auch Inhalte unterschiedlicher Quellen bzw. Anwendungen auf einer Seite kombiniert werden können. Diese zusätzliche gestalterische Freiheit erlaubt es auch, HTML-Dokumente gängigen Anwenderschnittstellen anzupassen (vgl. Meinel & Sack 2004, 853ff.).

358

28.2 Anwendung von Browsersystemen Frame1

Frame2

Frame3

Frame4

Abb. 28.3: Aufteilung des Browserfensters in Frames (Meinel & Sack 2004, 854) Allerdings existieren Probleme der Adressierung einzelner Unterseiten, da der Browser beim Wechsel zwischen verschiedenen Unterseiten meist nur die generelle Adresse des Framesets anzeigt. Ebenso haben Suchmaschinen Probleme die Startseite aufzufinden. Entsprechend wird – gerade in kommerziellen Anwendungen – zunehmend auf die Verwendung von Frames verzichtet.

28.2

Anwendung von Browsersystemen Als Präsentationssysteme weisen Browsersysteme zahlreiche Vorteile auf. So gehören sie inzwischen zur Standardausstattung jedes Arbeitsplatzrechners und weisen eine meist sehr ähnliche Anwenderführung auf. Ihre Anwendung gilt als einfach, und entsprechende Anwenderqualifikationen sind weit verbreitet. Browsersysteme haben weiter geringe Anforderungen an die Performanz der Endgeräte und sind daher meist kostengünstig realisierbar. Insbesondere bei großen Anwenderzahlen verspricht die Verwendung von Browsern zusätzlich auch deutliche Verbesserung in der Administration von Anwendungssystemen, da etwa »Updates« oder Fehlerbehebungen zentral durchgeführt werden können (vgl. Ress 2002, 6). Schließlich machen Browsersysteme entsprechende Inhalte und Anwendungen (nahezu) ubiquitär verfügbar. Neben diversen Kommunikationsmöglichkeiten ist insbesondere die Möglichkeit über Browser auf diverse interne Anwendungen und Daten zuzugreifen, für das Personalmanagement von besonderer Wichtigkeit. Dabei profitieren alle personalwirtschaftlichen Anwendungssysteme von Zugriffsmöglichkeiten über das Web. Etwa wird bei Beschaffungsmanagementsys359

28

Browsersysteme temen die Reichweite von Stellenausschreibungen erheblich erhöht, die Präsentationsmöglichkeiten von Stellen und Unternehmen verbessern sich, man verfügt über unmittelbare Kommunikationsmöglichkeiten mit dem Bewerber und kann durch die Auslagerung von Dateneingabetätigkeiten den Aufwand verringern und die Datengüte verbessern (vgl. Kap. 16). Ebenso profitieren Planungs- und Kontrollsysteme von einem Webzugriff. So ist es auf der Basis personalwirtschaftlicher Business IntelligenceSysteme (vgl. Kap. 5, 11 und 12) möglich, webbasierte PersonalCockpits (Leitstände, »Dashboard«) zu entwickeln. Verteilte Informationen können so in verdichteter und teilweise visualisierter Weise dargestellt werden. Führungskräfte des Personalbereichs verfügen dadurch über die Möglichkeit, auf einfache Weise auf Daten zuzugreifen. Angesichts der generellen Vorteile verfügen personalwirtschaftliche Informationssysteme seit Mitte der neunziger Jahre zunehmend über webbasierte Zugriffsmöglichkeiten. Wiesen Pionieranwendungen zusätzlich zu diesem Webzugriff i.d.R. auch noch eine konventionelle Anwenderschnittstelle auf, werden Browser Ende der neunziger Jahre zunehmend als einzige Anwenderschnittstelle angeboten. In der zweiten Hälfte der neunziger Jahre finden sich erstmals personalwirtschaftliche Systeme, mit für interne wie für externe Anwender ausschließlich browserbasiertem Zugriff. Neben den dominanten »HTTP«-Browsern lassen sich dabei zumindest vereinzelt auch »WAP«-basierte Anwendungen nachweisen. Beispielsweise können Mitarbeiter individuelle Auftrags- und Projektarbeitzeiten auf der Basis von Personal Digital Assistants erfassen und direkt an ein entsprechendes Arbeitszeitmanagementsystem weiterleiten (vgl. Kap. 14). Die teils vorausgesagte generelle Zunahme der Anwendung solcher mobilen Kleingeräte im Personalmanagement (vgl. etwa Davies & Calderón 2004, 63) scheint aus verschiedenen Gründen jedoch eher offen. So ist die Leistungsfähigkeit der Displays eingeschränkter, die Übertragungsrate ist geringer und die Kosten einer Übertragung sind nach wie vor vergleichsweise hoch. Ebenso dürfte die meist vorhandene Notwendigkeit, zusätzlich zu WWW-Seiten redundant auch WAP-fähige Seiten zu erstellen, viele Hersteller von einem Angebot abhalten. Und schließlich ist ein mobiler WWW-Zugriff per Funk auch über Laptop-Rechner mit entsprechender Zusatzausstattung möglich. Die Webbasierung personalwirtschaftlicher Anwendungen bildet ohne jede Frage die zentrale technische Basis der Entwicklungen zum »Electronic Human Resource Management« (»e-HR[M]«) (vgl.

360

28.2 Anwendung von Browsersystemen Strohmeier 2002). So sind die zahlreichen Self Service-Konzepte ohne Browsersysteme (und korrespondierende Internettechnologien) kaum denkbar. In gleicher Weise profitieren Konzepte des Application Service Providing von Browsersystemen und Internettechnologien (vgl. auch Kap. 2). Verbreitung

Derzeit geben 72,6% der Unternehmen an, eine Variante webbasierten Zugriffs auf ihre personalwirtschaftlichen Anwendungssysteme anzubieten (vgl. Strohmeier & Kabst 2007). Browser dürften entsprechend auf dem Weg sein, das universelle Präsentationssystem für zahlreiche Anwendungen des Personalmanagements zu werden und dem e-HRM damit zum endgültigen Durchbruch zu verhelfen.

361

Literaturverzeichnis Ackermann, K.-F. (2005). Shared-Service-Center HR in Deutschland – Erfahrungen und Erwartungen. Personalwirtschaft, 5, 10-11. Adamski, B. (1995). Die Organisation der computergesteuerten Zeitwirtschaft. Köln: Datakontext. Adamson, L. & Zampetti, R. (2001). Web-Based Manager Self-Service: Adding Value to the Work in Web-Based Human Resources. In: Walker, A. J. (Hrsg.), Web-Based Human Resources. New York: McGraw-Hill, 24-35. Aerts, I., Hoeck, M., Pelowski, A., Wolf, S. & Mülder, W. (2004), Personalkennzahlen. CoPers, 7, 10-13. Ala, M. & Brunaczki, B. (2003). Online Benefits Solutions: A New Trend in Managing Employee Benefits Programs. Journal of Health Care Finance, 29(3), 61-66. Andresen, K., Koslowski, S. & Stoffer, M. (2005). Marktübersicht: ERP-Systeme. ERP-Management, 1(3) 2005, 48-57. Arbeitsgemeinschaft wirtschaftliche Verwaltung (AWV) (2001). Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS). Eschborn. Back, A., Bendel, O. & Stoller-Schai, D. (2001), E-Learning im Unternehmen: Grundlagen – Strategien – Methoden – Technologien, Zürich: Orell Füssli. Bamberger, R. & König, A. (2002). Voice Business. Aufbau von Sprachportalen mit dem Phone Manager. Wirtschaftsinformatik, 44(3), 261-266. Baumgartner, P. (2007). Editorial – E-Learning und Standards. Zeitschrift für E-Learning, 2(2), 1. Baumgartner, P., Häfele, H., & Maier-Häfele, K. (2002). E-Learning Praxishandbuch. Auswahl von Lernplattformen. Innsbruck et al.: Studienverlag. Bender, J. (2001). HR Service Centers. In: Walker, A. J. (Hrsg.), Web-Based Human Resources. New York: McGraw-Hill, 212225. Bergmeier, E. & Hoppe, A. (2006). Personalinformationssysteme. Betriebs- und Dienstvereinbarungen. Frankfurt a.M.: Bund.

363

Literaturverzeichnis Berndt, O. & Leger, L. (1994). Dokumenten-Management-Systeme – Nutzen, Organisation, Technik. Neuwied et al.: Luchterhand. Berning, H.-J. (1995). Lohn- und Gehaltsabrechnung, St. Augustin: Asgard. Berry, M. J. A. & Linoff, G. S. (2004). Data Mining Techniques for Marketing, Sales and Customer Support, 2. Aufl., New York et al.: Wiley. BHE (Bundesverband der Hersteller- und Errichterfirmen von Sicherheitssystemen) (2001). Europäische Normen für Zutrittskontrollanlagen. www.bhe.de/zkt_11.shtml, Abruf 11/09/2007. Bizer, J. (2006a). Kommentar zu § 6a Automatisierte Einzelentscheidung. In: Simitis, S. (Hrsg.) Bundesdatenschutzgesetz, 6. Aufl., Baden-Baden: Nomos, 558-570. Bizer, J. (2006b). Kommentar zu § 9a Datenschutzaudit. In: Simitis, S. (Hrsg.) Bundesdatenschutzgesetz, 6. Aufl., Baden-Baden: Nomos, 693-712. Blazewick, J., Ecker, K., Pesch, E., Schmidt, G. & Weglarz, J. (2007). Handbook on Scheduling. From Theory to Application, Berlin et al.: Springer. Bodendorf, F. (1993). Typologie von Systemen für die computergestützte Weiterbildung. In: Bodendorf, F. & Hofmann, J. (Hrsg.), Handbuch der Informatik – Computer in der betrieblichen Weiterbildung, Band 15.2, München und Wien: Oldenbourg, 63-82. Bollenbeck, P. (2006). Anforderungen an ein Optimierungssystem im Workforce Management. White Paper Invision Software AG, o.O. Booth, J. F. (1998). The User Interface in Computer-Based Selection and Assessment: Applied and Theoretical Problematics of an Evolving Technology. International Journal of Selection and Assessment, 6(2), 61-81. Brecht, W., Garvens, M., Jöckel, H.-J. & Pielczyk, R. (1998). PEPO- Personaleinsatzplanung mittels Optimierung. Wirtschaftsinformatik, 40(5), 397-408. Brill, A. (2005). Die Zukunft der Personaleinsatzplanung. Eine Vision aus der Praxis. In: Frank, M. & Scherf, B. (Hrsg.), Handbuch Personaleinsatzplanung, Köln: Datakontext, 463-471. Brooks, M. (2001). Generating Productivity Gains with Employee Portals. Compensation & Benefits Management, 1, 55-57.

364

Literaturverzeichnis Bundesministerium der Finanzen (2001). Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU). Cambern, J. (2006). Online Benefits Management Systems: An HR Evolution. Compensation & Benefits Review, 38(4), 65-70. Chang, J. F. (2005). Business Process Management Systems. Boca Raton & New York: Auerbach Publications. Clarey, J., Chapman, B., Nantel, R. & Woodill, G. (2007). Learning Management Systems for Blended Learning: Which Systems to Buy and How to Buy it. Sunnyvale: Brandon Hall Research. Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6), 377-387. Codd, E. F., Codd, S. B. & Salley, C. T. (1993). Providing OLAP to User Analysts: An IT-Mandate. White Paper Codd Associates, o.O. Collier, K., Carey, B., Sautter, D. & Marjaniemi, C. (1999). A Methodology for Evaluating and Selecting Data Mining Software. Proceedings of the 32nd Hawai International Conference on Systems Sciences, 6009-6020. Däubler, W. (2005). Arbeitsrecht und Informationstechnologien. Computer und Recht, 10, 767-772. Data Mart Consulting (1999). Einsatzfelder von Technologien und Anwendungen im Data Warehouse Umfeld bei verschiedenen betriebswirtschaftlichen Aufgabenstellungen. http://www.datamart.de/index.php?page=studien&site=kostenl oserauszug_dw _studie. Abruf 01/12/2006. Davies, S. A. & Calderón, R. F. (2004). Integrating Handheld Computer Technology into HR Research and Practice. In: Torres-Coronas, T. & Arias-Oliva, M. (Hrsg.), e-Human Resources Management, Hershey: Idea, 31-67. Deutsches Institut für Normung (2002). DIN 33430. Anforderungen an Verfahren und deren Einsatz bei berufsbezogenen Eignungsbeurteilungen. Berlin: Beuth. Dewes, C., Wichmann, A. & Feldmann, A. (2003). An Analysis of Internet Chat Systems. Proceedings of the 3rd ACM Conference on Internet Measurement, New York: ACM Press, 51-63. Dingler, M. (1997). Arbeitszeitmanagement. Gestaltung und Implementierung von Arbeitszeitmodellen, Wiesbaden: Gabler.

365

Literaturverzeichnis Domsch, M. (1980). Systemgestützte Personalarbeit. Wiesbaden: Gabler. Drumm, H.-J. (2005). Personalwirtschaft. 4. Aufl., Berlin et al.: Springer. Dulebohn, J. H. & Marler, J. H. (2005). E-Compensation: The Potential to Transform Practice? In: Gueutal, H. G. & Stone, Dianna L. (Hrsg.), The Brave New World of eHR, San Francisco: Jossey-Bass, 166-189. Dunkel, J. & Holitschke, A. (2003). Softwarearchitektur für die Praxis, Berlin et al.: Springer. Düsing, R. (2005). Knowledge Discovery in Databases. Begriff, Forschungsgebiet, Prozess und System. In: Chamoni, P. & Gluchowski, P. (Hrsg.). Analytische Informationssysteme. Business Intelligence-Technologien und -Anwendungen, Berlin et al.: Springer, 241-262. Ernst, A. T., Jian, H., Krishnamoorthy, M. & Sier, D. (2004). Staff Scheduling and Rostering. A Review of Applications, Methods and Models. European Journal of Operational Research, 153(1), 3-28. Fayyad, U., Piatetsky-Shapiro, G. & Smyth, P. (1996), From Data Mining to Knowledge Discovery: An Overview, In. Fayyad, U. et al. (Hrsg.), Advances in Knowledge Discovery and Data Mining, Cambridge MA: MIT Press, 1-34. Fitting, K., Engels, G., Schmidt, I., Trebinger, Y. & Linsenmaier, W. (2006). Betriebsverfassungsgesetz – Handkommentar, 23. Aufl., München: Vahlen. Florkowski, G. W. & Olivas-Luján, M. R. (2006). The Diffusion of Human-Resource Information Technology in U.S. and Non U.S. Firms. Personnel Review, 35(6), 684-710. Frank, M. & Meißer, O. (2005). Softwarelösungen zur Personaleinsatzplanung. In: Frank, M. & Scherf, B. (Hrsg.), Handbuch Personaleinsatzplanung, Köln: Datakontext, 189-206. Funke, J. (1998). Computer-Based Testing and Training with Scenarios from Complex Problem-Solving Research: Advantages and Disadvantages. International Journal of Selection and Assessment, 6(2), 90-96. Funke, U. (1995). Szenarien in der Eignungsdiagnostik und im Personaltraining. In: Strauß, B. & Kleinmann, M. (Hrsg.), Com-

366

Literaturverzeichnis putersimulierte Szenarien in der Personalarbeit, Göttingen: Hogrefe, 145-216. Gaugler, E., Oechsler, W. A. & Weber, W. (2004). Personalwesen. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 1653-1663. Gaul, W. & Säuberlich, F. (1999). Classification and Positioning of Data Mining Software. In: Gaul, W. & Locarek-Junge, H. (Hrsg.), Classification in the Information Age, Berlin et al.: Springer, 143-151. Gebert, H. A. (2004). IT-gestütztes Kompetenzmanagement in kundenorientierten Geschäftsprozessen - Gestaltungselemente, Architektur- und Methodenvorschlag. Bamberg: Difo. Geis, I., Grenzer, M. & Jähnicke, U. (2003). Rechtliche Betrachtung eines digitalen Personalakten-Systems. Lohn + Gehalt, 3, 40-43. Giraud-Carrier, C. & Povel, O. (2003). Characterizing Data Mining Software. Intelligent Data Analysis, 7, 181-192. Gluchowski, P. & Kemper, H.-G. (2006). Quo vadis Business Intelligence? BI-Spektrum, 1, 12-19. Goebel, M. & Gruenwald, L. (1999). A Survey of Data Mining and Knowledge Discovery Tools. SIGKDD Explorations, 1(1), 2033. Götzer, K. (2001). Dokumenten-Management. Informationen im Unternehmen effizient nutzen, 2. Aufl., Heidelberg: d.punkt. Goldmann, E. L., Panttaja, E., Woicikowski, A. & Braudes, R. (2001). Voice Portals - Where Theory Meets Practice. International Journal of Speech Technology, 4, 227-240. Gronau, N. (2004). Enterprise Resource Planning und Supply Chain Management – Architektur und Funktionen. München und Wien: Oldenbourg. Gulbins, J., Seyfried, M. & Strack-Zimmermann, H. (2002). Dokumenten-Management. Vom Imaging zum Business-Dokument, 3. Aufl., Heidelberg: Springer. Gurzki, T. & Hinderer, H. (2003). Eine Referenzarchitektur für Software zur Realisierung von Unternehmensportalen. In: Reimer, U., Abecker, A., Staab, S. & Stumme, G. (Hrsg.). Professionelles Wissensmanagement. Erfahrungen und Visionen, Bonn: Köllen, 157-160.

367

Literaturverzeichnis Gurzki, T. & Özcan, N. (2003). Unternehmensportale. Kunden-, Lieferanten- und Mitarbeiterportale in der betrieblichen Praxis. Stuttgart: Fraunhofer Institut für Arbeitswirtschaft und Organisation. Guy, S. (2000). Reaching PC-free Employees. HR Magazin, 45(9), 141-146. Hänsgen, K.-D. (1999). Computereinsatz in der Psychodiagnostik - Stand und mögliche Perspektiven. Forschungsbericht Nr. 141, Psychologisches Institut der Universität Freiburg, Schweiz. Hänsgen, K.-D. (2003). DIN 33430 - Blick »von aussen« auf Chancen, Risiken und Nebenwirklungen. www.unifr.ch/ztd/din/ dinbeitrag.pdf, Abruf 14/02/2007. Hager, G. (1995). Die Personalzusatzkosten – Struktur, Ermittlung und Verrechnung, Praxis des Rechnungswesens, 8(4), Freiburg i.Br. Hasselmann, D. (1993). Computersimulierte komplexe Problemstellungen in der Managementdiagnostik, Hamburg: Windmühle. Hasselmann, D. (1995). Die Konstruktion computersimulierter Szenarien für die Personalarbeit, in: Strauß, B. & Kleinmann, M. (Hrsg.), Computersimulierte Szenarien in der Personalarbeit, Göttingen: Hogrefe, 237-259. Heidack, C. (2004). CBT/WBT: Multimediale Qualifizierung durch computer- und webunterstütztes Training. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 639-651. Heinecke, A. (1992). Applikationsmöglichkeiten von Expertensystemen in den funktionalen Bereichen der Personalwirtschaft. Aachen: Shaker. Heinecke, A. (1994). EDV-gestützte Personalwirtschaft - DV-Methoden und Modelle. München und Wien: Oldenbourg. Helber, S. & Stolletz, R. (2004). Call Center Management in der Praxis: Strukturen und Prozesse betriebswirtschaftlich optimieren, Berlin et al.: Springer. Hempel, P. S. (2004). Preparing the HR Profession for Technology and Information Work. Human Resource Management, 43(2&3), 163-177. Henselek, H. (2004). Personalkosten und -aufwand. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des

368

Literaturverzeichnis Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 15541566. Hentschel, B. (2003). Application Service Providing (ASP). In: Scholz, C. & Gutmann, J. (Hrsg.), Webbasierte Personalwertschöpfung. Theorie – Konzeption – Praxis, Wiesbaden: Gabler, 195-205. Hentschel, B. & Kolzter, H.-J. (2002). Computergestützte Entgeltabrechnung. Abrechnungstechnik, -verfahren und -kontrolle in systematischer Darstellung, Köln: Datakontext. Hesse, G. (2003). E-Cruiting bei Bertelsmann. In: Hertel, G. & Konradt, U. (Hrsg.), Human Resource Management im Interund Intranet, Göttingen: Hogrefe, 72-91. Hesseln, S. & Zander, G. (2005). Funktionen einer Software zur Personaleinsatzplanung. In: Frank, M. & Scherf, B. (Hrsg.), Handbuch Personaleinsatzplanung, Köln: Datakontext, 119148. Hettrich, A., & Koroleva, N. (2003). Marktstudie Learning Management Systeme (LMS) und Learning Content Management Systeme (LCMS). Stuttgart: Fraunhofer Institut für Arbeitswirtschaft und Organisation (IAO). Hildebrandt, K. (1994). Strategische Informationssystemplanung. Wirtschaftsinformatik, 36(1), 69-73. Hils, M. & Bahner, J. (2005). Electronic Human Resource Management (E-HRM) in Deutschland – Stand und Entwicklung. Jahrbuch aus Lehre und Forschung der Universität Stuttgart, Stuttgart, 28-41. Hodgins, W. & Duval, E. (2002). Draft Standard for Learning Object Metadata. http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_ v1_Final_Draft.pdf, Abruf 28/08/2007. Holthuis, J. (1999). Der Aufbau von Data Warehouse-Systemen. Konzeption, Datenmodellierung, Vorgehen. 2. Aufl., Wiesbaden: DUV. Hüsselmann, C. (2006), Personalbedarfsplanung als Produkt werkzeuggestützter Geschäftsprozessoptimierung. In: Kruppke, H., Otto, M. & Gontard, M. (Hrsg.), Human Capital Management. Personalprozesse erfolgreich managen. Berlin et al.: Springer, 115-140. Huss Medien GmbH (2006). Human Resources Software. Anforderungen, Funktionalitäten und Anbieter. Berlin: Huss.

369

Literaturverzeichnis Inmon, W. (2005). Building the Data Warehouse, 4. Aufl., London et al.: Wiley. Jäger, W. (2006) Die Business Unit Personal – Strategische Herausforderung für die Aufbau- und Ablauforganisation im Personalmanagement. In: Kruppke, H., Otto, M., Gontard, M. Human Capital Management – Personalprozesse erfolgreich managen, Berlin et al.: Springer, 47-66. Jäger, W. & Jäger, M. (2002). Electronic Human Resources. In: Maess, K. & Franke, D. (Hrsg.). Das Personaljahrbuch 2002, Neuwied: Luchterhand, 296-306 Jaspers, A. (2006). Neues Allgemeines Gleichbehandlungsgesetz: Auswirkungen auf die betriebliche Datenverarbeitung. Lohn + Gehalt, 9, 17-18. Jessel, R., Furkel, D. & Sturm, K. A. (2007). Softwarekompendium für das Personalwesen, 2. Aufl., Freiburg: Rudolf Haufe. Kabst, R. & Giradinni, A. (2005). Einblicke in das strategische Personalmanagement. Die deutsche Perspektive (The Cranfield Project on International Human Resource Management). Giessen. Kanning, U. P. (2002). Grundlagen psychologischer Diagnostik, In: Kanning, U. P. & Holling, H. (Hrg.), Handbuch personaldiagnostischer Instrumente. Göttingen: Hogrefe, 47-92. Kaplan, R. S. & Norton, D. P. (1996). The Balanced Scorecard. Translating Strategy into Action. New York: McGraw Hill. Keebler, T. (2001). HR Outsourcing in the Internet Era. In: Walker, A. J. (Hrsg.), Web-Based Human Resources. New York: McGraw-Hill, 259-276. Keller, G., Nüttgens, M., Scheer, A.-W. (1992). Semantische Prozessmodellierung auf der Grundlage ereignisgesteuerter Prozessketten (EPK). Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWI), Heft 89, Saarbrücken. Kemper, H.-G. & Finger, R. (2006). Transformation operativer Daten - Konzeptionelle Überlegungen zur Filterung, Harmonisierung, Aggregation und Anreicherung im Data Warehouse. In: Chamoni, P. & Gluchowski, P. (Hrsg.) Analytische Informationssysteme. Business Intelligence-Technologien und -Anwendungen, 3. Aufl., Berlin et al.: Springer, 113-128.

370

Literaturverzeichnis Kemper, H.-G., Mehanna, W. & Unger, C. (2004). Business Intelligence. Grundlagen und praktische Anwendung. Wiesbaden: Vieweg. Kersting, M. (2001). Zur Konstrukt- und Kriteriumsvalidität von Problemlöseszenarien anhand der Vorhersage von Vorgesetztenurteilen über die berufliche Bewährung. Diagnostica, 47(2), 67-76. Khan, R. (2003). Evaluating BPM Software. Business Integration Journal, 10, 24-30. Kirchgässner, G. & Wolters, J. (2006): Einführung in die moderne Zeitreihenanalyse, München: Vahlen. Klaus, H., Rosemann, M. & Gable, G. G. (2000). What is ERP? Information Systems Frontiers, 2(2), 141-161. Knolmayer, G. F. (2000). Application Service Providing (ASP). Wirtschaftsinformatik, 42(5), 443-446. Koch, K. (2003). Workflow-Management in der betrieblichen Personalwirtschaft. Frankfurt a.M.: Lang. König, W., Weitzel, T., Keim, T. & von Westarp, F. (2006). Recruiting Trends 2006, Frankfurt am Main. Konradt, U., Lehmann, K., Böhm-Ruppert, J. & Hertel, G. (2003). Computer- und internetbasierte Verfahren der Berufseignungsdiagnostik: Ein empirischer Vergleich. In: Sarges, W. & Konradt, U. (Hrsg.), E-Recruiting und E-Assessment, Göttingen: Hogrefe, 105-124. Krause, R. (2005). Bewertungskriterien für biometrische Identifikationssysteme im Vergleich zu bisherigen Identifikationsverfahren, Freiburg: Albert Ludwigs-Universität. Krcmar, H. (1990). Bedeutung und Ziele von Informationssystemarchitekturen. Wirtschaftsinformatik, 32(5), 395-402. Krcmar, H. (2004). Informationsmanagement. 4. Aufl., Berlin et al.: Springer. Küpper, C. (2005). Verbreitung und Akzeptanz von E-Learning. Duncker & Humblot: Berlin. Kumar, K. & van Hillergersberg, J. (2000). ERP: Experiences and Evolution. Communications of the ACM, 43(4), 23-26. Kurlander, P. (2001), Building Incentive Compensation Management Systems: What Can Go Wrong? Compensation & Benefits Review, 33(4), 52-56. Lederer, M. & Ganter, C. (1999). Zeitwirtschaft: Kriterien zur Systemauswahl. Personalwirtschaft, Sonderheft 10, 41-57. 371

Literaturverzeichnis Lepak, D. P. & Snell, S. A. (1998). Virtual HR: Strategic Human Resource Management in the 21st Century. Human Resource Management Review, 20(3), 215-234. Ließmann, H. & Wetzke, J. (2006). Entwicklung und Management einer service-orientierten Integrationsinfrastruktur mithilfe von BPEL und BPMN. In: Aier, S. & Schönherr, M. (Hrsg.), Enterprise Application Integration. Berlin: Gito, 197-228. Limper, W. (2001). Dokumenten-Management. Wissen, Informationen und Medien digital verwalten. München: DTV. Lusti, M. (2002). Data Warehousing und Data Mining. Eine Einführung in entscheidungsunterstützende Systeme, 2. Aufl., Berlin et al.: Springer. Maier-Häfele, K. & Häfele, H. (2003). Learning-, Content- und Learning Content Management-Systeme. Gemeinsamkeiten und Unterschiede. Vandans: Arge Virtual-Learning. Meinel, C. & Sack, H. (2004). WWW. Kommunikation, Internetworking, Web-Technologien. Berlin et al.: Springer. Mertens, P. (2007). Integrierte Informationsverarbeitung 1. Operative Systeme in der Industrie. 16. Aufl., Wiesbaden: Gabler. Mertens, P. & Griese, J. (2002). Integrierte Informationsverarbeitung 2. Planungs- und Kontrollsysteme in der Industrie. 9. Aufl. Wiesbaden: Gabler. Milius, F. (2002). CLIX. Learning-Management-System für Unternehmen, Bildungsdienstleister und Hochschulen. Wirtschaftsinformatik, 44(2), 163-170. Miranda, S. (2004). Beyond BI: Benefiting from Corporate Performance Management Solutions. Financial Executive, 20(2), 5861. Moore, C. (2006). The Forrester Wave™: Human-Centric Business Process Managements Suites. Forrester Research Paper: o.O. Mucksch, H. & Behme, W. (2000). Das Data Warehouse-Konzept als Basis einer unternehmensweiten Informationslogistik. In: Mucksch, H. & Behme, W. (Hrsg.) Das Data Warehouse-Konzept: Architektur, Datenmodelle, Anwendungen, 4. Aufl., Wiesbaden: Gabler, 3-82. Mülder, W. (1993). Arbeitszeitmanagementsysteme um Arbeitszeit zu flexibilisieren. Personalwirtschaft, 3, 25-26. Mülder, W. (2000). Personalinformationssysteme – Entwicklungsstand, Funktionalität und Trends. Wirtschaftsinformatik, 42, 98106. 372

Literaturverzeichnis Mülder, W. (2003a). Einsatz von Workflow-Management-Systemen bei der Personalrekrutierung. In: Konrad, U. & Sarges, W. (Hrsg.) E-Recruiting und E-Assessment, Göttingen: Hogrefe, 83-103. Mülder, W. (2003b). Electronic Human Resources – Potenziale und Grenzen. In: Kemper, H.-G. & Mülder, W. (Hrsg.), Informationsmanagement: Neue Herausforderungen in Zeiten des e-Business. Festschrift für Prof. Dr. Dietrich Seibt, 495-516. Mülder, W. (2004). Personalinformationssysteme. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 15431546. Mülder, W. & Störmer, W. (2002). Arbeitszeitmanagement und Zutrittskontrolle mit System, Neuwied und Kriftel: Luchterhand. Mülder, W., Tenvorde, K., Roters-Hülsmann, C. & Rüschenbaum, F. (1994). Pflichtenheft für die Auswahl eines Personalinformationssystems, Computergestützte Personalarbeit, 4, 1-16. Müthlein, T. & Jaspers, A. (2007). AGG – Rechtsichere Personalprozesse und -datenverarbeitung. Köln: Datakontext. Newcomer, E. & Lomow, G. (2005). Understanding SOA with Web Services, Upper Saddle River et al.: Addison-Wesley. Nextevolution Consulting Group (2005). Personalprozesse und Personaldokumente verzahnen. Unternehmensbefragung zu den Chancen und Risiken Digitaler Personalakten. Hamburg. Niegemann, H. M., Hessel, S., Hochscheid-Mauel, D, Aslanski, K., Diemann, M. & Kreuzberger, G. (2003). Kompendium E-Learning. Berlin et al.: Springer. Obermann, C. (1995). Computergestützte Planspiele in der Mitarbeiterauswahl – Anwendungsbeispiel Airport. In: Geilhardt, T. & Mühlbradt, T. (Hrsg.), Planspiele im Personal- und Organisationsmanagement, Göttingen: Hogrefe, 401-409. Oechsler, W. A. (2006). Personal und Arbeit. Grundlagen des Human Resource Management und der Arbeitgeber-Arbeitnehmerbeziehungen. 8. Aufl., München und Wien: Oldenbourg. Oechsler, W. A. & Schönfeld, T. (1986). Computergestützte Personalinformationssysteme. Rechtliche Probleme in der betrieblichen Praxis. Die Betriebswirtschaft, 6, 720-735.

373

Literaturverzeichnis Oey, K. J., Wagner, H., Rehbach, S. & Bachmann, A. (2005). Eine einführende Darstellung des Konzepts der serviceorientierten Architekturen. In: Aier, S. & Schönherr, M. (Hrsg.), Unternehmensarchitekturen und Systemintegration, 2. Aufl., Berlin: GITO, 197-220. Oppermann, K. (1989). Die Lohn- und Gehaltsabrechnung. Köln: Datakontext. O.V. (2007). Advanced Resume Processing and Matching Solutions for the Staffing Industry. White Paper WCC Services B.V., o.O. Paatz, M., Jeschke, E., Mönkediek, S. & Ritter, V. (2007). Microsoft Excel im Personalwesen. Unterschleißheim: Microsoft Press. Pedersen, T. B. & Jensen C. S. (2001). Multidimensional Database Technology. Computer, 12, 40-46. Pendse, N. (2004). What is OLAP? An Analysis of What the Increasingly Misused OLAP Term is Supposed to Mean. http:// www.olapreport.com/fasmi, Abruf 08/05/2007. Potowski, D. & Bobko, P. (2004). Selection Testing via the Internet: Practical Considerations and Exploratory Empirical Findings, Personnel Psychology, 57(4), 1003-1034. Reinheimer, S., Lang, F., Purucker, J. & Brügmann, H. (2007). Zehn Antworten zu SOA. In: Fröschle, H.-D. & Reinheimer, S. (Hrsg.), HMD Praxis der Wirtschaftsinformatik. Service Orientierte Architekturen (SOA), 253, 7-17. Ress, M. J. (2002). Evolving the Browser Towards Standard User Interface Architecture. Australian Computer Science Communications, 24(4), 1-7. Richter, J. & Stähler, G. (2003). Talente im Visier – Vom traditionellen Recruitment zum Talent Relationship Management. In: Peitz, A. & Pfeffer, R. (Hrsg.), Personalauswahl International, Düsseldorf: Symposion, 165-189. Ruël, H., Bondarouk, T. & Looise, J. K. (2004). E-HRM: Innovation or Irritation? An Exploration of Web-Based Human Resource Management in Subsidiaries of Multinational Companies. Utrecht: Lemma. Sarges, W. & Wottawa, H. (2005). Handbuch wirtschaftspsychologischer Testverfahren, 2. Aufl., Lengerich: Pabst. 374

Literaturverzeichnis Sauter, W., Sauter E. & Bender, H. (2004). Blended Learning. Effiziente Integration von E-Learning und Präsenztraining. Luchterhand: Neuwied. Schäffer-Külz, U. (2005). Mitarbeiterportale und Self-Service. Eine empirische Untersuchung der Auswirkungen und Gestaltungsparameter unter Verwendung des Technologie-Akzeptanzmodells. Köln: Datakontext. Scheer, A.-W. (2002). ARIS – Vom Geschäftsprozess zum Anwendungssystem. 4. Aufl., Berlin et al.: Springer. Scherf, B. (2005a). Ein Vorgehensmodell zur Personaleinsatzplanung. In: Frank, M. & Scherf, B. (Hrsg.), Handbuch Personaleinsatzplanung, Köln: Datakontext, 15-53. Scherf, B. (2005b). Zeitwirtschaft heute – Notwendiges Übel oder Kernelement bedarfsorientierter Personaleinsatzplanung? Lohn + Gehalt, 5, 27-30. Schinzer, H. & Bange, C. (1999). Werkzeuge zum Aufbau analytischer Informationssysteme. Marktübersicht. In: Chamoni, P. & Gluchowski, P. (Hrsg.) Analytische Informationssysteme. Data Warehouse, On-Line Analytical Processing, Data Mining. 2. Aufl., Berlin et al.: Springer, 41-58. Schinzer, H., Bange, C. & Mertens, H. (1999). Data Warehouse und Data Mining. Marktführende Produkte im Vergleich. München: Vahlen. Schirmer, F. (2004). Organisation und Träger der Personalarbeit. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: SchäfferPoeschl, 1271-1279. Schmeisser, W. & Clermont, A. (1999). Personalmanagement. Herne & Berlin: Verlag Neue Wirtschaftsbriefe. Schönherr, M. (2006). Enterprise Architecture Frameworks. In: Aier, S. & Schönherr, M. (Hrsg.), Enterprise Application Integration. Service Orientierung und nachhaltige Architekturen, 2. Aufl., Berlin: Gito, 3-48. Scholz, C. (1997). Zuerst die Strategie, dann die Software. Personalwirtschaft, 11, 8-14. Scholz, C. (2000). Personalmanagement. Informationsorientierte und verhaltenstheoretische Grundlagen, 5. Aufl. München: Vahlen. Scholz, C. (2003). Datenaustausch in webbasierter Personalarbeit über XML. In: Scholz, C. & Gutmann, J. (Hrsg.). Webbasierte

375

Literaturverzeichnis Personalwertschöpfung. Theorie - Konzeption - Praxis, Wiesbaden: Gabler, 207-222. Scholz, C. (2004). Virtualisierung der Personalarbeit. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 19791988. Schütz, T. (2004). Dokumentenmanagement. In: Kuhlen, R., Seeger, T. & Strauch, D. (Hrsg.) Grundlagen der praktischen Information und Dokumentation, 5. Aufl., Band 1, München: K.G. Saur. Schulmeister, R. (2003). Lernplattformen für das virtuelle Lernen. Evaluation und Didaktik. München und Wien: Oldenbourg. Schulmeister, R. (2007). Grundlagen hypermedialer Lernsysteme. Theorie - Didaktik - Design. 4. Aufl., München und Wien: Oldenbourg. Schulte, C. (2002). Personalcontrolling mit Kennzahlen. 2. Aufl., München: Vahlen. Schumacher, M. L., Hardzinski, M. L. & Schwartz, A. L. (1995). Increasing the Usability of Interactive Voice Response Systems: Research and Guidelines for Phone-Based Interfaces. Human Factors, 37(2), 251-264. Shearer, C. (2000). The CRISP-DM Model: The New Blueprint for Data Mining. Journal of Data Warehousing, 5(4), 13-22. Shebab, E. M., Sharp, M. W., Supramniam, L. & Spedding, T. A. (2004). Enterprise Resource Planning: An Integrative Review. Business Process Management Journal, 10(4), 359-386. Shrivastava, S. & Shaw, J. B. (2003). Liberating HR Trough Technology. Human Resource Management, 42(3), 201-222. Sinz, E. J. (1997). Architektur betrieblicher Informationssysteme. In: Rechenberger, P. & Pomberger, G. (Hrsg.), Handbuch der Informatik, München: Hanser, 875–887. Spengler, T. (2004). Personaleinsatzplanung. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 14691479. Stahlknecht, P. & Hasenkamp, U. (2005). Einführung in die Wirtschaftsinformatik, 11. Aufl., Berlin et al.: Springer. Staufenbiel, J. E. & Giessen, B. (2002). Electronic Recruiting Personalmarketing auf der Homepage, 2. Aufl. Köln: Staufenbiel Institut für Studien- und Berufsplanung.

376

Literaturverzeichnis Störmer, W. (1999). Integration der Zutrittskontrolle innerhalb von Zeitwirtschaftssystemen. CoPers, 2, 40-43. Stone, D. L., Lukaszeweski, K. M. & Isenhour, L. C. (2005). E-Recruiting: Online Strategies for Attracting Talent. In: Gueutal, H. & Stone, D. L. (Hrsg.). The Brave New World of e-HR. San Francisco: Jossey-Bass, 22-53. Strauß, B. & Kleinmann, M. (1995). Die formale Beschreibung computersimulierter Szenarien. In: Strauß, B. & Kleinmann, M. (Hrsg.), Computersimulierte Szenarien in der Personalarbeit, Göttingen: Hogrefe, 105-125. Strohmeier, S. (1995). Informationstechnologie-Werkzeuge für die Personalentwicklung, Computergestützte Personalarbeit, 4, 168-179. Strohmeier, S. (1996). SAP™ R/3 HR. Eine personalwirtschaftliche Einführung. Bamberger Betriebswirtschaftliche Beiträge, Nr. 111, Bamberg. Strohmeier, S. (1998). Reengineering, Artificial Intelligence and Virtualization. Innovations in Information Technology and Chances for Human Resource Management. In: Weber, W., Festing, M. & Kabst, R. (Hrsg.), Proceedings of the 6th International Conference on Human Resource Management, Paderborn. o.S. Strohmeier, S. (1999). Software Kompendium Personal. Anbieter, Produkte, Marktüberblick. Köln: Datakontext. Strohmeier, S. (2000). Informatisierung der Personalwirtschaft. Eine kritische Bestandsaufnahme gegenwärtiger Forschung. Wirtschaftsinformatik, 10, 90-96. Strohmeier, S. (2002). Electronic Human Resources: Begriff, Konzept und Praxis. Information Management & Consulting, 1, 614. Strohmeier, S. (2004). Informationstechnische Unterstützung der Personalarbeit. In: Gaugler, E., Oechsler, W. A. & Weber, W. (Hrsg.), Handwörterbuch des Personalwesens, 3. Aufl., Stuttgart: Schäffer-Poeschl, 905-918. Strohmeier, S. (2006). Coping with Contradictory Consequences of e-HRM. In: Ruël, H. & Bondarouk, T. (Hrsg.), Proceedings of the First European Academic Workshop on Electronic Human Resource Management, Twente, o.S. Strohmeier, S. (2007). Research in e-HRM: Review and Implications. Human Resource Management Review, 17(1), 19-37.

377

Literaturverzeichnis Strohmeier, S. & Piazza, F. (2005). Modellgestützte Personalentscheidungen mit »Data Mining«. Eine explorative Analyse am Beispiel der Regelinduktion. In: Kossbiel, H. & Spengler, T. (Hrsg.), Modellgestützte Personalentscheidungen 9, München & Mering: Hampp, 117-140. Strohmeier, S. & Diederichsen, A. (2006), Electronic Recruitment: Does the Internet Displace Conventional Print Media? In: Ruël, H. & Bondarouk, T. (Hrsg.), Proceedings of the First European Academic Workshop on Electronic Human Resource Management, Twente, o.S. Strohmeier, S. & Kabst, R. (2007), Do Current HRIS Meet the Requirements of HRM? An Empirical Evaluation Using Logistic Regression and Neural Network Analysis. Proceedings of the 1st International Workshop on HRIS, Madeira 2007, 31-44. Tannenbaum, S. I. (1990). Human Resource Information Systems: User Group Implications. Journal of Systems Management, 41(1), 27-32. Thomas, O., Leyking, K., Freifus, F. Fellmann, M. & Loos, P. (2007). Serviceorientierte Architekturen: Gestaltung, Konfiguraion und Ausführung von Geschäftsprozessen. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Saarbrücken, Heft 189. Troitzsch, K. G. (2004). Simulationsverfahren. Das Wirtschaftsstudium, 33(10), 1256-1268 und 1300-1302. Turau, V. (1999). Techniken zur Realisierung webbasierter Anwendungen. Informatik Spektrum, 22(1), 3-12. Ulmer, G. (2004). Gehaltssysteme erfolgreich gestalten. IT-unterstützte Lohn- und Gehaltsfindung, 2. Aufl., Berlin et al.: Springer. Ulrich, D. (1995). Shared Services: From Vogue to Value. Human Resource Planning, 18(3), 12-33. Vaduva, A. & Vavouras, A. (2004). Repositorium. In: Bauer, A. & Günzel, H. (Hrsg.), Data Warehouse Systeme. Architektur, Entwicklung, Anwendung. 2. Aufl., Heidelberg: d.punkt, 68-70. Vidmar, G. & Hudomalj, E. (2002). Decision Support for Everyone: OLAP in MS-Excel. Proceedings of the Conference on Data Mining and Data Warehousing (SIGKDD), Ljubljana, o.S.

378

Literaturverzeichnis Vlachakis, J., Kirchhof, A. & Gurzki, T. (2005). Marktübersicht Portalsoftware. Stuttgart: Fraunhofer Institut für Arbeitswissenschaft und Organisation. Vollmer K. & Gilpin, M. (2006). The Forrester Wave™: Enterprise Service Bus. Forrester Research Paper, o.O. Vollmer, K. & Peyret, H. (2006). The Forrester Wave™: Integration Centric Business Process Management Suites. Forrester Research Paper, o.O. Wagener, D. (2001). Psychologische Diagnostik mit komplexen Szenarios, Lengerich et al.: Pabst. White, S. E. (2004). Introduction to BPMN. IBM White Paper, o.O. Wiencke, W. & Koke, D. (1997). Call Center Praxis, Stuttgart: Schäffer-Poeschel. Wisskirchen, G. (2007). AGG Allgemeines Gleichbehandlungsgesetz. Auswirkungen auf die Praxis, 3. Aufl., Köln: Datakontext. WKWI (1994). Profil der Wirtschaftsinformatik. Ausführungen der Wissenschaftlichen Kommission Wirtschaftsinformatik. Wirtschaftsinformatik, 36(1), 80-81. Wright, A. (2003). Tools for Automating Complex Compensation Programs. Compensation & Benefits Review, 35(6), 53-61. Zachmann, J. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276-292. Zalud, B. (2000). Web Browsers as GUI. Security. 37(5), 69-70. Zampetti, R. & Adamson, L. (2001). Web-Based Employee SelfService: A Win-Win Proposition for Organizations and Employees. In: Walker, A. J. (Hrsg.), Web-Based Human Resources. New York: McGraw-Hill, 15-23.

379

Schlagwortverzeichnis A

B

Ablauforganisation 314 Abrechnungssystem Siehe Personalabrechnungssystem Abweichungsanalyse 163 ACD Siehe Automatic Call Distribution AGG Siehe Allgemeines Gleichbehandlungsgesetz Allgemeines Gleichbehandlungsgesetz 49, 203 Analyseprozess im Data Mining 164 Anwenderrollen 31, 266, 300, 319 Anwenderverwaltung 31, 266, 300, 319 Anwendungsschicht 4 Application Hosting 22 Application Service Providing 21, 177, 361 Approximationsalgorithmen 110, 130, 253 Arbeitsschutz 198 Arbeitssicherheit 198 Arbeitszeitgesetz 189 Arbeitszeitmanagementsysteme 179, 295 Arbeitszeitmodelle 180 Arbeitszeitplanung 184 Architektur Siehe Systemarchitektur ASP Siehe Application Service Providing Assoziationsanalyse 162 Auftragsdatenverarbeitung 46 Auftragsentwicklung 19 Ausschreibung 202 Authentifizierung 181, 194 biometrische 182 datenträgerbasierte 181 PIN/Passwort-basierte 183 Automatic Call Distribution 344 Automatisierte Einzelentscheidung 45 Autorensysteme 239, 257

B2E Siehe e-HRM Balanced Scorecard 268 BDE Siehe Betriebsdatenerfassung Bedarfsnivellierung 103 Bedarfsplanung 98 organisationsbasierte 100 simulationsbasierte 99 vergangenheitsbasierte 98 Berichtsgenerator 65 Beschaffungsmanagementsysteme 201, 295 Bescheinigungswesen 176 Besucheradministration 198 Betriebsdatenerfassung 188 Betriebsratsrechte 47 Betriebsvereinbarung 48 Betriebsverfassungsgesetz 46 Beurteilung Siehe Performance Management-Systeme Beurteilungskriterien 265 Beurteilungsmethoden 269 Beurteilungsprozess 267 Bewerberverwaltung Siehe Beschaffungsmanagementsysteme Bildungscontrolling 259 Blended Learning 245, 261 BPEL Siehe Business Process Execution Language BPM Siehe Business Process Management-Systeme BPMN Siehe Business Process Modelling Notation Branchenversionen 119, 290 Browserframes 358 Browsersysteme 241, 351 HTTP-Browser 360 Sprachbrowser Siehe Voice ResponseSysteme

381

Schlagwortverzeichnis WAP-Browser 352, 360 Bruttoentgeltermittlung 169 BSC Siehe Balanced Scorecard Budgetierung 280 Bundesdatenschutzgesetz 39 Business Activity Monitoring 312 Business Intelligence-Systeme 69, 145, 157 Business Process Diagramm 310 Business Process Execution Language 310 Business Process Management-Systeme 305 Business Process Modelling Notation 309 Business Process Outsourcing Siehe Outsourcing Business-to-Employee Siehe e-HRM

C Cafeteriasystem 284 CBT Siehe Computer Based TrainingSysteme CBT-Template 238, 257 CGI Siehe Common Gateway Interface Chat 208, 259, 357 Clusteranalyse 162 Cockpit 155, 360 Coded Information 83 Common Gateway Interface 354 Common Warehouse Metamodel 78 Compensation Management-Systeme Siehe Vergütungsmanagementsysteme Computer Based Training-Systeme 235 adaptierbare 243 adaptive 242 lineare 241 Computer Supported Cooperative Learning 244, 257 Computer Supported Cooperative Work 306 Computer Telephony Integration 207, 342 Computersimulierte Szenarien Siehe Szenariosysteme Content Management 252, 321

382

Content-Datenbank 251 Corporate Performance Management Siehe Performance ManagementSysteme Courseware Siehe Computer Based Training-Systeme CPM Siehe Performance ManagementSysteme CRISP-DM Siehe Cross Industry Standard Process for Data Mining Cross Industry Standard Process for Data Mining 158 CSCL Siehe Computer Supported Cooperative Learning CTI Siehe Computer Telephony Integration Customizing Siehe Systemimplementierung CWM Siehe Common Warehouse Metamodel

D Dashboard Siehe Cockpit Data Mining 65, 312 Data Mining-Systeme 69, 157 Data Warehouse-Systeme 69 Data Marts 71 virtuelle 70 zentrale 70 Datenanalyse (dis-)aggregierende 76, 149 multidimensionale 76, 146 mustererkennende Siehe Data MiningSysteme Datenanonymisierung 42, 165 Datenanreicherung 74 Datenarten 56 Datenbank 56 Datenbankabfrage 62 Datenbankdefinition 61 Datenbankmanipulation 62 Datenbankmodell 57 lineares 57

Schlagwortverzeichnis multidimensionales 60, 77, 153 objektorientiertes 59 relationales 58, 77, 152 Datenbanksysteme 55 Datenbankverwaltungssystem 61 Datengranularität 75 Datenhaltungsschicht 4 Datenhistorisierung Siehe Datentemporalisierung Datenintegration 293 Datenorganisation 56 Datenpräaggregation 153 Datenpseudonymisierung 42, 165 Datenschutz 39 Datenschutzaudit 43 Datenschutzbeauftragter 44 Datensicherheit 42 Datensparsamkeit 42 Datentemporalisierung 75, 293 Datenverdichtung 74 Datenvermeidung 42 Datenwürfel 60, 77, 147 Demand-Pull 17 DEÜV Siehe Verordnung Erfassung und Übermittlung von Daten für Träger der Sozialversicherung Digitale Bewerberakte 90, 203 Digitale Personalakte 89 Digitale Signatur 85 Digitalisierung 83 DIN 33430 216 Diskussionsforum 258, 322 Dokumentenmanagementsysteme 81, 203, 323 Dokumentenviewer 87 Drill Down & Roll Up Siehe Datenanalyse, (dis-)aggregierende

E EAI Siehe Enterprise Application Integration e-Assessment 208, 215, 225 e-Business 290

e-HRM 33, 166, 327, 360 Eigenentwicklung 19 Eignungsdiagnostik 233 Einsatzplan 116 e-Learning Siehe Computer Based Training-Systeme und Learning Management-Systeme Electronic Human Resource Management Siehe e-HRM Electronic Mail Siehe e-Mail Electronic Recruiting Siehe Beschaffungsmanagementsysteme Elektronische Bewerberakte Siehe Digitale Bewerberakte Elektronische Personalakte Siehe Digitale Personalakte Elektronische Post Siehe e-Mail Elektronische Stecktafel 118 e-Mail 206, 258, 322, 332, 343, 356 Embedded Systems 192 Employee Interaction Center Siehe Service Center Employee Self Service Siehe Self Service EN 50133 192 Enterprise Application Integration 306, 318 Enterprise Portal Siehe Portalsysteme Enterprise Resource Planning-Systeme 289 Entgeltzahlung 174 e-Performance Siehe Performance Management-Systeme EPK Siehe Ereignisgesteuerte Prozesskette e-Recruiting Siehe Beschaffungsmanagementsysteme Ereignisgesteuerte Prozesskette 296, 307 Ergebnisprofil 221 ERP-Systeme Siehe Enterprise Resource Planning-Systeme e-Shop 323 ETL Siehe Extraktion, Transformation und Laden Europäische Datenschutzrichtlinie 40 Exception Reporting 143, 151 Extensible Markup Language 353

383

Schlagwortverzeichnis Extraktion, Transformation und Laden 72

F FASMI Siehe Fast Analysis of Shared Multidimensional Information Fast Analysis of Shared Multidimensional Information 146 Filtering 209 Finanzbuchhaltung 174 Freeware 23 Funktionsintegration 295

G GDPdU Siehe Grundsätze Datenzugriff und Prüfbarkeit digitaler Unterlagen Geschäftsprozess 101 Geschäftsprozessmanagementsysteme Siehe Business Process ManagementSysteme Gesetzliche Abzüge 175 GKV Zertifikat 51, 175 Gleichbehandlung Siehe Allgemeines Gleichbehandlungsgesetz GoBS Siehe Grundsätze ordnungsmäßiger Buchführungssysteme Groupware 322 Grundgesetz 39 Grundsätze Datenzugriff und Prüfbarkeit digitaler Unterlagen 52 Grundsätze ordnungsmäßiger Buchführungssysteme 51

HR-XML 61 HTML Siehe Hypertext Markup Language HTML-Editor 257, 356 HTTP Siehe Hypertext Transfer Protocol Hub-and-Spoke 71 Human Capital Management-Systeme 10 Hyperlink 353 Hypermedia-Dokument 351 Hypertext Markup Language 353 Hypertext Transfer Protocol 353 Hyperwürfel 60, 77, 147

I Indexierung 85 Individualsoftware 20 Informationelle Selbstbestimmung 39 Informationsabfrage 63 Instant Messaging-Dienst 357 Integrationsschicht 5 Intelligente Tutorielle Systeme 243 Internet Protocol Adresse 354 Internetbrowser Siehe Browsersysteme Interpretations- und Befundungshilfe 221 IP-Adresse Siehe Internet Protocol Adresse ITSG-Zertifikat 51, 175 IVR Siehe Voice Response-Systeme

J Jobagent 206 Jobbörse 213

H

K

Handheld Siehe Personal Digital Assitant HCM Siehe Human Capital ManagementSysteme HR Cockpit Siehe Cockpit HR Portal Siehe Portalsysteme HR Service Center Siehe Service Center

Kantinendatenerfassung 188 Karriere- und Nachfolgeplanung Siehe Personalentwicklungsplanungssysteme Karriereplan 125 KDD Siehe Data Mining-Systeme Key Performance Indicator 155

384

Schlagwortverzeichnis Klassifikationsanalyse 161 Knowledge Discovery-Systeme Siehe Data Mining-Systeme Konferenzsysteme 258, 323 Kostenrechnung 175 Kreuztabellenabfrage 64 Kurskatalog 249, 253

L Landesversion 276, 290 Laufbahn 123 Learning Content Management-Systeme 239, 252 Learning Management-Systeme 236, 244, 247, 273 Learning Objects Metadata 240 Leasing 21 Leistungsbeurteilung 280 Leitstand Siehe Cockpit Lernmanagementsysteme Siehe Learning Management-Systeme Lernobjekte 237 Lernplattformen Siehe Learning Management-Systeme Lernportal 244 Lizenz 20 Lohn- und Gehaltsabrechnung Siehe Personalabrechnungssysteme LOM Siehe Learning Objects Metadata

M Makroarchitektur 3 Mandantenfähigkeit 168, 248, 291 Matching 126, 209, 221 Mediaplayer 358 Meldewesen 175 Metadatenbank 77, 88, 240 Mikroarchitektur 3 Mitarbeiterportal Siehe Portalsysteme Mitarbeiterzuordnung 115 Mitbestimmung 46

Multidimensional Expressions 150 Multisourcing Siehe Outsourcing Muss-Datenfeld 62

N Nachfolgeplan 125 Nettolohnermittlung 171 Normvergleich 221

O OCR Siehe Optische Zeichenerkennung ODMA Siehe Open Document Management Alliance ODS Siehe Operational Data Store OLAP 312 hybrides 153 multidimensionales 153 relationales 152 Online Analytical Processing-Systeme 60, 69, 145 Online Transaction Processing 145 Online-Bewerbungsformular 207 Open Document Management Alliance 82 Open Source Siehe Freeware Operational Data Store 76 Optical Character Recognition Siehe Optische Zeichenerkennung Optische Zeichenerkennung 84 Organizer Siehe Personal Digital Assitant Outsourcing 35, 348

P Parametrisierung 27, 87, 299 PDA Siehe Personal Digital Assistant PEP Siehe Personaleinsatzplanungssysteme Performance Management-Systeme 263, 295 Personal Digital Assistant 352

385

Schlagwortverzeichnis Personal Services 326 Personalabrechnungssysteme 167, 186 Personalbedarfsplanungssysteme 95 Personalberichterstattung Siehe Datenbanksysteme Personalbeurteilungssysteme Siehe Performance Management-Systeme Personaldatenerfassungssysteme Siehe Arbeitszeitmanagementsysteme Personaldispositionssysteme Siehe Personaleinsatzplanungssysteme Personaleinsatzplanungssysteme 107, 185, 295 Personalentwicklungsplanungssysteme 121, 295 Personalinformationssysteme i.e.S. 67 Personalisierung 320 Personalkostenarten 136 Personalkostenplanung Hochrechnung 138 Simulation 140 Zeitreihenanalyse 139 Personalkostenplanungssysteme 133, 287, 295 Personalstammdatenhaltung Siehe Datenbanksysteme Personenbezogene Daten 40 Pflichtenheft 18, 25 Pivottable Siehe Kreuztabellenabfrage Plug In 257, 352 Podcast 208 Portalanwendungen 321 Portalsysteme 317 Portlet 324 Präsentationsschicht 5 Problemlöseszenarien Siehe Szenariosysteme Profilvergleich 129 Projektzeiterfassung 188 Prozessmodellierung 307 Prozessmonitoring 312 Prozesssimulation 312 Prozesssteuerung 298

386

Q Qualifikationsdatei 122 Quellsysteme 72, 151

R Radio Frequency Identification 182 Ranking 209 Raumbilanzierung 197 Referenzdatenmodell 154, 292 Referenzprozesse 266, 307 RFID Siehe Radio Frequency Identification

S Schichtblock 114 Schichtenmodell 4 Schichtplanung 111 SCORM Siehe Sharable Content Object Reference Model Self Service 31, 256, 267, 286, 326, 335, 343, 355, 361 Bewerber Self Service 33, 207 Manager Self Service 32 Mitarbeiter Self Service 33 Seminarmanagementsysteme Siehe Learning Management-Systeme Service Center 33 Agenten 340 Anfragehistorie 341 Geschäftsprozesse 340 Multi Channel Management 341 Skripte 340 Wissensdatenbank 340 Service Center-Systeme 34, 339 Service Delivery 349 Service Level Agreement 22, 347 Service-Bus 13 Serviceorientierte Architektur Siehe Systemarchitektur, serviceorientierte

Schlagwortverzeichnis Service-Repository 13 Sharable Content Object Reference Model 239 Shared Service Center Siehe Service Center Shareware Siehe Freeware Short Message Service 109, 207 Simulation 99 Single Sign On 319 Skill Based Routing 336, 344 Slicing & Dicing Siehe Datenanalyse, multidimensionale Smart-Phone 352 SOA Siehe Systemarchitektur, serviceorientierte Software On Demand Siehe Application Service Providing Sperrelemente 194 Sprachbasiertes Browsen 334 Sprachbasiertes Mailen 334 Sprachportal Siehe Voice ResponseSysteme Sprachscanner 271 Sprecherausschussgesetz 46 SQL Siehe Structured Query Language Staging Area 74 Stammdaten Siehe Datenarten Standardabfrage 63 Stellenbewertung 279 Steuerungsleistung 231 Strategie Siehe Systemplanung Structured Query Language 61 Suite Siehe Systemarchitektur, modulare Systemakzeptanz 28 Systemanwendung 30 Systemarchitektur 3 fragmentierte 10 modulare 9, 296 monolithische 7, 296 serviceorientierte 12, 26, 302, 315 Systemauswahl 25 Systembereitstellung 18 Systembezug 20 Systementwicklung 18 Systembetrieb 30

Systemimplementierung 26 organisatorische 28 technische 26, 298 Systemintegrator 29 Systemplanung 16 operative 17 strategische 16 Szenariostruktur 227 Szenariosysteme 208, 225

T Tabellenkalkulation 49, 143, 155 Talent Management-Systeme 10 Talent Relationship Management 212 Tankdatenerfassung 188 TCP/IP 354 Technology-Push 17 Telefax 343 Teleseminar 258 Teletutoring 258 Terminal 180, 192 Testentwicklung 217 Testnormierung 217 Testsysteme 208, 215 Text Mining 166 Tracking 207, 210, 260, 272

U Uniform Resource Locator 354 URL Siehe Uniform Resource Locator

V Vakanz 202 Vergütungsmanagementsysteme 273, 275 Verhaltensleistung 232 Verordnung Erfassung und Übermittlung von Daten für Träger der Sozialversicherung 41, 50, 175 Verteilte Systeme 180, 192, 290

387

Schlagwortverzeichnis Viewer Siehe Dokumentenviewer Virtual Learning Environments Siehe Learning Management-Systeme Virtuelle Modularisierung 8 Virtuelle Personalabteilung 33 Virtuelles Klassenzimmer 258 Voice Mail 345 Voice Response-Systeme 329, 342 Voice-Portal Siehe Voice ResponseSysteme

Workflowmanagementsysteme Siehe Business Process Management-Systeme Workforce Management 10, 105, 107, 119, 190 Workplace Siehe Portalsysteme World Wide Web 353 WWW-Browser Siehe Browsersysteme

W

XML Siehe Extensible Markup Language XML Process Definition Language 311

WBT Siehe Computer Based TrainingSysteme Web Siehe World Wide Web Web Mining 166 Web Service Description Language 313 Web Services 313 Webbasiertes System 6, 33, 61, 203, 236, 359 Webbrowser Siehe Browsersysteme Weblog 208 Weiterbildungsplanung 124 Werkschutz 198 Work[force]-Scheduling System Siehe Personaleinsatzplanungssysteme Workflow 27, 204, 256, 266, 282, 296, 306, 322 Workflowengine 296

388

X

Z Zeitbewertung 185 Zeiterfassungssysteme Siehe Arbeitszeitmanagementsysteme Zeitkonten 181 Zeitkorrekturen 186 Zielkaskadierung 268 Zutrittsberechtigung 193 Zutrittsdaten 193 Zutrittskontrollsysteme Siehe Zutrittsmanagementsysteme Zutrittsmanagementsysteme 191 Zutrittssteuerung 196 Zweckbestimmung 41