Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Migracja danych - plug & play?

Poznaj problemy, z którymi mierzą się konsultanci podczas migracji danych do systemów HCM.
27 08 2018

Migracja danych to ważny element wdrożenia nowego systemu w organizacji. Kluczowa jest tu odpowiednia jakość i wykonanie całej operacji w terminie. Jeżeli te warunki nie zostaną spełnione, to wejście na produkcję może zostać znacznie przesunięte lub w ogóle nie dojść do skutku. Bardzo często bagatelizuje się wyzwanie, jakie stoi tu przed zespołem projektowym, a migracja okazuje się później piętą achillesową projektu. Ręka do góry - kto zawsze idealnie oszacowuje migrację na swoich wdrożeniach?

Najpierw kilka słów dla niewtajemniczonych.

System HCM w służbie HR-u

System HCM przede wszystkim ułatwia zarządzanie kadrą organizacji. Do jego funkcji zaliczyć można obsługę procesów HR-owych - np. zatrudniania czy zwalniania - oraz dostarczanie wszelkiego rodzaju raportów wspomagających decyzje. W związku z tym dane, które trzeba zmigrować, dotyczą przede wszystkim organizacji i w niej zatrudnionych.

A przykład?

Dobry przykład systemu HCM znajdziemy w firmie Workday, która ma setki klientów na całym świecie, w tym największe przedsiębiorstwa takie jak Amazon czy Walmart. Workday HCM to produkt główny, ale w ofercie są również inne moduły (np. finansowy, do zarządzania projektami). Czas implementacji u klientów jest zróżnicowany, ale średnio wynosi dziewięć miesięcy. Na stronie firmy można znaleźć więcej informacji o systemie.

Rozważmy studium przypadku wdrożenia Workday w dużym przedsiębiorstwie.

Wdrażanie Workday 

To projekt wykonany przez PwC w ostatnich latach, gdzie głównym wyzwaniem była właśnie migracja danych. Klient - firma z branży energetycznej - zatrudnia ponad 10 000 pracowników w ponad 50 krajach na sześciu kontynentach. Rozkład pracowników był nierównomierny; w niektórych krajach zatrudnionych było ponad 600 osób, w innych mniej niż 30. Oto kilka kluczowych informacji, które wpłynęły na wybór rozwiązania.

  1. Firma nie posiadała wcześniej globalnego systemu HCM. Była całkowicie zdecentralizowana zarówno w kontekście przechowywania danych, jak i - w wielu aspektach - decyzyjności. W zależności od regionu i kraju do przechowywania danych wykorzystywano: systemy lokalne, bazy danych, pliki Excel lub fizyczne nośniki (takie jak pełna papieru szafa pancerna o wadze 4200 kg).
  2. Właścicielem danych były lokalne grupy HR, które nie zawsze posiadały wsparcie pionu IT. Umiejętności techniczne wielu z tych osób nie wykraczały poza podstawy Excela.
  3. Nie funkcjonował unikalny, globalny identyfikator pracowników czy jakiegokolwiek innego typu danych.
  4. Pojęcie master data management nie istniało, stąd też nie było globalne ustalonych, dozwolonych wartości dla wszelkiego rodzaju danych. Przykładowo: Emiraty Arabskie dzieliły pracowników na standardowych i tymczasowych, a Holandia na regularnych, praktykantów, zatrudnionych na czas określony, kontraktorów, konsultantów i 11 innych typów.
  5. Na deser pozostaje fakt, że dane przechowywane były często w językach lokalnych, np. portugalskim


To - niepełny jeszcze - zarys problemów rozpoznanych na starcie projektu, który nakreśla warunki, w jakich mieliśmy wprowadzić wdrożenie. W podanej sytuacji mamy całkowicie zdecentralizowany system, w większości nietechniczny zespół kliencki i - potencjalne - ogrom wynikających z tego problemów. Nieprawidłowe przeprowadzenie migracji (np. utrata danych, złe mapowanie) może spowodować błąd, w wyniku którego setki pracowników dostaną nieodpowiednie wypłaty (bo Workday dostarczać będzie dane do systemu obsługującego payroll) czy też złamanie prawa (np. w niektórych krajach obowiązkowe jest posiadanie informacji o pochodzeniu etnicznym zatrudnionych, a w innych jest to zabronione). Możemy też mieć do czynienia z tysiącami niezadowolonych pracowników z uwagi na standaryzację nazewnictwa, np. tytułów biznesowych.

