Czy robić projekty BI w trybie Agile?

Data: 2015-05-25
Autor: Sebastian Konkol
Czy robić projekty BI w trybie Agile?

Odpowiedź w wersji „streszczenia dla kierownictwa”: oczywiście, że tak i daje się tak działać. W tradycyjnej typologii projektów IT, projekty BI (Business Intelligence) postrzegane są jako „ciężkie” – dużo analiz, dużo programowania, dużo infrastruktury, zanim zbudowana będzie „wartość biznesowa”, którą można się już pochwalić. Wszystkie te lematy są już bardzo wiekowe i – w dzisiejszych czasach – często nie są prawdziwe.

Środowisko realizacji współczesnych projektów BI jest trudne. Projekty takie są zwykle realizowane, kiedy sytuacja będzie już „nabrzmiała” – kiedy istnieje już gęsty i niespójny system gromadzenia, przeliczania i udostępniania danych, który realizuje stawiane przed nim cele, ale wymaga istotnej dozy pracy ręcznej. Skoro taki system dostarcza oczekiwane wyniki, często prezentowane kierownictwu lub zarządom firm, zastąpienie go rozwiązaniem klasy BI – w pełni – stawia poprzeczkę bardzo wysoko. Wiele systemów źródłowych, posiadających dane często „luźno” powiązane, uczestniczące w realizacji procesów biznesowych – analogicznie – co najwyżej „luźno” powiązanych. Osiągnięcie oczekiwanych wyników wymaga złożonych przeliczeń, często agregujących dane od poziomu danych operacyjnych do agregacji MIS. Rzecz jasna, semantyka danych źródłowych zmienną jest – biznes się zmienia i zmieniać się musi. Smaczku dodaje fakt, że dokumentacja systemów źródłowych – w najlepszym wypadku – jest nieaktualna.

Kluczowym zagadnieniem, jakie wprowadza zamieszanie, jest rozumienie „w pełni”. Nie oznacza ono bowiem ani „za jednym zamachem”, ani tym bardziej „wszystko”, ani nawet „tak samo, tylko automatycznie”. Paradoks? Ależ skąd, już wyjaśniam.

W mojej opinii podstawą zagadnienia jest – błędne – rozumienie wartości biznesowej, jaką dostarcza system klasy BI. Podczas uruchamiania niemalże każdego projektu BI składane są obietnice rodem z kampanii wyborczych, że „będzie to wszystko co jest, a nawet więcej, tylko w pełni zautomatyzowane”. W takim ujęciu, jeśli projekt BI dostarczy choćby odrobinę mniej, to jest totalną porażką. A to nieprawda. Wartość biznesowa, choć cząstkowa, pojawia się już w wyniku zintegrowania danych z dwóch systemów (np. klienci z CRM i ich kontrakty z systemu rozliczeniowego). Pod hasłem „zintegrowane” mam na myśli nie tylko techniczne powiązanie danych, ale uznanie tego, zintegrowanego źródła danych za oficjalne – razem ze zrozumieniem słabości integracji objawiających się mniejszą niż 100% jakością danych zintegrowanych. Skoro dotąd takie dane nie były zintegrowane, a raportowanie ich dotyczyło, to zapewne kilka osób musiało co jakiś czas (tydzień, miesiąc) dokonywać najróżniejszych operacji, aby te dane scalić i uzgodnić. Prawdopodobnie takie prace były wykonywane w kilku miejscach, bo przecież inaczej jest w sprzedaży, inaczej w marketingu, a jeszcze inaczej w finansach. Sedno sprawy – uznanie obowiązywania źródła zintegrowanego i akceptacja jakości integracji – niesie wartość biznesową, mierzalną, choć cząstkową.

Drugim elementem zamieszania wokół terminu „w pełni” jest – będący konsekwencją realizacji wszystkiego za jednym zamachem – duży zakres, a przez to długi czas realizacji projektu BI. Zanim uda się „dowieźć” ten zakres, tyle rzeczy się pozmienia, że pojawia się niemal gwarancja konieczności wprowadzania zmian do dopiero co dostarczonego (albo jeszcze niedostarczonego) systemu.

Tutaj także, jak to oceniam, kluczową rolę odgrywa budowanie wartości biznesowej w możliwie jak najmniejszych przyrostach. Źródło raz uznane za oficjalne będzie już takim, a wszyscy z niego korzystający będą dbali o to, żeby utrzymać jego jakość.

Projekt BI jest świetnym materiałem na realizację jego zakresu w małych przyrostach z częstym dostarczaniem mierzalnej wartości biznesowej. Jest przez to doskonałym kandydatem na projekt agile i uda się, o ile będą zachowane podstawy dla realizacji takiego projektu. Przede wszystkim system musi być potrzebny, czyli powinno dać się zmierzyć jego wartość biznesową. Zakres projektu powinien być tak długo dekomponowany, aż elementy wymagań będą realizowalne w ramach pojedynczego przyrostu. Każdy przyrost powinien dostarczać mierzalną wartość biznesową. Trwający przyrost powinien być chroniony przed „pomysłami na zmiany”. Realizacją projektu powinien zajmować się zdały zespół pracujący ze stałą szybkością. Nade wszystko jednak, realizacji projektu musi przyświecać praca zespołowa, włączając w to – przede wszystkim – potrzebujących danych.

W dzisiejszych warunkach budowanie rozwiązania BI jest działalnością „detektywistyczną”. Nikt nie wie, co „tkwi w danych”, dokąd ich nie prześwietli, a to właśnie prześwietlani danych (często nazywane analizą danych) jest najtrudniejszym, najbardziej praco- i czasochłonnym zadaniem w projekcie BI. Realizacja pracy „detektywistycznej” na danych powinna więc oznaczać eksperyment polegający na postawieniu roboczej tezy o znaczeniu danych, stworzeniu – być może – prototypu i weryfikacji jakości wyniku. Chcemy wszak zwiększać zrozumienie danych źródłowych, a przez to powiększać wiarygodność zintegrowanego źródła. Prowadzenie eksperymentów to esencja projektów agile.

Żeby nie było tak różowo, dekompozycja zakresu projektu na zadania mieszczące się w ramach jednego przyrostu jest trudnym zadaniem. Wymaga zdefiniowania wartości biznesowej, co zawsze wiąże się z wieloma przeszkodami. Równie trudne jest przyjęcie metod oceny wyników realizacji przyrostów projektu – akceptacja podejścia good enough wymaga wiele polityki, negocjacji i ewangelizacji. Ustanowienie metod oceny wyników eksperymentów jest zagadnieniem klasy good enough, choć w skali zespołu projektowego.

W kolejnych wpisach opowiem o dwóch praktykach ze świata agile – backlogu i TDD – przeniesionych na grunt projektów BI. Stay tuned!

Pozostaw komentarz