Na każdym etapie budowy hurtowni danych konieczne jest zaangażowanie jej przyszłych użytkowników.

Według statystyk, częstym powodem niepowodzeń projektów informatycznych jest brak akceptacji systemu przez jego przyszłych użytkowników. Co o tym decyduje? Większość spotykanych na rynku rozwiązań technologicznych ma podobne funkcje. System może być łatwiejszy w obsłudze bądź stanowić ostatni krzyk informatycznej mody. Okazuje się, że niezależnie od tych cech akceptacja użytkowników zależy głównie od roli, jaką będą pełnili podczas tworzenia systemu. Szczególnie dotyczy to hurtowni danych, która jest tylko zestawem narzędzi, zaś sposób korzystania z niej zależy od inwencji i wiedzy użytkowników. Toteż oprócz ekspertów technicznych, w prawie wszystkich etapach tworzenia takiego systemu, muszą uczestniczyć pracownicy merytoryczni.

Projekt budowy hurtowni danych można podzielić na kilka etapów. Pierwszym z nich jest etap analizy kontekstowej, który określa cel i zakres projektu. Następny etap, którym jest analiza danych, definiuje strukturę i kontekst informacji pojawiających się w systemie. Jeżeli wiemy już, co chcemy osiągnąć, można przejść do następnej fazy, którą jest prototypowanie. W tej fazie powstają prototypy hurtowni. Każdy prototyp musi być zweryfikowany. Cykl budowy i weryfikacji prototypu powtarza się kilkakrotnie, aż wreszcie prototyp uzyskuje akceptację użytkowników. Pozwala to na przejście do kolejnej fazy, czyli wdrożenia systemu.

Na ogół wdrożenie hurtowni danych jest znacznie prostsze niż dla zintegrowanych pakietów.

Analiza kontekstowa

Celem tego etapu jest osiągnięcie wspólnego rozumienia zadań, jakie ma spełniać system, a zwłaszcza określenie rodzaju danych, które powinny być przechowywane w systemie i dostępne dla użytkownika. Zwykle analiza ta jest przeprowadzana na podstawie cyklu rozmów i warsztatów z kluczowymi użytkownikami. Największym problemem, jaki zwykle pojawia się podczas analizy kontekstowej, jest odmienne rozumienie tych samych pojęć przez różne osoby w firmie. Na przykład dyrektor sprzedaży pod nazwą marża będzie rozumiał różnicę między ceną a kosztami produkcji, natomiast dyrektor finansowy do kosztów produkcji doda jeszcze koszty transportu. Najprostszym rozwiązaniem jest w takim przypadku opracowanie słownika terminów, które będą używane w systemie. Słownik powinien definiować pojęcia w sposób zrozumiały dla wszystkich zainteresowanych - dlatego książkowe definicje nie zawsze właściwie będą oddawały ich znaczenie.

Czasem okazuje się, że cała firma zainteresowała się prowadzonym projektem i skromne środki nie wystarczą do zaspokojenia wszystkich potrzeb.

Analiza danych

Podczas analizy danych dopracowywane są szczegóły związane z wymiarami opisującymi wybrane informacje. Następnie dla każdego wymiaru określane są jego wartości. Poza tym mogą być zdefiniowane atrybuty opisujące poszczególne wartości i grupujące je hierarchie. Tak jak poprzednio, główną techniką w tej fazie projektu są rozmowy i praca w grupach roboczych. Warto zwrócić uwagę na fakt, że w obydwu tych fazach rola informatyków i konsultantów sprowadza się do słuchania i zapisywania w ustrukturalizowanej formie tego, co ustalają przyszli użytkownicy systemu. Zwykle dodatkowo informatycy występują w roli mediatorów i animatorów dyskusji. Taką rolę może też odgrywać w zespole projektowym osoba nie związana z informatyką, ale mająca niezależne spojrzenie na omawiane zagadnienia. Podczas analizy danych mogą być używane różne formy zapisu projektu systemu, ale żadna z nich nie gwarantuje, że wszystkie pomysły i potrzeby będą poprawnie przelane na papier. Ważne jest więc, aby etap analizy trwał stosunkowo krótko (np. dla projektów średnich rozmiarów dwa tygodnie intensywnych prac). Nie wszystko musi być od razu zdefiniowane, a szczegółowe dane można uzupełnić przy opracowywaniu i weryfikacji prototypów. Jedynym skutecznym sposobem upewnienia się czy wyniki analizy odpowiadają intencjom osób biorących w niej udział, jest jak najszybsze zbudowanie prototypu. W przypadku hurtowni danych jest to możliwe i należy z tej możliwości w pełni korzystać.

Jeżeli w pierwszej fazie projektu udało się rozwiązać wszystkie problemy, następuje okres stabilizacji. Jeżeli słownik wspólnych pojęć się sprawdził, warto go rozbudowywać o nazwy wymiarów i ich wartości, hierarchie i atrybuty. Warto tutaj uniknąć sytuacji, w której wiele osób będzie chciało dodać mały element do prowadzonego projektu. W efekcie projekt przerośnie znacznie zakładane na wstępie rozmiary, a tym samym budżet. Aby takich sytuacji uniknąć, pod koniec analizy kontekstowej należy określić ostateczny zakres projektu (najlepiej z pisemną akceptacją) i nowe prośby dodawać do listy wymagań dla następnej wersji.