Data Analyst, Business Analyst i BI Developer: co robią w projekcie

Data Analyst, Business Analyst, BI Developer. Otwierasz trzy ogłoszenia, a w każdym SQL, kontakt z biznesem i raportowanie. Potem trafiasz na czwarte, gdzie analityk biznesowy prawie nie dotyka danych, za to opisuje procesy i wymagania systemu. Łatwo dojść do wniosku, że nazwy stanowisk niewiele znaczą. Ja traktowałbym je jako wskazówkę do zadawania pytań, a nie gotowy opis przyszłego tygodnia pracy.

Sam zaczynałem jako analityk biznesowy i sporo pracowałem w SQL-u oraz Excelu. Część bardziej biznesowych obowiązków brał na siebie doświadczony kolega. Ten przykład pokazuje, jak konkretna organizacja dzieli pracę. Nie wynika z niego, że każdy Business Analyst powinien wykonywać taki sam zestaw zadań albo że trzy role są zawsze zamienne.

Pokażę różnice na jednym fikcyjnym projekcie: sklep chce lepiej obsługiwać zamówienia, które długo czekają na wysyłkę. Przejdziemy od niejasnej prośby do analizy, raportu i późniejszego utrzymania. Wszystkie przykłady organizacyjne i liczby są syntetyczne. Celem jest ocena odpowiedzialności, a nie stworzenie kolejnej sztywnej hierarchii zawodów.

Zacznij od rezultatu, za który odpowiada dana osoba

Najbardziej użyteczne rozróżnienie brzmi dla mnie tak: analityk biznesowy pomaga ustalić potrzebę i warunki zmiany, analityk danych bada problem na podstawie danych, a BI Developer buduje rozwiązanie raportowe, z którego można korzystać wielokrotnie. W rzeczywistym zespole jedna osoba może wykonywać części wszystkich trzech prac. Nadal warto wiedzieć, kiedy zmienia rodzaj odpowiedzialności.

Brytyjski opis roli Business Analyst obejmuje między innymi analizę problemu, potrzeb użytkowników, procesów i skutków zmiany. Z kolei opis Data Analyst wskazuje przygotowanie, analizowanie i komunikowanie danych. To jeden model kompetencji, przydatny do porównania. Nie narzuca definicji wszystkim firmom ani nie rozstrzyga zakresu konkretnego ogłoszenia.

Przy ocenie oferty zapisałbym więc trzy rzeczy: co mam dostarczyć, kto tego używa i po czym poznamy, że działa. Jeżeli odpowiedzią jest wyłącznie lista narzędzi, obraz stanowiska pozostaje niepełny. Dwie osoby korzystające codziennie z SQL-a mogą pracować nad zupełnie innymi rezultatami. Jedna sprawdza hipotezę, druga utrzymuje wspólny model raportowy, trzecia weryfikuje wymaganie systemowe.

Przykład: zamówienia czekają na wysyłkę

Kierowniczka operacyjna mówi: „Potrzebuję dashboardu opóźnień”. Łatwo od razu otworzyć Power BI. Ja najpierw zapytałbym, co zrobi po zobaczeniu raportu. Czy ma przesunąć ludzi między zadaniami, skontaktować się z magazynem, czy poinformować klientów? Jeżeli nie ustalimy decyzji, możemy zbudować atrakcyjny ekran, który jedynie potwierdza, że sytuacja jest nieprzyjemna.

W naszym scenariuszu kierowniczka chce codziennie wskazać zamówienia wymagające interwencji. To wymaga aktualnej kolejki, właściciela działania i reguły priorytetu. Osobno chce wiedzieć, czy proces poprawił się w ostatnim miesiącu. Tu potrzebujemy danych historycznych i porównywalnych miar. Jeden widok może nie obsłużyć dobrze obu potrzeb, mimo że obie dotyczą „opóźnień”.

Zamówienie może mieć kilka pozycji, pozycje mogą wyjść w różnych paczkach, a zapłata może przyjść później niż złożenie zamówienia. Samo odejmowanie dwóch dat nie rozwiązuje problemu. Trzeba wybrać jednostkę obserwacji oraz moment rozpoczęcia i zakończenia pomiaru. Te ustalenia będą potrzebne każdej roli, choć każda użyje ich w innym celu.

Business Analyst ustala, co ma się zmienić

Analityk biznesowy może zacząć od odtworzenia procesu. Kto przyjmuje zamówienie? Co blokuje przekazanie do magazynu? Kto podejmuje decyzję o częściowej wysyłce? Jak wygląda wyjątek, gdy produktu brakuje? Wynikiem rozmów powinna być wspólna wiedza o problemie oraz możliwych działaniach. Samo spisanie życzenia „raport ma być szybki i intuicyjny” niewiele jeszcze pomaga zespołowi.

