W czasach rosnącej wartości informacji sprawne przetwarzanie danych jest fundamentem niezbędnym do efektywnego działania nowoczesnych przedsiębiorstw. W związku z dużą różnorodnością i zmiennością źródeł danych rosną potrzeby w obszarze utrzymania hurtowni danych oraz środowisk Big Data.

Wraz ze wzrostem wykorzystania repozytoriów danych przez wiele różnych działów biznesowych rośnie także nakład pracy na utrzymanie tych środowisk. Dojrzałe infrastruktury danych nie skupiają się już tylko na przetwarzaniu i dostarczaniu statycznych danych, ale także na wdrożeniu i czynnym wykorzystaniu mechanizmów jakości danych, procedur i polityk Data Governance, wprowadzaniu i utrzymywaniu słowników pojęć biznesowych czy udostępnianiu wydajnych i elastycznych środowisk typu „sandbox” lub wyspecjalizowanych środowisk zaawansowanej analityki.

Ich różnorodność pociąga za sobą zwiększone zaangażowanie nie tylko działu IT, ale także działów biznesowych. Często role niezbędne do utrzymania takiego środowiska rozdzielone są właśnie pomiędzy działy IT i biznesowe, co w znacznym stopniu zwiększa koszt całego przedsięwzięcia. Ponadto atrakcyjność obecnych mechanizmów przetwarzania i przeprowadzania analiz powoduje, że działy biznesowe chętniej sięgają do coraz większych zakresów danych zarówno strukturalnych, jak i nietypowych składowanych także w środowiskach typu Data Lake.

Wszystkie te czynniki mają niemały wpływ na wydajność przetwarzania i dotrzymywanie zadanych SLA oraz na dostępność danych w godzinach biznesowych – zwłaszcza w momentach, w których pojawiają się problemy podczas przetwarzania. Zaangażowanie działów monitorujących takie procesy często wykracza poza standardowe godziny pracy. Przy obecnym apetycie działów biznesowych idealnie byłoby zaangażować działy IT na minimum 16 godzin w ciągu dnia, podczas których w godzinach nocnych obsługiwany jest monitoring i utrzymanie aktualnego przetwarzania danych, a w godzinach dziennych, biznesowych – obsługiwany jest aktualny rozwój oraz odbywa się adresowanie nowych potrzeb analizy i przetwarzania danych. W związku z tym firmy często angażują swoje działy IT na pracę co najmniej dwuzmianową, co często spotyka się z niechęcią specjalistów IT, gdzie dodatkowym problemem jest to, że najmniej atrakcyjna praca (z punktu widzenia wysoko wyspecjalizowanego IT) jest do wykonania w godzinach nocnych.

Właściwie zbudowany offshoring zadań utrzymaniowych w znacznym stopniu ogranicza negatywne skutki powyższych problemów. Wypracowany model działania (taki jak w Onwelo Offshore Support), pozwala odciążyć działy IT z powtarzalnych czynności wykonywanych poza godzinami pracy oraz dodatkowo zwiększa efektywność funkcjonowania przedsiębiorstwa np. poprzez przyspieszenie wdrażania i testowania rozwiązań.

Przed transformacją offshore

W wielu firmach posiadających środowiska przetwarzania danych dzienna (uproszczona) siatka procesów hurtowni danych lub środowisk Big Data wygląda następująco:

• 0:00 – zamykanie systemów źródłowych
• 0:00 – 1:00 – eksport plików zasilających z systemów źródłowych
• 1:00 – 5:00 – zasilanie środowiska przetwarzania danych
• 6:00 – 7:00 – odświeżanie i dystrybucja raportów

W idealnym przypadku obszary korzystające z raportów, analiz, dashboardów czy innych produktów dostarczanych przez narzędzia Business Intelligence mają dostęp do najświeższych informacji w trakcie godzin biznesowych, a specjaliści od przetwarzania danych w tym czasie zajmują się rozwojem nowych funkcjonalności lub ewentualnie optymalizacją istniejących.

Niestety obecnie niezbędne jest elastyczne dostosowywanie się biznesu do realiów rynkowych. To z kolei bardzo często prowadzi do zmian w systemach źródłowych lub procesach biznesowych, a wszelkie takie działania mogą powodować szereg różnych problemów – od tych związanych z późniejszą ekstrakcją i dalszym przetwarzaniem, aż do problemów dot. sprawnego funkcjonowania narzędzi analitycznych udostępnionych biznesowi.

