Proces migracji danych ze starego systemu ERP do nowego zawsze jest wyzwaniem dla organizacji. Im więcej pracowników i bardziej złożona struktura firmy, tym migrowanie danych może okazać się bardziej czasochłonne oraz kosztowne. Nieoceniona pozostaje w tym procesie rola analityka, od którego zależy forma i jakość zebranych wymagań oraz dobór sposobu migracji danych do nowego środowiska.
W niniejszym artykule przedstawię przykład, jak przebiegała praca analityka i na czym polegała jego rola w globalnym projekcie migracji danych z SAP-a moduł HR do systemu Workday.
Systemy klasy ERP
Na wstępie przypomnijmy, czym w ogóle są systemy takie jak SAP i Workday. Należą one do systemów klasy ERP, które stanowią zbiór powiązanych ze sobą rozwiązań informatycznych, wspierających kluczowe procesy całego przedsiębiorstwa. Obecnie odchodzi się od praktyki tworzenia jednolitej wersji systemu ERP dla wszystkich klientów.
Dostawcy systemów ERP, aby zachować konkurencyjność, biorą pod uwagę, że po wdrożeniu systemu będzie on dostosowywany do indywidualnych wymagań każdego klienta. Konieczność dostosowywania systemu ERP wynika z realnych i zauważalnych niedoskonałości w funkcjonowaniu systemu informatycznego. Niektóre z tych niedoskonałości można rozwiązać poprzez reorganizację procesów biznesowych lub zmianę konfiguracji oprogramowania, podczas gdy inne wymagają dostosowania samego systemu. Warto zauważyć, że istnieją również takie braki rozwiązań systemowych, które mogą nigdy nie zostać całkowicie uzupełnione.
Wszystkie zmiany względem wyjściowego rozwiązania muszą być ponownie zwalidowane przy każdorazowym wdrożeniu pakietu oprogramowania. W niektórych przypadkach właśnie kompletna zmiana systemu jest najlepszym rozwiązaniem, aby w jak największym stopniu pozbyć się luk systemowych.
W rezultacie, jak łatwo się domyślić, dostosowania systemu ERP są procesem długotrwałym i kosztownym. Jest to inwestycja, która zwracać się będzie latami, dając w zamian możliwość zoptymalizowanego zarządzania zasobami przedsiębiorstwa.
Metody i narzędzia wspierające analizę migracji danych
Przejdźmy zatem do narzędzi, które często okazują się niezastąpione podczas projektu migracyjnego. Mogą one z pewnością ułatwić komunikację między zespołami, czy też zapewniać bezpieczne przechowywanie dokumentacji projektowej, zawierającej poufne dane.
Azure Devops jako narzędzie do komunikacji między zespołami
Azure DevOps to platforma oprogramowania typu Software as a Service (SaaS) oferowany przez firmę Microsoft, która za pomocą swoich narzędzi łączy developerów, analityków, kierowników projektów oraz innych członków zespołów developerskich w celu realizacji wdrożenia nowego oprogramowania, czy też innych rozwiązań dla ułatwienia komunikacji i przepływu zadań w projektach IT.
Jest to rozwiązanie na tyle elastyczne, że integruje się ze znaczną liczbą narzędzi popularnych na rynku, będąc optymalną alternatywą do kompilacji narzędzi typu DevOps. Dzięki intuicyjnemu interface’owi organizacje mogą wdrażać i ulepszać produkty efektywniej niż w przypadku standardowych metod tworzenia oprogramowania.
Dostęp do Azure DevOps można uzyskać za pośrednictwem przeglądarki internetowej lub klienta IDE.
Narzędzia Azure Devops
Do podstawowych narzędzi Azure Devops należą:
- Boards – jest to zestaw narzędzi wspomagających planowanie oraz śledzenie postępów wdrożeń za pomocą metodyk zwinnych typu Kanban oraz Scrum. W projektach związanych z migracją danych rozwiązanie ułatwia również komunikację pomiędzy poszczególnymi zespołami. Przeniesienie zadania do następnego etapu, czy też zespołu odbywa się poprzez zwykłe „drag and drop” za pomocą myszki. Ponadto, większość kluczowych aktywności związanych z projektem migracji danych będzie odbywać się na tak zwanych „Boardach”, co zostanie opisane w następnych częściach artykułu.
- Inne dostępne narzędzia warte wspomnienia to:
- Repos – daje dostęp do repozytoriów Git oraz kontroli wersji serwera Team Foundation (TFVC) w celu kontroli źródła kodu.
- Pipelines – jest to zestaw narzędzi do konfigurowania automatycznych procesów budowania i dostarczania aplikacji.
- Azure Test Plans – udostępnia zestaw narzędzi do testowania rozwiązań, w tym testowania eksploracyjnego i UAT (User Acceptance Test).
- Azure Artifacts – dzięki temu rozwiązaniu zespoły mają dostęp do pakietów, takich jak Maven, NuGet, NPM itp., nie tylko z publicznych, ale także z prywatnych źródeł.
Sharepoint
Aplikacja Sharepoint stanowi bezpieczne środowisko do gromadzenia, porządkowania i współdzielenia informacji, umożliwiające dostęp do nich z dowolnego urządzenia. Do korzystania z tej aplikacji wystarczy przeglądarka internetowa, jak np.: Microsoft Edge, Internet Explorer, Chrome czy Firefox.
Analiza procesu migracji danych
Proces migracji danych, który ma miejsce w opisywanym projekcie, został zdefiniowany jak przedstawiłem poniżej:
Zgodnie z powyższym diagramem, proces rozpoczyna się od ekstrakcji danych ze starego systemu bazodanowego. W tym przypadku jest nim SAP HR. Odbywać się to może w dwojaki sposób:
- Pierwszym sposobem jest manualna ekstrakcja danych, gdy dane pracowników lub ich część znajduje się w innych systemach niż SAP albo po stronie firm zewnętrznych, jak na przykład ma to miejsce z danymi payrollowymi. Gromadzenie danych odbywa się tu za pomocą wcześniej przygotowanych szablonów, które zawierają odpowiednie kolumny, wskazujące wymagane wartości, jakie powinny się w nich znaleźć. Innymi słowy, w tym podejściu tworzymy manualną listę pracowników wraz z informacjami o warunkach ich zatrudnienia.
- Drugim podejściem jest ekstrakcja zautomatyzowana. Przy tym podejściu również wypełnia się szablony, jednak wpisuje się w nie ogólne zasady i reguły opisujące tabele, z których mają być czerpane dane oraz ewentualny mapping danych, tłumacząc wartości z SAPa na język Workdaya.
Następnym krokiem jest przesłanie tak przygotowanych danych do zespołu developerskiego, który jest odpowiedzialny za przetestowanie reguł i mappingów dostarczonych za pomocą szablonów, czy też sprawdzenie poprawności danych manualnych. Jeżeli testy wypadły poprawnie – co z doświadczenia wiem, że zdarza się to bardzo rzadko 😊 – developerzy zaczynają upload danych do nowego systemu.
Przygotowanie szablonów
Pierwszym krokiem w kierunku zebrania wymagań z poszczególnych zespołów lokalnych jest przygotowanie szablonów, które zawierać będą wszystkie niezbędne informacje odnośnie tego, jakie dane, z jakich tabel powinny zostać przeniesione ze starej bazy danych do nowej.
Za narzędzie posłuży nam dość powszechny Excel, w którym każda wartość będzie miała odpowiednie pole. Dodatkowo, w zakładkach możliwe będzie dodanie ewentualnego mapowania, służącego do przetłumaczenia wartości z SAP-a na język Workday’a.
Wypełnianie szablonów jest etapem kluczowym, gdyż im lepsza będzie jakość dostarczonych danych i mappingu, tym sprawniej i szybciej przebiegnie cała migracja. Ponadto, poprawne wypełnienie szablonu zmniejszy występowanie zbędnych bugów, czy też konieczności stworzenia Change Requestów, które mogą w znacznym stopniu wydłużyć proces migracji. Dodatkowo wszystkie szablony są składowane w odpowiednich folderach na Sharepoincie, co umożliwia łatwy dostęp do całej dokumentacji projektowej, a także pracę kilku osób na tym samym pliku jednocześnie.
Przygotowania do migracji
Kluczowym elementem analizy biznesowej w projekcie związanym migracją danych, jak i w innych tego typu projektach, jest bliski kontakt z biznesem, czyli z pracownikami działów, które w swoje codziennej pracy wykorzystują właśnie dane pracownicze w celu administrowania nimi lub wypłaty wynagrodzeń.
Zespół takiego działu powinien więc składać się z osób, które mają doświadczenie w pracy ze starym systemem ERP po to, aby przy ewentualnych błędach móc je szybko i sprawnie rozwiązać. Osoby techniczne, które były zaangażowane we wdrożenie starego systemu, również ułatwią pracę i pozyskanie niezbędnych informacji.
Kick-off
W celu rozpoczęcia współpracy z interesariuszami po stronie biznesu, ustalany jest dzień rozpoczęcia całego przedsięwzięcia, w którym to na pierwszym spotkaniu, tj. kick-offie, omówione zostaną cele projektu, sposób jego realizacji oraz timeline. Warto nadmienić, że szczegółowe przygotowanie prezentacji, ale także szablonów, na których pracować będą członkowie zespołu znacząco ułatwi dalszą współpracę. Innymi słowy, im całe przedsięwzięcie i jego cel będą bardziej zrozumiałe dla pracowników działu HR, tym lepszej jakości dane otrzymamy.
Na tym etapie niezastąpionym narzędziem może okazać się Azure DevOps. Wykorzystując Board przypisany do danego interesariusza, możemy stworzyć taski dla poszczególnych szablonów, co ułatwi nam monitorowanie postępów w realizacji zadań oraz komunikację między uczestnikami procesu. Niemniej bardzo istotne jest, aby upewnić się, że każdy z uczestników ma odpowiednio nadane dostępy. W przypadku ich braku, proces nadawania dostępów może zmarnować cenny czas, potrzebny na przygotowanie szablonów.
Przegląd i uzupełnianie szablonów
Wyobraźmy sobie, że jesteśmy już po kick-offie. Interesariusze wiedzą dlaczego, w jakim celu, jak i kiedy będzie realizowany projekt. Co dalej? Z reguły następnym krokiem jest dwu– lub trzytygodniowy przegląd i uzupełnienie szablonów o odpowiednie wartości. Jak tutaj wygląda praca analityka? Można powiedzieć, że co kraj to obyczaj. 😊
- Niektórzy interesariusze bardzo dużą wagę przykładają do bliskiej współpracy z analitykiem, który prowadzi ich przez cały proces i jest obecny przy wypełnianiu szablonów. Jest to metoda bardzo przyspieszająca cały proces, gdyż wtedy faza weryfikacji przez analityka odbywa się on the job. Przedstawiciele działu HR mogą zadawać pytania bezpośrednio, a analityk może kontrolować, czy zespół wpisuje odpowiednie wartości oraz tworzy poprawny mapping.
- Kolejną metodą, stosowaną przez niektórych uczestników procesu, jest praca samodzielna, co oznacza, że interesariusz konsultuje swoje postępy z analitykiem tylko na cotygodniowych spotkaniach, a my jako analitycy możemy w trakcie realizacji tylko dopytywać o postępy lub sprawdzać postęp prac na boardzie w AzureDevOps. Niemniej nie mamy bezpośredniej kontroli nad sposobem realizacji zadania, jak w pierwszym modelu współpracy.
Refinement team
Minęły dwa lub trzy tygodnie, interesariusz zdążył dostarczyć nam wypełnioną niezbędnymi wartościami dokumentację oraz mapping danych. Następnym krokiem, przy założeniu, że analityk wspierał interesariuszy w zbieraniu danych, jest przydzielenie zadań do Refinement teamu.
Jest to zespół developerów, którzy za pomocą testów wykonywanych na odpowiednich środowiskach sprawdzają, czy wartości otrzymane od uczestników procesu działają poprawnie. Aby dać sygnał Refinement teamowi, że może rozpocząć swoją pracę, wystarczy nadać taskom na boardzie w Azure DevOps odpowiedni status.
Po takiej analizie następują tzw. Refinement Sessions. Są to spotkania, organizowane przez analityka, na których przedstawiciele Refinement teamu mają możliwość przedstawienia wyników swoich testów bezpośrednio zespołowi HR. Całe spotkanie jest facylitowane przez analityka, który powinien pilnować, aby było spójne i efektywne. Ponadto, Refinement team może zostawiać swoje komentarze oraz pytania do poszczególnego szablonu również w taskach w Azure DevOps. Dzięki temu rozwiązaniu, wszyscy interesariusze mogą przygotować się do spotkania i przejrzeć ponownie rezultaty swojej pracy.
Upload wyeksportowanych danych
Gdy wszystkie niespójności zostaną wyjaśnione pomiędzy zespołami, dane są gotowe, aby przesłać je dalej do zespołu developerów, którzy zainicjują upload wyeksportowanych danych do Workday’a. W tym celu analityk jest zobligowany do stworzenia user story w Azure dla każdego szablonu, aby zebrać i podsumować wszystkie niezbędne informacje, potrzebne do poprawnego uploadu. Dodatkowo, podczas transferu danych, analityk wspiera zespół developerów w ewentualnie występujących defektach.
Jak łatwo zauważyć, rola analityka w tak dużym przedsięwzięciu jest bardzo szeroka i towarzyszy wielu zespołom zaangażowanym w projekt właściwie na każdym etapie – od kick-offu aż do końcowego uploadu danych.
Podsumowanie
Migracja danych, a tym samym Analiza Biznesowa w migracji danych, jest procesem mocno złożonym i podatnym na ewentualne błędy, występujące podczas wdrożenia. Dlatego też wprowadzenie analityka do projektu jest etapem czasochłonnym, gdyż musi on zapoznać się ze sposobem pozyskiwania danych, w tym z szablonami, z komunikacją między zespołami (dział HR, Developerzy oraz z własnym zespołem), czy też zrozumieć, jakie dane są wymagane dla poszczególnych zespołów.
Z pewnością znajomość systemów ERP, między którymi przebiega migracja, znacząco ułatwi pracę nad przygotowaniem danych oraz adresowaniem wątpliwości zespołu HR. Niemniej jednak ilość wiedzy, jaką analityk musi przyswoić w globalnym projekcie sprawi, że potrzeba będzie czasu aby sprawnie i bezbłędnie pozyskiwać oraz analizować powierzone zasoby bazodanowe.
Z pewnością będzie to dla niego satysfakcjonujące oraz ciekawe doświadczenie, gdyż środowisko, w jakim będzie działać jest bardzo dynamiczne oraz zróżnicowane, a wdrożony z sukcesem system ERP będzie ciekawą pozycją w jego doświadczeniu jako specjalisty.
Dodatkowo, dzięki narzędziom przedstawionym w powyższym artykule, migracja może przebiegać sprawniej i bardziej wydajnie, redukując przy tym błędy i nieporozumienia, które mogą wystąpić podczas współpracy miedzy zespołowej.
Bibliografia
- Azure Microsoft
- SharePoint Microsoft
- Tomasz WASIELEWSKI, Robert KAMIŃSKI, Ireneusz J. JÓŹWIAK, Analiza koncepcji zmian w Systemach informatycznych klasy ERP, Zeszyty Naukowe Politechniki Śląskiej, Seria: Organizacja i Zarządzanie, z. 113.
***
Jeśli interesuje Cię rola analityka lub inne stanowisko w IT, zobacz koniecznie artykuły dotyczące ścieżek karier przygotowane przez naszych specjalistów.
Zostaw komentarz