HR meets IT

Gerade im HR-Management laufen IT-Realisierungsprojekte nicht so rund wie in anderen Bereichen. Einfache Erklärungsversuche für diese langjährigen Praxisbeobachtungen beschränken sich oftmals darauf, dass die Qualität von Systementscheidungen für den Support von HR-Prozessen insbesondere darunter leiden, dass

• 
IT-Bereiche selten gute Kenntnisse zum Anbietermarkt für HR-Systeme haben,  sich zumeist wenig in den funktionalen Anforderungen aus den HR-Prozessen auskennen und zudem zu wenig auf User-Friendliness fokussieren. Gerade Letzteres ist jedoch bei HR-Systemen mit der speziellen Anwendergruppe «Führungskräfte», die nicht immer eine hohe «E-Readiness» mitbringen, oftmals Kernanforderung;
• 
HR-Bereiche selten über ausreichende IT-Kompetenz verfügen und wenig Verständnis für Abhängigkeiten haben, die integrierte System-(ERP-)Landschaften mit sich bringen. HR-Bereiche verlagern Probleme unsystematischer, nicht end-to-end-definierter Prozesse gerne auf die IT.

Diese beiden stereotypen Erklärungsmus-ter haben sicherlich in vielen Organisationen einen wahren Kern. Um konkrete 
Probleme zu lösen, sollte allerdings detaillierter analysiert werden, wo die Schwachpunkte liegen. Die Erfahrung zeigt, dass HR-IT-Projekte insbesondere darunter leiden, dass Anforderungsanalysen eher «quick & dirty» durchgeführt werden, was dann häufig dazu führt, dass

• 
«Besonderheiten» in heutigen Instrumenten und Prozessen unreflektiert als USPs definiert und dann als Anforderungen festgeschrieben werden, ohne zu prüfen, ob der Systemstandard nicht ebenfalls ausreichend wäre;
• 
andererseits Standards unreflektiert übernommen werden auch dort, wo Individualität ratsam wäre;
• 
Unterschiede zwischen verschiedenen Organisationseinheiten oder Ländern während der Analyse- und Konzeptionsphase zu wenig betrachtet werden und später zu teuren und zeitraubenden Nacharbeiten führen;
• 
Datenschutzaspekte zwar in ihrer Relevanz erkannt werden, aber die Ausgestaltung in Prozess- und IT-Umsetzung, insbesondere im globalen Kontext, zu wünschen übrig lässt;
• 
es keinen eindeutigen Process Owner gibt und die Schnittstelle zwischen HR und IT mehr schlecht als recht organisiert ist.

Vor diesen allgemeinen Beobachtungen können die folgenden Empfehlungen für eine reibungslose HR-IT-Unterstützung 
gegeben werden:

Beraterauswahl

• 
Validierung, dass der Berater Leading Practices zu den umzusetzenden Prozessen mitbringt und somit die Analyse- und Konzeptionsphase effizient gestalten kann.
• 
Wenn eine neutrale Systemauswahl gewünscht wird, um das System zu finden, das am besten geeignet ist, ist es wichtig, einen Berater auszuwählen, der keine Eigeninteressen hat, also zum Beispiel für einige Systeme eigene Realisierungskapazitäten zur Verfügung stellen könnte und somit zumindest ein unterschwelliges Interesse an der Realisierung bestimmter Systemlösungen hat.
• 
Wenn das System bereits feststeht (zum Beispiel Lösung innerhalb der ERP-Strategie): Auswahl eines Beraters mit nachweisbarer Expertise in diesem System, damit nicht Funktionalitäten definiert werden, die hinterher nicht abbildbar sind.
• 
Eindeutige Definition des Scopes des Beratungsprojektes: Wann und mit welchem Ergebnis endet das Mandat, an wen wird wie übergeben?

Analyse