Przykładowo, w przypadku wystąpienia błędu w nocy następuje awaria w zasilaniu, która może zatrzymać cały proces, w szczególności, gdy specjaliści środowiska przetwarzania danych pracują w standardowych godzinach biznesowych. Wówczas taki problem może się rozprzestrzenić na wiele różnych procesów.

Przykładowe dodatkowe aktywności w harmonogramie przetwarzania w przypadku wystąpienia problemu:

1. 2:00 – pojawił się błąd wstrzymujący dalsze przetwarzanie
2. 8:00 – błąd został podjęty przez dział IT
3. 9:00 – dział IT jest gotowy do wznowienia przetwarzania, błąd został znaleziony i przygotowano poprawkę
4. 13:00 – proces przetwarzania danych zakończył się sukcesem, udostępniono najnowsze dane obszarom biznesowym

Chciałbym tutaj zauważyć, że powyższy harmonogram dostarczenia danych w przypadku awarii może być wersją bardzo optymistyczną. Dalsze wydłużenie czasu oczekiwania na przetworzone dane może być spowodowane np. poprzez obciążanie środowiska przez aktywnych użytkowników. Dla nich są to standardowe godziny pracy, w których muszą się wywiązać ze swoich obowiązków (np. raportowych i analitycznych), nie mogąc sobie pozwolić na przestój do godzin popołudniowych.

Dodatkowo zwracam tutaj uwagę na fakt, że w przypadku awarii specjaliści IT muszą zostać oddelegowani do poprawienia błędu i dalszego jego monitorowania, co może spowodować opóźnienie w innych pracach – np. rozwoju środowiska o nowe funkcjonalności.

Innym przykładem, na który warto zwrócić uwagę, jest zderzenie harmonogramu dostarczania nowej funkcjonalności z dostępnością specjalistów.

Uproszczony proces dostarczania nowej funkcjonalności wygląda następująco:

1. Analiza i projektowanie rozwiązania
2. Development
3. Testy wewnętrzne
4. Testy biznesowe
5. Wdrożenie rozwiązania

Biorąc pod uwagę niewielkie zmiany, z których każda zajmuje ok. 1 dzień roboczy, dostarczenie takiego rozwiązania w idealnym przypadku będzie trwało 5 dni roboczych. Z powodu np. jakości danych lub złożoności procesów biznesowych, taki proces może ulec wydłużeniu – najczęściej jest to spowodowane tym, że w trakcie testów wewnętrznych lub testów biznesowych wykrywane są błędy, które wymuszają cofnięcie się do fazy developmentu lub nawet analizy i projektu rozwiązania.

W uproszczonym przypadku, w którym w trakcie testów wewnętrznych wykryto błędy i zwrócono rozwiązanie do developmentu, czas dostarczania wydłuży się o 2 dni robocze (w sumie więc 7 dni).

W bardziej skomplikowanym przypadku, w którym błędy zostały wykryte w trakcie testów biznesowych i wymaga się zmiany projektu rozwiązania, dostarczenie rozwiązania może się wydłużyć aż o 4 dni robocze (w sumie 9 dni).

Dobrze przygotowane rozwiązanie mogłoby w znacznym stopniu ograniczyć negatywne skutki powyższych problemów. Poniżej przedstawiam sposób przeprowadzenia wdrożenia wsparcia offshore.

Transformacja

Proces transformacji jest kluczowym etapem w przypadku wdrożenia zespołu offshore w środowisko przetwarzania danych. Dzięki odpowiednio przemyślanym działaniom sam proces można w znacznym stopniu skrócić i wyrównać. Proponowane metodyczne i modułowe podejście do takiego procesu ułatwia podjęcie decyzji dotyczącej zakresu wsparcia.

Moduły procesu transformacji:

• Moduł monitoringu i obsługi środowiska – II linia wsparcia
• Moduł rozwiązywania problemów – III linia wsparcia
• Moduł monitorowania jakości danych
• Moduł testów
• Moduł optymalizacji
• Moduł developmentu
• Moduł wdrażania rozwiązania

Bez względu na wybrane moduły wsparcia sam proces transformacji wygląda podobnie.

W pierwszym kroku – tranzycie wiedzy – specjaliści konsultują się z przedstawicielami firmy w celu ustalenia oczekiwań, potrzeb, sposobu działania oraz w celu zdobycia wiedzy niezbędnej do przyszłego adresowania potrzeb w ramach wybranego modułu.

