Analiza biznesowa – 7 grzechów głównych

Czym jest analiza biznesowa?

Według formalnej definicji IIBA (International Institute of Business Analysis) analiza biznesowa to „określanie potrzeb i rekomendowanie rozwiązań”. W takiej właśnie, a nie innej kolejności.

Wdrożenie rozwiązania dla biznesu to proces wymagający zaangażowania i kompetencji wielu specjalistów. Zarówno w przypadku mniej, jak i bardziej złożonych projektów, niezbędne jest zebranie wymagań, które pozwolą określić potrzeby klienta. Podobnie przy realizacji „projektów” w życiu codziennym – na przykład podczas budowy domu – zanim dokonamy kosztownej inwestycji, zastanawiamy się nad lokalizacją, bierzemy pod uwagę takie czynniki jak wykonanie projektu, koszt materiałów, zaangażowanie ekipy budowlanej. Analityk jest w projekcie informatycznym jak architekt w projekcie budowlanym.

W przypadku analizy biznesowej klienci często mają sprecyzowane wymagania, ale potrzebna jest osoba, która je spisze, zweryfikuje ich wykonalność (lub nie), a następnie przekaże zespołowi IT, który zajmie się przygotowaniem pod tym kątem produktu dla klienta. Tu wkracza analityk biznesowy, który jest pośrednikiem między światem biznesu a światem technologii.

Przeczytaj także:

• Podstawy UML- czyli modelowanie dla każdego
• Diagramy UML I BPMN – narzędzia pracy analityczki biznesowej i analityka biznesowego 

Analiza biznesowa a Business Intelligence

Częstym błędem jest mylenie analizy biznesowej z analityką biznesową (Business Intelligence). Mimo podobieństwa w nazwach są to odrębne dziedziny. Specjalista Business Intelligence skupia się na gromadzeniu, transformacji i wizualizacji danych w celu wspierania procesów podejmowania decyzji i podnoszeniu wydajności przedsiębiorstwa. Analityk biznesowy natomiast definiuje potrzeby i tworzy rozwiązania, które na nie odpowiadają. Praca analityka biznesowego jest nierozerwalnie związana z procesem zmiany, a jej zakres może wykraczać poza systemy informatyczne. Stworzony przez IIBA framework BABOK (ang. A guide to the Business Analysis Body of Knowledge) jako analityka biznesowego definiuje każdą osobę, która podejmuje działania z obszaru analizy biznesowej, bez względu na stanowisko lub pełnioną w organizacji funkcję.

Rola analityka biznesowego

Analityk biznesowy to osoba, która powinna mówić zarówno językiem klienta, jak i językiem IT. Dla wielu analityk to „pisarz dokumentacji”. Ale czy tak jest naprawdę? Sprowadzenie roli analityka do uczestnictwa w spotkaniach i spisywania wymagań niezbędnych do wypełnienia szablonu dokumentu to krzywdzące uproszczenie. W rzeczywistości to osoba, której zakres obowiązków wykracza poza identyfikowanie potrzeb interesariuszy i określanie wykonalność projektu, ale także posiada wiedzę, która pozwala podejść krytycznie do prezentowanych pomysłów, zrozumieć faktyczne potrzeby i aktywnie rekomendować optymalne rozwiązania.

Analiza przedwdrożeniowa pozwala wybrać najlepsze rozwiązania IT, zdefiniować cele biznesowe i wymagania umożliwiające skuteczne wdrożenie oprogramowania. Analityk dostarcza zespołom programistycznym istotnych informacji również w okresie trwania projektu pomaga w ocenie bieżącej sytuacji i podejmowaniu najważniejszych decyzji. Monitoruje biznesowe potrzeby klienta i jest z nim w stałym kontakcie.

W dzisiejszym szybko zmieniającym się świecie analityk często staje przed koniecznością współpracy zdalnej z klientem. Zazwyczaj „zdalnie” oznacza „szybciej i taniej”. Bez względu na sposób współpracy umiejętność pracy z klientem to podstawa w zawodzie analityka.

Czy można się obyć bez analityka biznesowego? Jestem z wykształcenia automatykiem i sądzę, że roboty szybko nas nie zastąpią. Zresztą badania wskazują, że automatyzacji łatwiej niż procesy analityczne poddają się prace programistyczne czy testerskie. Obserwowałem również projekty, w których rolę analityka powierzano project managerom lub deweloperom – niestety, efekty były dalekie od zadowalających.

Analiza przedwdrożeniowa fundamentem skutecznego systemu Business Intelligence

Dlaczego analiza przedwdrożeniowa jest ważna, kto i w jaki sposób powinien ją przeprowadzić?

Przeczytaj artykuł

Rola analityka a metodyka pracy

W coraz bardziej popularnych projektach zwinnych komunikacja odgrywa kluczową rolę. Precyzuje to Manifest Agile, który w swoim pierwszym punkcie wskazuje: „Ludzie i interakcje ponad procesy i narzędzia”. Tę zasadę można z powodzeniem odnieść do pracy analityka biznesowego, w pracy którego umiejętność słuchania i rozmowy z drugim człowiekiem jest niezbędna. Jeżeli ktoś nie ma rozwiniętych kompetencji komunikacyjnych, raczej nie powinien rozważać kariery analityka biznesowego.