• 
Bei umfangreicheren HR-IT-Vorhaben ist eine Anforderungsanalyse unerlässlich. Diese sollte auf Basis etablierter Leading Practices erfolgen. Somit muss nicht jeder Prozess des Status quo im Detail beschrieben werden. Stattdessen erfolgt eine Analyse des Unterschiedes des Ist-Standes zu praxiserprobten Prozeduren. Bei Abweichung vom Musterprozess erfolgt dann die Festlegung, ob der Unterschied gerechtfertigt ist (Erfolgsfaktor für das Business vs. historisch gewachsene Besonderheiten ohne erkennbaren Mehrwert).
• 
Bei der Definition der Anforderungen sollte mit dem Prozessergebnis begonnen werden: Welche Outputs soll ein Sys-tem liefern (Reports, Analyseergebnisse, Prozessergebnisse)? Dies hilft sehr, Datenmodelle auf Vollständigkeit zu überprüfen.
• 
Definition und Gewichtung der Bewertungskriterien zur Systemauswahl sollten vor der Markt-/Systemanalyse erfolgen. Ein ausgewogener Anforderungskatalog mit technischen, funktionalen, überfachlichen und wirtschaftlichen Bewertungskriterien und einem abgeleiteten Raster der Nutzwertanalyse sollte frühzeitig mit den Entscheidungsträgern abgestimmt werden. Ein nachträgliches «Verbiegen» der Beurteilungskriterien zur Beeinflussung der Entscheidung ist dann deutlich erschwert.

Konzeption

• Kritische Überprüfung aller Funktionen und Versuch der Reduzierung auf das Wesentliche aus Sicht der späteren Anwender.
• 
Fokussierung auf Handhabbarkeit durch die Anwender, insbesondere wenn Self-Service-Szenarien für Mitarbeiter und Führungskräfte geplant werden.
• 
Ein HR-IT-Projekt sollte immer auch genutzt werden, um Prozesse zu optimieren. HR gewinnt an Reputation, wenn die verschiedenen Personal- und Führungsprozesse durch effektive Umsetzung in IT erkennbar «aus einem Guss» wirken, insbesondere aus Sicht der Anwender.

Organisation

• 
Schnittstelle zwischen HR- und IT-Bereich über eine eHR-Funktion (je nach Grösse auch Team/Abteilung) abbilden. Organisatorische Aufhängung im HR-Bereich, eindeutige Ansprechpartner in der IT. eHR hat dann die «Hoheit» über das Stammdatensystem und erzielt hohe Governance über das Organisationsmanagement (es kann keine Stelle geben, die nicht dort angelegt wurde, es kann keinen User-Account geben, ohne dass dort Information geflossen ist).
• 
Supportorganisation definieren, insbesondere bei weltweitem Roll-out.
• 
Bei On-demand-/SaaS-Konzepten frühzeitig datenschutzrechtliche Aspekte für die Vertragsverhandlungen mit aufbereiten.

Datenschutz

• 
Sofern relevant, sind alle internationalen Aspekte zu berücksichtigen. Werden neue Lösungen für Prozesse geschaffen, die bisher nicht durch IT unterstützt wurden, besteht zumeist hoher Regelungsbedarf (insbesondere zum Beispiel bei Prozessen wie eRecruiting und Talent Management). Verstösse gegen Datenschutzbestimmungen werden (ins-besondere in Zukunft) sehr teuer und kosten in hohem Masse Reputation. Besonders für Standorte in der EU zeigen sich hohe Anforderungen bei gleichzeitig hohen landesspezifischen Besonderheiten (insbesondere Deutschland und Frankreich).
• 
Zum Datenschutz im Personalmanagement sei auf eine aktuelle Studie des 
BitKom-Verbands hingewiesen: www.
bitkom.org/de/presse/8477_72844.aspx

Vendor Selection

