Wymagające wymagania (wg. Kimball Lifecycle)
Wymagania biznesowe są kluczowym elementem projektu budowy hurtowni danych i systemów klasy Business Intelligence. Od tego, jak dokładnie zostaną zidentyfikowane, zrozumiane i spełnione, zależy sukces całego przedsięwzięcia. Niezwykle istotne jest więc profesjonalne podejście do procesu ich gromadzenia.
Spis Treści
- Kimball Lifecycle
- Potrzeba
- Kluczowa rola wymagań
- Zbieranie wymagań
- Podejście
- Wywiady i sesje
- Budowa zespołu
- Przygotowanie
- Dobór użytkowników
- Kwestionariusze
- Planowanie wywiadów
- Dobre praktyki
- Pytania
- Procesy biznesowe
- Przeszkody
- Podsumowanie
Kimball Lifecycle
Kimball Lifecycle (The Data Warehouse Lifecycle Toolkit) jest kompletną metodologią projektowania, budowy i wdrażania hurtowni danych oraz systemów Business Intelligence, opracowaną przez Ralpha Kimballa i jego Kimball Group. Szczegółowo opisuje ona każdy etap cyklu życia systemu klasy DW/BI2 i jest jedną z najpowszechniej stosowanych metodologii na świecie. Niniejszy artykuł przedstawia specyfikę etapu zbierania wymagań dla systemów analitycznych w oparciu o Kimball Lifecycle.
Potrzeba
Za każdą inicjatywą wdrożenia systemu klasy DW/BI stoi potrzeba, która musi zostać zaspokojona. Pochodną tej potrzeby są wymagania zbierane w procesie analizy. Zespół specjalistów wdrażających system opiera się głównie na dokumentacji tych wymagań, dlatego powinny one być klarowne, wysokiej jakości i precyzyjnie obrazować główny cel przyświecający projektowi. Pojedyncze wymagania i ich spełnienie nie są wartością samą w sobie, a jest nim dopiero dostarczenie produktu, który będzie zaspokajał powstałą potrzebę i zyska uznanie wśród użytkowników.
Kluczowa rola wymagań
Aby projekt mógł zakończyć się sukcesem, wymagania biznesowe powinny znajdować się w centrum zainteresowania. Każdy etap projektu, każda inicjatywa, a nawet każda pojedyncza decyzja powinna zostać podjęta ze szczególnym uwzględnieniem wymagań i zgodności z nimi. Wymagania powinny grać główną rolę w każdym aspekcie cyklu życia projektu, począwszy od ustalania zakresu, definiowania modelu danych oraz procesów transformacji danych źródłowych (ETL), wyboru sprzętu i oprogramowania, przygotowywania raportów i analiz na utrzymaniu i dostarczaniu wsparcia kończąc.
Zbieranie wymagań
Rola procesu zbierania wymagań od użytkowników biznesowych nie ogranicza się jedynie do jasnego i precyzyjnego sformalizowania celów i potrzeb dla jakich projekt został uruchomiony. Bardzo ważnym aspektem jest wymiar psychologiczny komunikacji z przyszłymi użytkownikami, czy sponsorami systemu. Olbrzymie znaczenie ma tutaj możliwość bezpośredniego kontaktu i pokazania użytkownikom, że system jest budowany dla nich, a przedstawiane przez nich postulaty są ważne i będą uwzględnione podczas budowy i wdrożenia systemu. Daje im to poczucie współtworzenia i współodpowiedzialności za projekt, co jest jednym z fundamentalnych czynników późniejszego pozytywnego przyjęcia systemu. Użytkownicy, którzy spotkają się z projektem na jego wczesnym etapie, będą lepiej rozumieli jego założenia i chętniej będą go używać, a właśnie powszechność użytkowania jest dla rozwiązań analitycznych głównym miernikiem sukcesu. Groźną pułapką może okazać się jednak zbytnie rozbudzenie oczekiwań dotyczących wdrożenia, co jest szczególnie niebezpieczne przy zaawansowanych systemach analitycznych typu DW/BI. Z tego względu coraz większą wagę przywiązuje się do tzw. zarządzania oczekiwaniami.
Podejście
Proces zbierania wymagań biznesowych powinien w głównej mierze koncentrować się na użytkownikach biznesowych. Z pozoru poprzednie zdanie wydaje się być tautologią, jednak niejednokrotnie wśród osób z działu IT pojawia się pokusa, aby wymagania biznesowe zebrać na podstawie modeli danych systemów źródłowych, wywiadów z administratorami, a także aktualnie używanych raportów i analiz. Komunikacja pomiędzy biznesem i IT od zawsze była procesem niezwykle trudnym. Do kanonu przeszły wzajemne oskarżenia typu „biznes nie wie, czego chce”, czy „IT nas nie wspiera”. Według raportów Gartnera, zrozumienie pomiędzy biznesem i IT będzie w najbliższej przyszłości jednym z ważniejszych czynników sukcesu w korporacjach. Mimo, że dla osób technicznych osoby biznesowe mogą wydawać się niezrozumiałe oraz mające wygórowane oczekiwania, to ich wymagania powinny być priorytetowe dla projektu. Należy je dokładnie zebrać i przeanalizować, nie tylko na poziomie danych, jakie mają być dostępne w hurtowni, ale także w perspektywie zrozumienia pracy, jaką wykonują użytkownicy biznesowi, sposobu podejmowania przez nich decyzji oraz tego, jak wyobrażają sobie efektywną pracę w przyszłości. Koncentracja na biznesie, nie wyklucza oczywiście gromadzenia informacji od działu IT. Konieczne jest zweryfikowanie zebranych wymagań z rzeczywistością i danymi dostępnymi w systemach źródłowych, w celu szybkiej identyfikacji rzeczy niemożliwych do zrealizowania i potencjalnych problemów.
Wywiady i sesje
Klasyczna inżynieria oprogramowania identyfikuje wiele różnych metod zbierania wymagań, od rozsyłania ankiet po wcielanie się analityków w role użytkowników. W przypadku systemów klasy DW/BI rekomendowane są dwie metody, zapewniające bezpośredni kontakt z użytkownikami. Pierwsza z nich to wywiady z pojedynczymi osobami, lub małymi grupami użytkowników. Łatwo jest takie spotkanie zorganizować, ponieważ nie ma potrzeby szukania terminu pasującego kilkunastu osobom. Bezpośredni wywiad wymusza większe zaangażowanie. Uczestnicy zmuszeni są do czynnego udziału w procesie zbierania wymagań i nie ma możliwości, aby ktoś nie został wysłuchany, a jego postulaty pominięte. Drugą metodą są dłuższe sesje gromadzące większą liczbę użytkowników. Prowadzi je jedna osoba, a dyskusja toczy się w formie burzy mózgów. Wymagają one poświęcenia większej ilości czasu przez poszczególnych użytkowników, jednak skracają sumaryczny czas procesu. Istnieje także trzecia możliwość, polegająca się na wcieleniu się analityka w rolę użytkownika, co pozwala dogłębnie zrozumieć jego model pracy i wymagania. Jest ona jednak niezwykle wymagająca dla obu stron, dlatego stosowana jest bardzo rzadko. Metodologia Kimball Lifecycle zaleca stosowanie połączonej metody wywiadów indywidualnych, pozwalających na zdobycie wiedzy o wymaganiach szczegółowych, oraz większych sesji, dających możliwość wspólnego uzgodnienia priorytetów i kolejnych kroków.
Budowa zespołu
Ważnym, a często zaniedbywanym etapem, jest budowa odpowiedniego zespołu odpowiedzialnego za przeprowadzanie wywiadów z użytkownikami. Najważniejszym jego członkiem jest osoba, która faktycznie prowadzić będzie wywiady. Powinien być to analityk biznesowy, który jest odpowiedzialny za cały proces zbierania wymagań i późniejsze jego przedstawienie w postaci dokumentu analizy i projektu technicznego. Osoba ta musi posiadać dogłębną wiedzę biznesową i techniczną oraz doskonałe umiejętności werbalne i komunikacyjne. Od trafnego doboru tej funkcji może zależeć sukces całej inicjatywy DW/BI. Aby analityk mógł skoncentrować się na prowadzeniu wywiadu, potrzebny jest członek zespołu odpowiedzialny za dokumentację spotkania. Używanie dyktafonów nie jest zalecane, ponieważ może powodować dyskomfort u rozmówców, a także niechęć do ujawniania nieformalnych, lecz ważnych informacji. Dodatkową rolą osoby robiącej notatki w czasie spotkania jest sygnalizowanie niejasności i nieporozumień, zadawanie pytań uzupełniających, a także monitorowanie, czy dyskusja nie zbacza z toru i czy wszystkie założenia zostały zrealizowane. Udziałem w spotkaniach mogą być zainteresowane także osoby, dla których ważna jest wiedza przekazywana przez poszczególnych użytkowników, takie jak: deweloperzy aplikacji analitycznych, osoby odpowiedzialne za definicje modelu danych, administratorzy baz danych, etc. Dodatkowo, jedna lub dwie takie osoby, mogą uczestniczyć w spotkaniach jako obserwatorzy.
Przygotowanie
Oczywiste jest, chociaż niestety czasem praktykowane, że spotkanie z użytkownikami biznesowymi i zadanie pytania „jakie są wasze wymagania?”, lub „jakie dane chcielibyście mieć w hurtowni?” nie przyniesie oczekiwanych rezultatów. Zespół powinien się gruntownie przygotować, zanim umówi pierwszą rozmowę z użytkownikiem biznesowym o jego wymaganiach. Bardzo dobrym punktem wyjścia jest zapoznanie się z ostatnim raportem rocznym przedsiębiorstwa. Zawiera on cenne informacje o inicjatywach strategicznych, strukturze organizacyjnej przedsiębiorstwa (hierarchia raportowania), dane operacyjne, a także informacje o branży oraz kluczowe wskaźniki finansowe. Interesujące z perspektywy inicjatywy DW/BI są również wszelkie dokumenty związane ze strategią, zarówno biznesową, jak i IT, takie jak wewnętrzne rozporządzenia zarządu, notatki ze spotkań, maile od zarządu i kierownictwa do pracowników, a także intranet. Warto poszukać informacji na stronie WWW przedsiębiorstwa oraz poprzez Internet, świadczących o tym, jak firma się prezentuje, jak postrzegana jest na zewnątrz przez partnerów i klientów, jacy są i czym się wyróżniają jej kluczowi konkurenci, oraz jak wygląda charakterystyka danej branży. Niezwykle ważnym elementem przygotowań jest zebranie wszelkich dostępnych informacji na temat inicjatyw DW/BI, jakie uprzednio były podejmowane w przedsiębiorstwie. Nie muszą być to jedynie próby stworzenia korporacyjnej hurtowni danych, ale także mniejsze, departamentalne inicjatywy budowania systemów analitycznych. Niezwykle bogate w ustrukturalizowane informacje na temat strategii przedsiębiorstwa są systemy zrównoważonej strategicznej karty wyników (ang. Balanced Scorecard, BSC), które mogą przyjmować różne formy, od arkuszy kalkulacyjnych po dedykowane systemy informatyczne. Należy ustalić osoby uprzednio zaangażowane w proprojekty analityczne, a także przeanalizować dostępną na ich temat dokumentację. Nie można jednak traktować etapu przygotowań, jako kluczowego momentu zbierania wymagań. Podstawowym elementem są spotkania z użytkownikami biznesowymi i do nich należy podchodzić z przekonaniem, że dadzą nam największą wiedzę na temat biznesu i jego wymagań.
Dobór użytkowników
Skoro wymagania grają kluczową rolę w projekcie, równie ważne jest to, od kogo będziemy je zbierać. Oczywiście nie ma możliwości ani sensu wysłuchania każdego w przedsiębiorstwie, dlatego należy dobrać odpowiednio reprezentatywną grupę użytkowników. Nie wystarczy jednak rzucić okiem na strukturę organizacyjną, wyciąć z niej części, których dotyczyć będzie projekt i dobrać po jednym użytkowniku z każdego poziomu. Równie ważna, a czasem nawet ważniejsza niż formalna, jest nieformalna organizacja przedsiębiorstwa. Warto ustalić najbardziej wpływowe osoby, kto jest przychylny nowym technologiom, a kto jest bardziej konserwatywny i może blokować rozwój inicjatywy DW/BI. Należy wziąć także pod uwagę aspekty polityczne i nie zaniedbać wywiadów z wpływowymi osobami, które mimo że nie wniosą nic wartościowego do wymagań, to mogłyby poczuć się urażone, gdyby nikt z nimi takiego wywiadu nie przeprowadził. Dobierając rozmówców w dziale IT, poza osobami odpowiedzialnymi za systemy źródłowe, które udzielą nam kluczowych informacji w kontekście dostępności danych, potrzebnych dla zaspokojenia potrzeb biznesu, należy również skonsultować się z managerami w celu poznania korporacyjnej strategii rozwoju IT.
Kwestionariusze
Bardzo pomocnym narzędziem podczas spotkań z użytkownikami są kwestionariusze wywiadów. Osoba prowadząca wywiady powinna mieć przygotowanych kilka rodzajów kwestionariuszy, w zależności od funkcji i profilu osoby, do której kierowane są pytania. Nie należy przygotowywać odrębnego zestawu pytań dla każdego użytkownika. Oczywiste jest jednak, że inne pytania zadawane będą osobom biznesowym, a inne członkom działu IT, jak również innego typu informacji oczekujemy od członka zarządu, a innego od osoby z tzw. linii frontu. Kwestionariusz powinien być przygotowany w sposób pozwalający płynnie przechodzić pomiędzy różnymi wątkami oraz utrzymywać spójną postać wywiadu. Nie należy go jednak traktować, jako sztywnego planu rozmowy, a jedynie jako pewien szkielet pozwalający na trzymanie wywiadu na właściwych torach. Aby nie rozpraszać uwagi użytkownika, ani osoby prowadzącej wywiad przeglądaniem i przekładaniem stosu papierów, kwestionariusz nie powinien zajmować więcej niż jedną stronę. Pomimo wykorzystywania gotowego zestawu pytań, niewykluczone, a wręcz wskazane jest zadawanie pytań uzupełniających, wynikających z toku rozmowy. Wraz ze zdobywaną wiedzą, podczas sesji z kolejnymi użytkownikami, kwestionariusze powinny być odpowiednio aktualizowane, w celu zwiększenia użyteczności uzyskiwanych informacji.
Planowanie wywiadów
Sprawne przeprowadzenie wszystkich potrzebnych rozmów z użytkownikami, w sposób maksymalizujący użyteczność zdobytych informacji, jest ogromnym wyzwaniem, nie tylko pod względem logistycznym i może sprawić wiele kłopotów. Dobrym punktem wyjścia jest rozpoczęcie od wywiadów z osobami odpowiedzialnymi za wizję projektu lub programu, czyli np. ze sponsorem biznesowym. Pozwoli to na lepsze zrozumienie idei i celów stawianych przed przedsięwzięciem. Dalsza kolejność wywiadów nie powinna przebiegać ani wg schematu bottom-up, ani top-down. Zbyt wcześnie przeprowadzane wywiady na poziomie operacyjnym mogą doprowadzić do zdezorientowania i zagubienia w morzu szczegółów. Z drugiej strony, aby móc kompetentnie rozmawiać z wyższą kadrą managerską, potrzebne jest dobre zrozumienie danego biznesu oraz jego specyfiki. Z powyższych względów najlepszym rozwiązaniem jest rozpoczęcie kolejnych wywiadów od kierowników średniego szczebla. Będąc na poziomie taktycznym piramidy zarządzania, mają oni bezpośredni kontakt z problemami operacyjnymi, równocześnie rozumiejąc strategię całego przedsiębiorstwa. Kolejną dobrą praktyką jest przeplatanie wywiadów z reprezentantami różnych części organizacji (finanse, sprzedaż, marketing, etc.) tak, aby w każdej kwestii poznać perspektywę wszystkich zainteresowanych stron oraz w razie niespójności, czy niejasności być w stanie je szybko wyjaśnić, bez organizowania dodatkowych sesji. Wracając do kwestii logistycznych; w miarę możliwości wywiady powinny być przeprowadzane w miejscu pracy użytkownika, aby zminimalizować problemy związane ze spóźnieniami, czy problemami z dotarciem na miejsce wywiadu. Dodatkowo, w znanym otoczeniu, użytkownicy czują się bardziej komfortowo. Bez względu na profil osoby, z którą przeprowadzany jest wywiad, należy na niego przeznaczyć około godziny, ponieważ mniej więcej przez tyle czasu będziemy w stanie utrzymać koncentrację użytkownika na odpowiednim poziomie. Na rozmowę z kierownikami wyższego szczebla pół godziny powinno wystarczyć, jednak ze względu na ich obciążenie obowiązkami służbowymi, przeważnie te drugie pół godziny poświęcone zostanie na skończenie poprzedniego zadania, czy wcześniejsze zakończenie spotkania ze względu na jakąś pilną sprawę. Z drugiej strony, pracownicy niższego szczebla są w stanie dostarczyć nam większą liczbę szczegółów, więc sesja z pewnością potrwa zaplanowaną godzinę. Pomiędzy sesjami powinny być zaplanowane około półgodzinne przerwy na chwilę odpoczynku, uzupełnienie notatek, czy przygotowanie się do kolejnego wywiadu. Warto, aby cały proces spotkań z użytkownikami został poprzedzony informacją (np. emailem) do wszystkich zainteresowanych od osoby wysoko postawionej w przedsiębiorstwie, który zwięźle opisze projekt, jego misję oraz wagę. Zwiększy to zrozumienie i poparcie dla danej inicjatywy, a także pozwoli zaoszczędzić sporo cennego czasu na spotkaniach, poświęcanego na przedstawianie projektu i jego celów.
Dobre praktyki
Podczas przeprowadzania wywiadów, każdy z członków zespołu powinien pamiętać o swojej roli, aby uniknąć późniejszych braków w zgromadzonych informacjach. Mogą się one pojawić np. w wyniku nie zadanych pytań, gdy prowadzący rozmowę zboczył niepotrzebnie z zaplanowanego toku wywiadu, czy braków w notatkach, ponieważ osoba odpowiedzialna za ich robienie zbytnio zaangażowała się w rozmowę. Przede wszystkim jednak należy być nastawionym na słuchanie i naukę. Zadawane pytania powinny być proste, jasne, zrozumiałe i prowokujące użytkowników do przekazywania jak największej ilości relewantnych informacji. Nie powinno się także rozmawiać z użytkownikami, mając przekonanie, że już wszystko się wie, co jest częstą pokusą, gdy po etapie przygotowań, analizie firmowych raportów oraz przeprowadzeniu kilku wywiadów, zespół zdobywa bogatą, lecz niepełną wiedzę o wymaganiach. Zgromadzone informacje należy traktować raczej jako narzędzie, dzięki któremu można z kolejnych użytkowników wydobyć nową, cenną wiedzę. W czasie przeprowadzania wywiadu, warto co pewien czas podsumowywać dotychczasowe ustalenia, a także upewniać się co do spójnego i właściwego ich rozumienia. Wszelkie niezrozumiałe kwestie powinno się natychmiast wyjaśniać z użytkownikami, aby nie dopuścić do sytuacji, kiedy po skończonym wywiadzie pozostają zagadnienia, których żaden z członków zespołu nie zrozumiał i każdy miał nadzieję, że ktoś inny będzie w stanie mu je wytłumaczyć. Bardzo ważnym elementem, którego nie można lekceważyć, jest słownictwo. Te same zagadnienia mogą mieć różne nazwy, w różnych departamentach w przedsiębiorstwie, jak również te same terminy, mogą znaczyć zupełnie różne rzeczy. Rozmawiając z użytkownikami, nie można zapomnieć także o wspomnianym już wcześniej zarządzaniu wymaganiami. Należy uświadamiać użytkowników, że w przeciwieństwie do tradycyjnych projektów, które przeważnie wykonywane są jednorazowo wg zadanej specyfikacji, wdrożenia systemów klasy DW/BI są w swej naturze iteracyjne i jeżeli ich wymagania nie zostaną uwzględnione na początku, nie oznacza to, że w ogóle nie zostaną wzięte pod uwagę.
Pytania
Jak już wcześniej wspomniano, dobór pytań do kwestionariuszy zależy głównie od pozycji w przedsiębiorstwie oraz organizacji, z której pochodzi użytkownik. Najsilniejszym czynnikiem wpływającym na tok i sposób rozmowy z użytkownikiem jest to, na jakim jest on szczeblu i jaki jest jego wpływ na projekt. Kwestionariusze można podzielić na dwie główne grupy. Jedne skierowane będą do osób odpowiedzialnych za wizję projektu, a ich celem jest zdobywanie informacji z perspektywy strategicznej. Drugie, na poziomie taktycznym i operacyjnym, skierowane będą na pozyskiwanie bardziej szczegółowej wiedzy od pracowników niższych szczebli. Kwestionariusze z pierwszej grupy będą z natury zawierały pytania bardziej ogólne, ponieważ ich celem jest zdobycie szerokiej wiedzy o organizacji, jej misji oraz potrzebach analitycznych. Powinny one dotyczyć celów przedsiębiorstwa oraz tego, do czego ono zmierza i co próbuje osiągnąć. Odpowiedzi użytkowników pozwolą poznać główne inicjatywy, jakie są podejmowane oraz tworzące je procesy biznesowe, które stanowią trzon całej organizacji. Należy się także dowiedzieć, jakie są główne czynniki sukcesu dla użytkowników oraz w jaki sposób i jak często są one mierzone. Informacje te są kluczowe dla środowiska analitycznego, ponieważ głównie te najważniejsze czynniki będą w nim przetwarzane, analizowane i prezentowane użytkownikom. Od ich dogłębnego zrozumienia zależy sukces całej inicjatywy DW/BI. Warto jest również zapytać się o problemy i wyzwania, przed jakimi staje przedsiębiorstwo. Ważne jest to, jaki mają one na nie wpływ, jak firma sobie z nimi radzi oraz jak wcześnie je identyfikuje. Z drugiej strony, dobrze jest również zdobyć wiedzę o tym, jak dane przedsiębiorstwo identyfikuje okazje, jakie przed nim się pojawiają, oraz to w jaki sposób zwiększony dostęp do analiz i informacji może polepszyć jego sytuację. Informacje te mogą okazać się niezwykle cenne dla wzmocnienia motywacji biznesowej dla projektu. Rozmawiając z użytkownikami wysokiego szczebla, jedną z ważniejszych rzeczy, które należy zrozumieć jest ich wizja lepszego wykorzystania informacji i szybkiego dostępu do niej. Ich oczekiwania wobec metod bezpośredniego korzystania z informacji przez pracowników pozwolą ocenić, czy mają oni wystarczającą siłę przebicia, aby zmienić sposób podejmowania decyzji w przedsiębiorstwie, z tego bazującego na intuicji, na taki, u podstaw którego leżą dane, informacje i wiedza. Kwestionariusze z grupy drugiej, skierowane są do kierowników niższego szczebla i zorientowane będą na bardziej szczegółowe potrzeby analityczne. Nie zmienia to jednak faktu, że na początku wywiadu należy zdobyć informacje analogiczne do tych, z kwestionariuszy strategicznych, tylko na poziomie komórki organizacyjnej danego użytkownika. Pytania bardziej szczegółowe powinny dotyczyć zagadnień, którymi użytkownik zajmuje się bezpośrednio. Użytkownik powinien opowiedzieć np. o swoich produktach (równie dobrze mogą być to usługi, klienci, dostawcy, partnerzy etc.), o tym w jaki sposób są rozróżniane (jakie mają unikalne cechy) i kategoryzowane, oraz jak często się zmieniają. Pozwoli to ustalić, w jaki sposób są one opisywane i będzie to podstawą do odpowiedniego zaprojektowania możliwości analitycznych systemu (operacje slice-and-dice wg przedstawionych charakterystyk). Należy także próbować zrozumieć zależności, jakie zachodzą pomiędzy atrybutami charakteryzowanych obiektów, jak np. maksymalna ilość klientów, których handlowiec może mieć przypisanych, czy ograniczenia na liczbę produktów, za które odpowiedzialny jest product manager. Kluczowym elementem wywiadów na tym poziomie są jednak informacje na temat wykorzystywanych raportów oraz analiz przeprowadzanych przez użytkowników. Ważne jest to, czego dotyczą te raporty i analizy, jakie dane są w nich wykorzystywane, skąd pochodzą te dane oraz to, co dzieje się z otrzymaną w wyniku informacją. Przeważnie w przedsiębiorstwach wiele raportów i analiz zawiera dane niekompletne, częściowo nieprzydatne, często użytkownicy przeprowadzają na nich dodatkowe operacje w arkuszach kalkulacyjnych. Należy zidentyfikować wszelkie słabości, nieścisłości i błędy w raportach i analizach oraz możliwości ich poprawy i usprawnienia. Nie wolno jednak zapominać o tym, że wymagania zbierane są dla nowej platformy analitycznej, której celem jest wniesienie nowej jakości do przedsiębiorstwa, a nie jedynie ułatwienie przygotowywania obecnie wykorzystywanych raportów. Warto zapytać użytkowników o analizy, które chcieliby móc przeprowadzać, a także o to, czy widzą możliwości usprawnienia obecnych procesów i metod. Ważna jest również wiedza o tym, jakie informacje są potrzebne użytkownikom ad hoc, do czego ich używają, komu je przekazują oraz jak dużo czasu pochłania ich zdobycie. Z perspektywy projektowania hurtowni danych, kluczowe są informacje o przydatności danych, o tym jak długo powinny być dostępne w systemie oraz jak szybko odświeżane, aby odzwierciedlać jak najbardziej aktualną sytuację. Ważne są także wszelkie wymagania związane z ochroną i bezpieczeństwem danych, jak również potrzeby związane z audytem. Wracając do samego użytkownika, warto zapytać go, o jego oczekiwania dotyczące zwiększonego dostępu do informacji i to jaki będzie miał on wpływ na wydajność pracy.
Procesy biznesowe
Budowa systemów klasy DW/BI jest procesem dynamicznym. Jeżeli po wdrożeniu pierwszego etapu, użytkownicy nie zgłaszają swoich uwag i potrzeb, najprawdopodobniej projekt poniósł klęskę i nie cieszy się uznaniem wśród osób z niego korzystających. Kolejne iteracje rozwoju systemu powinny być oparte o kolejne procesy biznesowe, które system ma wspierać. Podsumowując wymagania użytkowników należy koncentrować się przede wszystkim na identyfikacji kluczowych procesów biznesowych i według nich porządkować wymagania. Jako podstawowe czynności i zadania podejmowane przez biznes, procesy biznesowe są przez użytkowników wyrażane, jeżeli nie wprost, to poprzez czasowniki określające akcje i czynności. Najczęściej najważniejsze z procesów są wspierane przez operacyjne systemy transakcyjne. Jednym z ważniejszych elementów procesów biznesowych z perspektywy systemu DW/BI, są kluczowe wskaźniki wydajności (KPI), bezpośrednio, lub pośrednio odnoszące się do danego procesu. Właśnie one będą pierwszą informacją prezentowaną w systemie użytkownikom na kokpitach managerskich (Dashboards), dlatego projekt systemu powinien uwzględniać ich proste tworzenie i analizowanie.
Przeszkody
W procesie zbierania wymagań, nie zawsze mamy do czynienia z użytkownikami biznesowymi, którzy są w stanie chętnie i profesjonalnie przekazać nam swoje postulaty dotyczące systemu DW/BI. Poniżej scharakteryzowane są główne typy użytkowników, którzy mogą okazać się przeszkodą w skutecznym przeprowadzeniu procesu gromadzenia wymagań. Opisane są także metody postępowania z nimi.Osoby, które w przeszłości wielokrotnie przedstawiały swoje wymagania działowi IT i nie zobaczyły zadowalających efektów, mogą być niechętne kolejnym spotkaniom i poświęcaniu własnego, cennego czasu. Należy pro aktywnie zdefiniować listę użytkowników, którzy byli już zaangażowani w proces zbierania wymagań dla systemów analitycznych oraz zebrać wszystkie możliwe informacje i dokumentację na ten temat. Umawiając spotkanie należy zaznaczyć, że ma się wiedzę na temat uprzednio zebranych wymagań, a celem spotkania jest ich uaktualnienie. Wysocy rangą managerowie, którzy są często najważniejszą grupą przyszłych użytkowników systemu DW/BI, mają przeważnie bardzo napięte terminarze. Trudno jest im znaleźć wolny termin na spotkanie, a gdy już taki znajdą, niejednokrotnie spotkanie przekładają, nie zjawiają się na nim, lub przysyłają zastępstwo. Kluczowe jest tutaj zakomunikowanie przez silnego sponsora biznesowego, jak ważnym i istotnym projektem jest wdrożenie systemu. Jeżeli mimo to główni użytkownicy nadal będą mieli problemy ze znalezieniem czasu na zbieranie wymagań, można z dużą dozą prawdopodobieństwa przypuszczać, że nie znajdą go także na naukę użytkowania nowego systemu, a także wprowadzenie nowego typu raportów i analiz do swojej codziennej pracy. W takiej sytuacji lepiej jest wstrzymać lub zakończyć projekt, niż narażać się na jego niepowodzenie. Niektórzy użytkownicy mogą mieć problemy z komunikacją i przekazywaniem informacji na temat szerszego kontekstu swojej pracy, wymagań i oczekiwań względem systemu DW/BI. Na większość pytań odpowiadają zupełnie reaktywnie, dając krótkie, jednowyrazowe odpowiedzi. Problemem mogą być tutaj źle zadawane pytania, dlatego należy formułować je tak, aby prowokowały szerszą wypowiedź. Niejednokrotnie tego typu osobom łatwiej jest opisywać problemy jakie widzą w obecnej pracy, niż definiować nowe perspektywy. Jeżeli próby wydobycia cennych informacji kończą się fiaskiem, lepiej jest zrezygnować z wywiadu, lub znaleźć odpowiednie zastępstwo, jeżeli dana osoba jest na kluczowym stanowisku z perspektywy wdrożenia systemu.Podczas zbierania wymagań można natknąć się także na osoby nadmiernie gorliwe, które na umówione spotkanie przychodzą całą grupą, w której każdy jest entuzjastycznie nastawiony do wdrożenia systemu DW/BI i chętny, aby przekazać swoje uwagi i pomysły. Należy ustalić czy osoby te pełnią podobne, czy różne funkcje, a następnie podzielić je na odpowiednio mniejsze grupy i umówić odrębne spotkania. Innym przykładem użytkowników biznesowych, którzy mogą generować potencjalne problemy, są osoby uważające, że wiedzą wszystko, co jest niezbędne dla wdrażanego systemu analitycznego. Najczęściej ich funkcja znajduje się na styku biznesu i IT, dzięki czemu mają szersze spojrzenie na obecną sytuację. Często blokują także dostęp do innych osób, twierdząc, że są w stanie odpowiednio przekazać ich wymagania. Niejednokrotnie tacy użytkownicy rzeczywiście mają cenną wiedzę i należy efektywnie wykorzystać ich potencjał. Nie można jednak zaniedbywać możliwości kontaktu z innym użytkownikami, chociażby ze względu na wewnętrzną promocję systemu DW/BI i zdobywanie dla niego szerokiego poparcia.
Podsumowanie
Zbieranie wymagań dla systemów klasy DW/BI może z pozoru wydawać się jednym z łatwiejszych etapów jego cyklu życia. Ogromne znaczenie tychże wymagań oraz ich wpływ na cały projekt sprawia, że do procesu ich gromadzenia należy podejść z wielką dbałością i profesjonalizmem. Systemy DW/BI tworzone są dla użytkowników, aby mogli oni mieć lepszy i szybszy dostęp do informacji, której potrzebują. Sukces systemu zależy właśnie od ich akceptacji i tego, w jakim stopniu spełnione zostaną ich postulaty. Jeżeli nie poczują oni wartości dodanej, płynącej z korzystania z hurtowni danych i narzędzi Business Intelligence, to nawet najlepiej zaprojektowany system jest w takiej sytuacji skazany na porażkę i nie przyniesie zwrotu z inwestycji.