Jak to ugryźć?

Jak przeprowadzić ten proces efektywnie? To nie jest sytuacja, w której można wziąć stary system, zrobić całkowicie zautomatyzowany proces ETL (Extract, Transform, Load) na podstawie mapowania dostarczonego przez HRIS klienta i w sposób mało problematyczny zakończyć projekt.

PwC zaproponowało podejście hybrydowe. Czerpało z rozwiązań technologicznych, biorąc pod uwagę koszt automatyzacji konkretnych czynności w porównaniu do ich manualnego wykonania. Koniec końców musi być nie tylko wdrożony z sukcesem, ale również w ramach budżetu i w określonym czasie.

Na początku powstał zespół centralny w składzie: manager projektu, ekspert funkcjonalny Workday, ekspert techniczny Workday, architekt migracji, developer baz danych/ETL, globalny architekt ERP. Jego jedna część to pracownicy klienta znający środowisko, a druga: konsultanci PwC mający doświadczenie w tego typu wdrożeniach. Określiliśmy, że migracja będzie składać się z czterech cykli, a każdy z nich z czterech części: zbierania danych, dostarczenia, walidacji i ładowania. Każdy kolejny cykl będzie miał na celu poprawienie jakości zebranych danych.

Rozpoczęliśmy od spotkań z przedstawicielami HR z różnych regionów, przedstawienia projektu i jego zakresu. Celem było zbudowanie eksperckich zespołów lokalnych, złożonych z ponad 30 osób z różnych krajów i zebranie wszelkiego rodzaju wartości konfiguracyjnych. W niektórych przypadkach dodatkowo potrzebny był research: czy to z departamentem prawnym, czy to finansowym, w innych konsultacja z tłumaczem. Spotkania były prowadzone poprzez telekonferencje, jak i na żywo. Spotkania na żywo były istotne nie tylko z uwagi na dostarczenie wyniku. Pozwoliły również nawiązać relacje między centralą, a zespołami krajowymi. Stworzono słownik globalnych wartości.

Kolejne konsultacje miały na celu zapewnienie, że wszelkie wartości lokalne zostały poprawnie zmapowane. Na tym etapie niezwykle istotną rolę odegrał data steward, który upewniał się, czy wszelkie wymagania prawne są spełnione. Mogło się np. okazać, że - zgodnie z prawem - w niektórych zawodach w krajach arabskich firma ma obowiązek przechowywać informację o grupie krwi, a do tego w konkretnym formacie).

Globalny format pliku

Następny krok: dostarczenie uniwersalnego formatu pliku, w którym lokalne grupy będą dostarczać dane. Zdecydowano się na najlepiej rozpoznawany w organizacji Excel. Dodatkowym atutem tegoż była możliwość budowy narzędzia w VBA, które pozwalało na zautomatyzowanie badania jakości danych jeszcze przed ich dostarczeniem do centrali. Zbudowaliśmy setki makr, które sprawdzały m.in. spójność danych i czy wartości zgadzają się z master data. Video szkolenia ze stworzonego formatu pliku objaśniały krok po kroku, jak należy go wypełnić. Excel miał też zaletę w postaci wszechobecnych, bezpłatnych szkoleń w Internecie - w przypadku potrzeby uzupełnienia wiedzy któregoś z członków zespołu.