W modelu waterfall (kaskadowym) analiza to etap drugi, bez którego niemożliwe jest przejście do kolejnych faz projektu. Spróbujmy sobie wyobrazić rozpoczynanie pracy od developmentu bez wcześniejszej analizy tego, co, dla jakiej grupy odbiorców i w jaki sposób będziemy wdrażać. Analiza jest tu kluczowa.

Bez względu na rodzaj przyjętej metodyki pracy analiza biznesowa wymaga:

• zadawania pytań,
• wyciągania wniosków,
• przetwarzania,
• analizowania,
• optymalizowania.

Błędy w analizie biznesowej

Po przybliżeniu tematyki związanej z celem analizy biznesowej i roli analityka biznesowego w całym procesie przejdźmy do 7 grzechów głównych w analizie biznesowej. Nie zawsze będą to błędy po stronie analityka, jednak zawsze powinien on trzymać rękę na pulsie. Co może pójść nie tak w trakcie analizy biznesowej?

1. Błędnie określona potrzeba biznesowa

Czym jest określanie potrzeby biznesowej? „Chcę osiągać wyższe dochody, ponieważ chcę kupić samochód droższy niż ten, który ma sąsiad”. Z czym to się kojarzy? Tak, to user story, popularna „historyjka”. Obecnie user story to najbardziej popularny sposób dokumentowania wymagań biznesowych. Dodatkowo ważne są tu kryteria akceptacji, np. „Moje średniomiesięczne dochody wzrosły o min 5%”. Kryteria akceptacji to lista konkretnych wymagań i warunków do spełnienia, aby Zespół Scrumowy wiedział, czy historyjka została poprawnie wykonana z biznesowego punktu widzenia.

Dobrze zdefiniowana potrzeba biznesowa i jej zrozumienie są najważniejsze – nie tylko z punktu widzenia analityka, ale także klienta. Czy to po stronie biznesu, czy analityka powinna pojawić się myśl: po co to robimy? Co nam to da? Zdarzają się niestety sytuacje, gdy przedstawiciel biznesu rekomenduje konkretne rozwiązanie, gdyż jest na przykład jedyną osobą, która zna daną aplikację. Czy robi to dla dobra firmy, czy może chce jedynie zachować swoje stanowisko pracy? To pierwszy i bardzo ciężki grzech w analizie biznesowej. Dobry analityk powinien zachować czujność w takich sytuacjach i odpowiednio zareagować.

2. Stosowanie nieoptymalnych rozwiązań biznesowych

Chyba każdy słyszał o długu technologicznym. Dług technologiczny powstaje, gdy w celu szybkiego zaspokojenia potrzeb biznesowych idziemy „na skróty” i sięgamy po nieoptymalne rozwiązania techniczne. Chodzi o rozwiązania utrudniające bądź wręcz uniemożliwiające realizację przyszłych celów firmy. Dług technologiczny narasta już od pracy wykonanej przez analityka biznesowego. Prowadzi to do sytuacji, gdy np. nowe inwestycje czy usprawnienia konkretnych procesów w organizacji są możliwe dopiero po nadrobieniu zaległości, czyli właśnie spłaceniu długu technicznego. A wydawałoby się, że to jedynie błędnie napisana „historyjka” w programie Jira. Jak temu przeciwdziałać? Okazuje się, że „na skróty” nie zawsze znaczy szybciej. Podobnie jak w życiu: czasem lepiej wybrać dłuższą, lecz sprawdzoną drogę, dzięki której nie będziemy musieli nadkładać kilometrów.

3. Przedstawianie gotowych rozwiązań

Kolejny częsty błąd leży po stronie analityka, który w ferworze zbierania wymagań biznesowych zaczyna przedstawiać gotowe rozwiązania, zamiast spisywać wymagania klienta. Prawidłowo proces powinien przebiegać w taki sposób, że analityk zbiera wymagania i konsultuje z biznesem. Często jednak na tym etapie pojawia się pokusa, by zaproponować gotowe rozwiązanie, na przykład konkretną aplikację o określonych parametrach i funkcjonalnościach, która zdaje się odpowiadać na zdefiniowane oczekiwania. Analityk jest tylko człowiekiem, a błądzić jest rzeczą ludzką. Przy zbieraniu wymagań warto jednak zachować krytycyzm i nie dać się ponieść fantazji.

4. Bezkrytyczne zbieranie wymagań

Zbieranie przypadkowych wymagań może przydarzyć się nie tylko osobom stawiającym pierwsze kroki w analizie biznesowej. To częsty błąd wynikający prawdopodobnie z chęci zebrania jak największej liczby wymagań. Nadgorliwość nie jest dobrą metodą. Podobnie jak bezkrytyczne zbieranie wymagań. Moim celem jako analityka jest zebranie istotnych wymagań. Istotnych, czyli mających uzasadnienie biznesowe i dających się zrealizować. Może być tak, że przedstawiciele biznesu zaproponują rozwiązanie bazujące na aplikacji sprzed 15 lat. Lubimy to, co znamy, ale czy będzie to rozwiązanie najlepsze dla klientów?