W naszym przykładzie użyteczny rezultat to krótki opis dwóch potrzeb: codziennej listy interwencji i miesięcznej oceny procesu. Do każdej dopisujemy użytkownika, częstotliwość użycia, potrzebne informacje oraz zasady akceptacji. Dla listy operacyjnej ważny będzie identyfikator zamówienia, przyczyna oczekiwania i odpowiedzialny zespół. Dla oceny procesu ważna będzie definicja populacji i porównywalność okresów.

Analityk biznesowy pomaga również rozstrzygnąć konflikt. Magazyn może chcieć liczyć czas od otrzymania dyspozycji, a obsługa klienta od potwierdzenia płatności. Oba pomiary mogą mieć sens, lecz opisują inne odcinki procesu. Rozwiązaniem może być pokazanie ich osobno. Próba wymuszenia jednego wskaźnika bez wyjaśnienia odpowiedzialności zwykle przenosi spór na późniejsze spotkanie przy gotowym raporcie.

Ta praca może obejmować SQL i samodzielną analizę danych. Może też dotyczyć wdrożenia systemu, wymagań funkcjonalnych lub zmian procesu, przy niewielkim udziale raportowania. Dlatego nie zakładałbym, że Business Analyst to automatycznie łatwiejsza, nietechniczna wersja analityka danych. Zapytaj, jaki rodzaj analizy jest w danym zespole najważniejszy i jakie dokumenty lub decyzje rzeczywiście powstają.

Data Analyst sprawdza, co wynika z danych

Analityk danych może teraz zbadać skalę oczekiwania. Najpierw ustala, które rekordy są zamówieniami, a które zdarzeniami lub pozycjami. Sprawdza braki dat, wielokrotne wpisy i zamówienia nadal otwarte. Potem oblicza miary oraz porównuje grupy. W tym zadaniu sama umiejętność napisania zapytania jest potrzebna, ale jeszcze nie wystarcza do uzasadnienia wniosku.

Załóżmy, że spośród 100 zakończonych zamówień 20 przekroczyło uzgodniony czas obsługi. Udział wynosi 20%. Obok mamy 15 nadal otwartych zamówień. Nie dopisywałbym ich automatycznie do zakończonych ani nie uznawał za terminowe tylko dlatego, że brakuje daty wysyłki. Dla kolejki operacyjnej są istotne, lecz porównanie historycznej terminowości wymaga osobnej reguły ich traktowania.

Dobry wynik analizy wyjaśnia również ograniczenia. Wzrost czasu oczekiwania może współwystępować ze zmianą udziału produktów wymagających kompletacji. Nie dowodzi to jeszcze, że pracownicy działają wolniej. Analityk porównuje podobne grupy, sprawdza jakość danych i formułuje kolejne pytanie. Jeżeli potrzebna jest ocena przyczyny, trzeba zaprojektować dodatkową analizę, a czasem zmianę sposobu zbierania informacji.

Rezultatem może być krótka notatka z tabelą, rekomendacją dalszego sprawdzenia i kodem pozwalającym odtworzyć liczby. Nie każdy projekt musi kończyć się dashboardem. Jeśli decyzja jest jednorazowa, dobrze udokumentowana analiza może być właściwym produktem. O sposobie prezentacji więcej piszę w tekście o dashboardzie analityka.

BI Developer buduje raport, który będzie działał jutro

Kiedy potrzeba wraca codziennie, pojawia się temat rozwiązania do wielokrotnego użycia. BI Developer projektuje model danych, miary, interakcje i sposób odświeżania. Sprawdza, czy różne strony raportu korzystają z tych samych definicji. Dba też o to, żeby odbiorca potrafił odróżnić brak danych od rzeczywistego zera. Kolory wykresów są tylko częścią tej pracy.

W naszym przykładzie trzeba zdecydować, jak połączyć zamówienia, pozycje i zdarzenia wysyłki. Jeżeli kwotę zamówienia powielimy na każdym zdarzeniu, suma może urosnąć bez żadnej dodatkowej sprzedaży. Dokumentacja Microsoftu dotycząca schematu gwiazdy w Power BI wyjaśnia rolę tabel faktów, wymiarów i poziomu szczegółowości. To dobry punkt wyjścia do modelowania, a nie gotowy projekt dla każdego zbioru.

Rozwiązanie wymaga także informacji o świeżości. Jeśli ostatnie odświeżenie zakończyło się wczoraj, lista „dzisiejszych” interwencji może być bezużyteczna. Kto zauważy awarię? Kto sprawdzi zmianę w źródle? Jak odbiorca zobaczy, że dane są nieaktualne? Te pytania warto zadać przed wdrożeniem. Raport pozostawiony bez opiekuna potrafi działać technicznie i jednocześnie przestać pomagać.