Idea: każda lokalna grupa w każdym cyklu migracji dostarcza plik Excel z wypełnionymi danymi. Z każdym kolejnym cyklem dane miały mieć wyższą jakość, określoną na wyjściu poprzez konkretną liczbę błędów/problemów. Kraje z największą liczbą pracowników, by wypełnić plik Excel, użyły zautomatyzowanych procesów (np. ETL przy użyciu Informatica PowerCenter lub kwerend SQL bezpośrednio wykonanych na bazie). Kraje, w których pracowników było mniej, wykonały zadanie manualnie.

Wbudowana walidacja poprzez makra uruchamiała się w pliku automatycznie. Grupę lokalną wspierał odpowiednio zespół centralny. Miała za zadanie dostarczenie danych i utrzymanie licznika błędów na poziomie zero. Pliki trafiały następnie do centralnego repozytorium, które je łączyło. Repozytorium posiadało dodatkowe wbudowane reguły, by zapewnić, żę złączenie przebiegło poprawnie.

Model wymiany poufnych informacji

Informacje były poufne i wrażliwe (np. pensja pracowników). Dlatego też odpowiedni model wymiany plików między grupami był koniecznością. Tu świetnie zadziałał wykorzystywany już w organizacji Microsoft Sharepoint. Dzięki niemu określone grupy miały dostęp tylko do określonych katalogów, a nie plików innych grup lokalnych czy całego repozytorium, a zautomatyzowane pobieranie i łączenia plików było stosunkowo łatwe. W przypadku błędów czy pytań zespół centralny wracał do grup lokalnych z listą zadań do wykonania. Z centralnego repozytorium dane ładowane były do Workday poprzez web service w Java. Dzięki utworzeniu globalnego repozytorium możliwe było nadanie odpowiednich, unikalnych kluczy, np. globalnego numeru pracownika. Inną zaletą była możliwość dokładnej analizy wykonanej przez centralny zespół jeszcze przed ładowaniem do systemu.

Wdrożenie

Wdrożenie odbyło się w zakładanym czasie, kilkanaście procent poniżej określonego budżetu. Udało się nie tylko zmigrować dane z całkowicie zdecentralizowanego środowiska, ale również dokonać globalnej standaryzacji setek obiektów i dziesiątek tysięcy wartości. Zespoły HR klienta na całym świecie zaczęły używać tego samego języka do opisu procesów i danych. Stworzenie raportu dotyczącego np. różnorodności zatrudnienia było zautomatyzowane i nie zajmowało już, tak jak wcześniej, dwóch tygodni.

Największą zaletą podejścia była duża personalizacja i sprofilowanie metodyki zbierania informacji na poziomie lokalnym z zachowaniem centralnego procesu łączenia, walidacji i ładowania danych. Nie zawsze bowiem ma sens tworzenie skomplikowanych, zautomatyzowanych procesów dla każdego z krajów z osobna - dla samej sztuki ich tworzenia. Niezwykle istotne okazało się użycie narzędzi do kontroli jakości, takich jak wspomniane VBA czy odpowiednio przygotowane centralne repozytorium.

Największa przeciwność? Konieczność zarządzania i pracy z ogromnym zespołem w różnych strefach czasowych.

Dodatkową nauką wyciągniętą z projektu jest fakt, że tak wczesne zaangażowanie grup lokalnych jest wyjątkowo korzystne dla późniejszego „go live” systemu. Osoby te w naturalny sposób stają się ekspertami i ambasadorami nowego systemu w swoim otoczeniu. Niezwykle ułatwia to pierwsze miesiące pracy po wdrożeniu.

Cz w takim razie migracja danych to techniczny plug & play i całkowity no brainer?

Nie do końca.

Niewątpliwie przedstawione problemy znacznie różnią się od tych, które napotyka np. JavaScript developer podczas tworzenia nowej strony internetowej. Przy wdrożeniu HCM  rozwiązanie nie jest często jednoznaczne, można obrać wiele dróg. Wymagana jest elastyczność technologiczna - na jednym projekcie mamy szansę, by użyć VBA, SQL czy też Javy. Potrzebna jest wiedza czysto techniczna, ale też umiejętność swobodnej pracy z klientem w międzynarodowym środowisku.