W drugim kroku – transformacji – konsultanci przejmują odpowiedzialność za wybrane serwisy. Zalecane jest przejmowanie serwisów krok po kroku – tak, aby zminimalizować ryzyko niepowodzenia. W tym samym czasie stopniowo wygasa również zaangażowanie zasobów po stronie przedsiębiorstwa.

W trzecim kroku – operacyjnego wsparcia – konsultanci w całości odpowiadają za wybrane serwisy zgodnie z ustalonymi SLA, a zasoby po stronie przedsiębiorstwa mogą być już praktycznie w całości angażowane w inne aktywności.

Dodatkowo modułowe podejście do procesu transformacji pozwala już w pierwszym etapie zweryfikować (np. poprzez zlecenie samego monitoringu i obsługi środowiska) wartość dodaną zlecenia usługi. W przypadku powodzenia zakres działań może być poszerzony o wdrożenie dodatkowych rozwiązań.

Po transformacji offshore

Wracając do przykładów wspomnianych na początku, poniżej przedstawiam porównanie sytuacji przed wdrożeniem rozwiązań offshore i po ich wdrożeniu.

Przypadek opisujący wystąpienie błędu podczas przetwarzania:

Przypadek opisujący wdrożenie nowej funkcjonalności:

Potencjalne problemy i sposoby zarządzania nimi

Powyżej przedstawiłem przykładowe korzyści z zastosowania usługi offshore, uzyskiwane podczas częstych problemów związanych ze środowiskami przetwarzania danych. Doświadczenie specjalistów w prowadzeniu projektów zarówno utrzymaniowych, jak i rozwojowych takich środowisk pozwala na zaobserwowanie i uporządkowanie wielu problemów, których zaadresowanie jest niezbędnym elementem wypracowanego modelu.

Do przykładowych problemów zaliczyć można:

Dlaczego warto

Zarządzanie ryzykiem, wdrożenie zasad i podejścia dotyczącego zarządzania złożonymi sytuacjami – to tylko wybrane działania, gwarantujące uzyskanie biznesowych i technologicznych korzyści przez firmy współpracujące z zespołem offshore.

Dostępność lokalnych zasobów IT

Lokalne zasoby IT mogą zostać odciążone z nieatrakcyjnych aktywności związanych z testowaniem, monitorowaniem lub rozwiązywaniem błędów, skupiając się na rozwoju nowych funkcjonalności biznesowych.

Obniżenie kosztów utrzymania środowiska

Ideą zastosowania offshore w organizacjach jest najczęściej ograniczenie kosztów operacyjnych – w tym przypadku w szczególności kosztów związanych z utrzymaniem środowisk IT.

Naturalne godziny pracy

Poprzez zastosowanie usługi offshore i poprzez podział odpowiedzialności na dwa zespoły (utrzymanie – Polska, rozwój – USA) w optymalny sposób wykorzystywane są zasoby IT w trakcie godzin biznesowych. Ponadto minimalizowana jest potrzeba zaangażowania lokalnych specjalistów IT w godzinach nocnych.

Elastyczność i modułowość procesu transformacji

Zalecane jest przeprowadzenie procesu transformacji małymi krokami. W pierwszym kroku jest to uruchomienie II i ewentualnie III linii wsparcia w trybie offshore. W przypadku gdy obydwie usługi są wykonywane zgodnie z założoną jakością, możliwe jest uruchamianie dodatkowych usług (np. optymalizacji, testów).

Skrócenie wdrożenia nowych funkcjonalności oraz poprawienie dostępności danych

W poprzednich przypadkach pokazałem szczegółowo zysk (w czasie wdrożenia) osiągany poprzez zastosowanie modelu offshore w kontekście przykładowych problemów w środowiskach przetwarzania danych. Dzięki usłudze offshore dostępność danych jest większa, a proces wdrażania nowych funkcjonalności – krótszy.

Grzegorz Materna – architekt systemów IT, pasjonat hurtowni danych i środowisk Big Data z ponad trzynastoletnim doświadczeniem w projektowaniu architektury oraz zarządzaniu zespołami projektowymi. Wspiera klientów z szeregu sektorów na całym świecie, wykorzystując różne technologie (Oracle, MS SQL Teradata, IBM, Informatica) oraz realizując hurtownie danych w różnorodnych podejściach i metodykach (Data Vault, Kimball, Inmon, Data Lake).