Nie zakładaj, że BI Developer pracuje bez kontaktu z ludźmi. Trzeba wyjaśnić zachowanie filtrów, pokazać znaczenie miary i uzgodnić kompromis między szczegółowością a czytelnością. Osoba budująca rozwiązanie potrzebuje rozumieć sposób jego użycia. Inaczej łatwo dostarczyć poprawne obliczenia w interfejsie, który prowadzi do niewłaściwej interpretacji.

Przekazanie pracy wymaga wspólnych ustaleń

Najwięcej problemów może pojawić się między etapami. Analityk biznesowy uzgodni „zamówienia gotowe do realizacji”, analityk danych użyje daty płatności, a BI Developer nazwie wynik „czasem dostawy”. Każdy wykona sensowną lokalnie pracę, ale gotowy raport będzie opowiadał o czymś innym niż zamówiona analiza. Wspólne słownictwo ogranicza takie rozjazdy.

Przy przekazaniu zapisałbym definicję miary, jednostkę obserwacji, źródło danych, reguły wyjątków i kilka przypadków kontrolnych. Na przykład zamówienie z dwiema paczkami, anulowanie po płatności oraz brak zdarzenia końcowego. Opis powinien pozwalać sprawdzić interpretację bez udziału osoby, która pamięta wszystkie rozmowy. Dokumentacja ma pomagać w decyzji i kontroli, więc lepiej użyć kilku konkretnych przypadków niż wielkiej listy ogólników.

W małym zespole sam możesz przejść przez wszystkie role. Wtedy nadal warto oddzielić ustalanie potrzeby, badanie danych i budowanie rozwiązania. Zapisz moment zmiany założenia i sprawdź jego wpływ na pozostałe części. To pomaga uniknąć sytuacji, w której poprawiasz formułę, lecz zostawiasz stary opis na stronie raportu i starsze kryteria odbioru w notatce projektu.

Jak czytać ogłoszenie poza listą technologii

Podkreśl czasowniki w obowiązkach. „Uzgadniać wymagania”, „badać przyczyny”, „budować model”, „utrzymywać raporty” i „prowadzić testy akceptacyjne” wskazują różne rodzaje pracy. Następnie dopisz oczekiwany rezultat do każdego z nich. Jeśli opis miesza wszystko, zapytaj, które zadania zajmują najwięcej czasu oraz co nowa osoba zrobi w pierwszych tygodniach.

Poproś o przykład ostatniego projektu zespołu. Kto sformułował problem? Kto miał dostęp do danych? Kto sprawdził wyniki? Kto zajmuje się rozwiązaniem po wdrożeniu? Odpowiedzi pokażą podział obowiązków dokładniej niż deklarowane proporcje spotkań i kodowania. Proporcje mogą zmieniać się między etapami projektu, więc jedna liczba nie opisze całego stanowiska.

Warto zapytać także o granice odpowiedzialności. Czy masz gotowe źródło danych, czy oczekuje się budowania całego przepływu? Czy jest osoba prowadząca review? Kto podejmuje decyzje o priorytetach? Szeroki zakres może być ciekawą okazją do nauki, ale wymaga czasu i wsparcia. Lista trzech zawodów w jednym ogłoszeniu nie tworzy automatycznie trzech dodatkowych dni w tygodniu.

Trzy zadania próbne na jednym problemie

Przy rozmowie o ofercie sprawdziłbym jeszcze, jak zespół ocenia zakończenie zadania. W analizie biznesowej może chodzić o uzgodnienie potrzeby i sprawdzenie kryteriów odbioru. W analizie danych o wiarygodną odpowiedź z opisanymi ograniczeniami. W BI o poprawne działanie rozwiązania także po zmianie danych. Jeśli oczekiwania są inne niż sposób oceniania pracy, łatwo poświęcić czas niewłaściwemu elementowi.

Wyobraź sobie ofertę obiecującą badanie zachowań klientów, w której wszystkie cele dotyczą liczby obsłużonych zgłoszeń raportowych. Taki zespół może potrzebować przede wszystkim utrzymania i szybkiego dostarczania zestawień. To użyteczna praca, ale jej rytm będzie inny niż w projekcie wymagającym kilku tygodni spokojnego badania hipotezy. Warto zauważyć tę różnicę przed przyjęciem stanowiska, a nie dopiero po pierwszym kwartale.