• 
Wer muss an der Entscheidung beteiligt werden, damit diese nachhaltig Akzeptanz erfährt (Personen, Bereiche, Sparten, Länderorganisationen ...)?
• 
Reduzierung der Liste möglicher Anbieter auf eine fokussierte Shortlist über eindeutige K.-o.-Kriterien (etwa ASP-Lösung zulässig, point-&-time-fähig ...).
• 
Detaillierte Ausschreibungsunterlage. Zwang der Anbieter, dem Raster des Ausschreibenden zu folgen und kein Standardangebot zu legen. Hierfür ist es wichtig, relevante Use Cases festzulegen, also die Anwendungsfälle zu beschreiben, die den grössten Nutzen bringen und die spezifischen Bearbeitungsweisen und individuellen Besonderheiten der Organisation aufzeigen. Die Anbieter müssen dann hierzu Lösungskonzepte aufzeigen.
• 
Beschränkung von Pitch-Präsentationen auf fokussierte Diskussion der Use Cases.
• 
Besonderen Wert auf das  Projektteam des Anbieters legen: Erfahrung/Kompetenz der vom Dienstleister eingesetzten Mitarbeiter ist zumeist sehr wesentlich für den Projekterfolg.
• 
Bewertung des gesamten Angebots durch das Projektteam unter Beteiligung von IT und HR, evtl. unter Hinzuziehung eines neutralen Moderators.

Vertragsgestaltung

• 
Nicht nur auf Hauptkosten (Lizenzen, Service) fokussieren, sondern auch die Punkte detailliert definieren, die häufig in der Realisierung hohen Zusatzaufwand hervorrufen, zum Beispiel:

    – Abbildung von Workflows
    – Implementierung von Reports
    – Ausgestaltung Rechtemanagement
    – 
Anwenderschulung, Erst-Training und 
Re-Training

Projektansatz

• 
Es klingt trivial: Stringentes Projektmanagement mit klaren Meilensteinen und Quality Gates sollte selbstverständlich sein, leider ist es das viel zu häufig nicht.
• 
Frühzeitiges Klären von Altdatenübernahme/Migration. Zumeist sinnvoll: Migration nutzen, um Qualitätssicherung der Daten vorzunehmen. Hierfür ist manuelle Kapazität notwendig, eine frühzeitige Planung wichtig.
• 
Je nach Einsatz- und Anwendungsfeld, besonders bei neu unterstützten Prozessen, ist eine zweistufige Pilotierung zu empfehlen:

1. 
«Rapid Prototyping»: Schnell umgesetzte Click Dummies, gegebenenfalls sogar nur Papierversionen, um Akzeptanz der Lösung insbesondere bei Usern ausserhalb des HR zu prüfen. («Liebe Führungskraft, wäre dir mit einem solchen Portal für alle MA-bezogenen Themen/Prozesse geholfen? Welche Verbesserungsvorschläge hast du?»)
2.  
Lösungs-Prototyp: Test der 95-Prozent-Lösung mit realen Daten in einzelner Organisationseinheit. Erkennen von Anpassungsbedarf vor dem Flächen-Roll-out.

Abnahme

• 
Definition der Abnahmekriterien bereits im Vertrag mit dem Realisierungspartner.
• 
Gewissenhafte Ausgestaltung, wenn Softwarehersteller und Realisierungspartner unterschiedliche Unternehmen sind.

Anwendung

• 
Konsequenz in der Umsetzung, keine Umgehungsstrategien zulassen.
• 
Supportkonzept konsequent umsetzen.
• 
Akzeptanzanalyse im Nachgang, Validierung von Nutzen und Akzeptanz und Auswertung aller «Lessons Learned».

Diese Empfehlungen sind in Gänze sicherlich nicht immer umsetzbar. Kern sollte es sein, Emotionen zwischen der IT («Im Endeffekt sitzen wir am längeren Hebel») und dem HR («Die Technik interessiert nicht, unsere Forderungen müssen 1:1 umgesetzt werden») nach Möglichkeit herauszuhalten und aus übergeordneter Perspek-tive das Optimum zu erzielen.