Stare przysłowie mówi, że papier wszystko przyjmie. Być może tak, ale stąd już tylko krok do błędnej „historyjki” w Jira. I tak wracamy do punktu 1. Nie patrzmy wyłącznie na wiążącą nas umowę – liczy się przede wszystkim zdrowy rozsądek. Jak wszędzie – dobrze jest dążyć do złotego środka. Zbyt mało wymagań może doprowadzić do niejasności. Jeśli z kolei wymagań będzie zbyt dużo lub będą zbyt precyzyjne, zespół projektowy będzie miał związane ręce. Developer ma rozumieć, nad czym ma pracować, a Product Owner – co zlecił do wykonania. Dobry analityk będzie wiedział, jaka ilość wymagań jest optymalna. Jeśli jednak nie wiesz, co robić, zapytaj o zdanie zarówno developera, jak i Product Ownera.

5. Niezrozumienie dziedziny

Jako analityk pracowałem przy wielu projektach dla klientów z różnych branż. Wiem, że zrozumienie dziedziny klienta wymaga czasu, ale warto być dociekliwym, zadawać pytania, niczym dziennikarz, który zbiera materiały. W trakcie rozmowy pada termin „urządzenie budowy przeciwwybuchowej”, a Ty nie wiesz, o co chodzi? Pytaj! Nie ma złych pytań, a bez wejścia w „buty klienta” możesz sobie nie poradzić. Jeśli nie mówisz jego językiem, nie przygotujesz diagramu dziedziny, zbierającego najważniejsze terminy z danego obszaru, które są istotne z punktu widzenia analityka. To podstawowe narzędzie UML – (z j. ang. Unified Modeling Language), czyli języka dokumentującego wymagania. Diagram dziedziny to model, który przedstawia najważniejsze pojęcia, znajdujące się w danym obszarze zainteresowania oraz zależności między nimi. Dzięki niemu analityk może uporządkować jako obiekty wszystkie terminy pojawiające się w rozmowach o działalności przyszłych użytkowników.

6. Brak konsultacji

Najczęściej jest tak, że w zespole jest jeden analityk zbierający wymagania. Nawet jeśli analityk ma bogate, wieloletnie doświadczenie projektowe, nie można wymagać od niego, by wiedział wszystko. Warto kierować się zasadą „Nie wiesz, co robić? Zapytaj innych o zdanie”. Zasada ta dotyczy oczywiście nie tylko analityków. Bez względu na doświadczenie, kompetencje czy rolę w zespole konsultowanie swoich pomysłów czy wątpliwości to dobra praktyka. Nie zrażaj się. Nawet jeśli trafisz na osobę, która Ci odmówi – większość pomoże.

Podobnie ważna jest tu szczerość. Nawet jeśli obawiasz się przyznać do swoich braków, chęć konsultacji i otwartość w zdobywaniu wiedzy zadziała na Twoją korzyść i z czasem pomoże Ci zbudować wizerunek osoby dociekliwej i kompetentnej.

7. Brak priorytetów

Każdy z nas codziennie staje przed koniecznością wyznaczania priorytetów. Pozwalają one organizować czas efektywnie. Z mojego doświadczenia wynika, że w przypadku analizy biznesowej 3 poziomy priorytetów są w zupełności wystarczające: priorytet wysoki, średni i niski. Wrzucanie wszystkiego do jednego worka pod nazwą „release” jest najczęściej skutkiem tego, że nie potrafimy zdecydować, co jest dla nas w danym momencie ważne. Efekt? Robimy wszystko i… nic z tego nie wychodzi. Może warto pomyśleć o projektach pilotażowych? Wprowadzanie wybranych funkcjonalności partiami, np. dla jednego oddziału firmy, pozwoli przetestować ich działanie na mniejszej grupie i wychwycić potencjalne zagrożenia przed wdrożeniem na szeroką skalę.

Podsumowanie

Analiza biznesowa to proces wymagający wkładu i wiedzy zarówno po stronie biznesu, jak i zespołu projektowego. Pośrednikiem pomiędzy tymi światami jest analityk biznesowy, który powinien mieć nie tylko umiejętność identyfikowania błędów po stronie klienta, ale także eliminowania własnych. Choć w powszechnym rozumieniu analityk pracuje z dokumentacją, warto pamiętać, że przede wszystkim pracuje on z ludźmi – dlatego tak ważne są kompetencje miękkie. Czy to w trakcie pisania dokumentacji, czy negocjowania warunków z klientem analityk musi więc przede wszystkim analizować. Praca odtwórcza, bez kreatywności, umiejętności uzupełniania brakującej wiedzy i syntetyzowania może doprowadzić do błędów, które opisałem w dzisiejszym artykule. Mam nadzieję, że pozwoli on zarówno przedstawicielom biznesu, jak i analitykom biznesowym zidentyfikować obszary wymagające poprawy i przekuć je w mocne strony w analizie biznesowej.