Sprawdź też, kto jest odbiorcą informacji zwrotnej. Czy użytkownicy zgłaszają uwagi bezpośrednio, przez właściciela produktu, czy przez kolejkę zadań? Czy masz możliwość obserwować użycie raportu? Dostęp do takiej informacji pomaga poprawiać rozwiązania. Bez niego nawet szeroki zakres technologii może oznaczać głównie wykonywanie poleceń bez zrozumienia, czy rezultat komuś pomógł.

Jeśli wybierasz kierunek nauki, przygotuj trzy małe rezultaty do naszego scenariusza. Najpierw opisz potrzebę kierowniczki, obecny proces i kryteria odbioru rozwiązania. Nie projektuj jeszcze pięciu stron dashboardu. Ustal, jaka decyzja ma być łatwiejsza i jaki wyjątek mógłby zmienić działanie użytkownika. To przybliży ci część pracy z wymaganiami.

Następnie przygotuj syntetyczną tabelę zamówień i zbadaj oczekiwanie na wysyłkę. Pokaż mianownik wskaźnika, rozdziel przypadki otwarte i zakończone oraz zapisz ograniczenia. Wystarczy niewielki zbiór, jeśli zawiera sensowne wyjątki. Zadbaj o możliwość odtworzenia obliczeń. To pozwoli ocenić, czy lubisz szukanie wyjaśnienia i sprawdzanie, czy wniosek rzeczywiście wynika z danych.

Na końcu zbuduj prosty raport, który po podmianie danych daje ten sam rodzaj odpowiedzi. Dodaj informację o aktualności i sprawdź zachowanie pustej grupy oraz brakującej daty. Poproś drugą osobę, żeby znalazła zamówienia wymagające uwagi bez twojej pomocy. Ocenisz wtedy zarówno działanie rozwiązania, jak i jego zrozumiałość. Wszystkie trzy części można później pokazać jako jeden projekt portfolio.

Czego uczyć się najpierw

Zacząłbym od wspólnego warsztatu: rozumienia tabel, podstaw SQL, jakości danych, definicji miar i klarownego opisywania wyników. Te umiejętności pozwalają rozmawiać z osobami wykonującymi sąsiednie zadania. Potem dobierz pogłębienie do wybranego rezultatu. Praca z wymaganiami potrzebuje innych ćwiczeń niż optymalizacja modelu raportowego, nawet jeśli obie korzystają z wiedzy o procesie.

Nie traktuj przejścia między rolami jako automatycznego awansu. Możesz rozwijać się w analizie biznesowej, analizie danych albo BI na kolejnych poziomach doświadczenia. Zmiana tytułu może oznaczać zmianę specjalizacji, a nie wyższy poziom odpowiedzialności. Porównuj samodzielność, trudność problemów i wpływ decyzji. Sam napis w profilu zawodowym nie wystarczy, żeby ocenić postęp.

Po trzech zadaniach próbnych zapisz, które fragmenty chciałeś dopracować najbardziej. Czy wracałeś do rozmowy o procesie, do wyjaśnienia rozbieżności, czy do działania modelu i raportu? Potraktuj to jako wskazówkę do następnego projektu. Decyzja o kierunku staje się łatwiejsza, kiedy opiera się na wykonanej pracy i informacji zwrotnej. Nie musisz od razu wybierać etykiety na resztę życia.

Jak pokazać taki projekt na rozmowie

Opisując rezultat, oddziel swój wkład od całego procesu. Możesz powiedzieć, że na syntetycznych danych przygotowałeś definicję miary, analizę wyjątków oraz raport z kontrolą świeżości. Pokaż jedno miejsce, w którym zmieniłeś pierwotne założenie. To daje rozmówcy okazję do sprawdzenia twojego rozumowania. Sam zrzut dashboardu pokazuje wygląd, ale niewiele mówi o jakości decyzji prowadzących do jego powstania.

Jeśli nie budowałeś rzeczywistego harmonogramu odświeżania, nazwij ten element planem. Jeśli testowała tylko jedna znajoma osoba, opisz dokładnie taki test. Uczciwe granice projektu pozwalają rozmawiać o dalszym rozwoju bez udawania wdrożenia w dużej firmie. Dobra demonstracja może być niewielka, o ile rozumiesz jej działanie i potrafisz odpowiedzieć na pytanie, co trzeba byłoby zmienić przy rzeczywistym użyciu.

Ja wybrałbym ofertę, w której zadania, wsparcie i kierunek rozwoju pasują do mojego etapu. Tytuł pomaga znaleźć ogłoszenie. Dopiero rozmowa o rezultatach pozwala ocenić pracę. W każdej z trzech ról warto umieć powiązać potrzebę odbiorcy z danymi i sprawdzonym rozwiązaniem, zachowując świadomość, za którą część odpowiadasz.

Film o trzech rolach w danych