Metodyka projektowania systemów wspomagania podejmowania decyzji

Z projektem budowy systemu wspomagania decyzji zazwyczaj wiążą się bardzo wysokie oczekiwania i nadzieje na niemal natychmiastowe dostosowanie się do zmienionych warunków rynkowych lub organizacyjnych. Tymczasem tworzenie takiego systemu jest projektem ryzykownym i zwykle długotrwałym.

Z projektem budowy systemu wspomagania decyzji zazwyczaj wiążą się bardzo wysokie oczekiwania i nadzieje na niemal natychmiastowe dostosowanie się do zmienionych warunków rynkowych lub organizacyjnych. Tymczasem tworzenie takiego systemu jest projektem ryzykownym i zwykle długotrwałym.

Projekt, realizacja i wdrożenie Systemu Wspomagania Podejmowania Decyzji (DSS) i Hurtowni Danych (DW) są przedsięwzięciem złożonym. U podstaw każdego projektu DW leży idea zintegrowania posiadanych źródeł danych i stworzenia wiarygodnego źródła informacji zarządczej. System DSS ma natomiast zapewnić rozwiązanie problemów merytorycznych, usprawnić analizę danych biznesowych i spowodować szybkie podejmowanie słusznych decyzji. Niniejszy artykuł prezentuje metodykę realizowania takiego projektu zarówno od strony technicznej, jak i organizacyjnej oraz zawiera propozycję budowania systemów pilotażowych przed rozpoczęciem właściwego projektu. Proponowane rozwiązania są oparte na doświadczeniach własnych z realizacji systemów DSS/DW.

Metodyka budowy systemu DSS

Jedną z bardziej znanych i często stosowanych metod projektowania hurtowni danych i systemu DSS jest Business Dimensional Lifecycle. Metoda ta zakłada budowę oddzielnych, niezależnych hurtowni tematycznych i systemów dziedzinowych, zgodnie z pojawiającym się (planowanym) zapotrzebowaniem. Umożliwia to wszechstronną i efektywną analizę danych z poszczególnych dziedzin działalności przedsiębiorstwa (np. analiza budżetu) w oddzielnych, specjalizowanych systemach. Projekt powinien być realizowany w kolejnych iteracjach. Oznacza to, że tworzenie systemu DSS nigdy się nie zakończy, ponieważ metody oceny biznesu, struktury organizacyjne, czynniki opiniotwórcze itp. zmieniają się, co prowadzi do konieczności okresowej zmiany modelu logicznego, a w konsekwencji modelu fizycznego, nowej ekstrakcji danych itd. (patrz Diagram metodologii Business Dimensional Lifecycle).

Stworzenie niezależnych hurtowni tematycznych (zwykle zbudowanych przez różne zespoły w różnych działach przedsiębiorstwa i w różnym czasie) może prowadzić do otrzymywania niespójnego obrazu rzeczywistości. Raporty tworzone przez jeden system dziedzinowy mogą być nieporównywalne lub niezgodne z danymi opracowanymi przez inny system.

Powodem takiej sytuacji są z reguły różnice w definicjach pojęć i terminologii stosowanej we wspomnianych systemach. Ponadto może się pojawiać problem jakościowej niezgodności systemów (różnice w strukturach danych i wykorzystywanym oprogramowaniu) i wynikający stąd brak dostępu do informacji jednego systemu przez użytkowników systemu drugiego.

Poprawne rozwiązanie można otrzymać tylko wtedy, gdy tematyczne hurtownie danych budowane będą według ściśle określonych reguł zapewniających spójność zawartych w nich danych.

Budowę systemu rozpoczyna się od określenia reguł spójności pojęć oraz danych i uruchomienia jednej, zazwyczaj najbardziej pożądanej, hurtowni tematycznej. Wraz z pojawianiem się zapotrzebowania na analizę innych aspektów działania przedsiębiorstwa tworzy się, zgodnie z wspomnianymi regułami, kolejne minihurtownie tematyczne. W rezultacie otrzymujemy spójny system globalnej hurtowni pokrywającej potrzeby przedsiębiorstwa.

Istnienie określonych reguł, według których tworzone są hurtownie tematyczne, pozwala również na uzyskanie niezależności pracy zespołów tworzących systemy dziedzinowe.

Potrzeba rozpoznania celów

Powiększ

Podstawą systemu DSS w przedsiębiorstwie jest określenie wymagań biznesowych i związanych z tym wskaźników oceny efektywności gospodarowania. Trzeba przede wszystkim sprecyzować miary, za pomocą których będziemy oceniać przedsiębiorstwo (np. wielkość sprzedaży, koszt wytwarzania całkowity, koszt wytworzenia egzemplarza itp.), oraz metody oceny (wartość całkowita, wartość średnia, dynamika wartości itp.). Powinno się także wcześniej sformułować pytania, na które chcemy uzyskać odpowiedź, oraz określić, jakie zestawienia i raporty mogą być pomocne w uzyskaniu odpowiedzi (np. wartość sprzedaży w funkcji produktów, grup produktów, oddziałów firmy, w czasie, za podany okres itp.)

Dopiero po sporządzeniu szczegółowych wymagań można przystąpić do tworzenia modelu danych.

Brak jasno sprecyzowanego celu i nie zdefiniowane miary oceny biznesu należą do najczęstszych przyczyn niepowodzenia projektów DSS.

Model danych

Powiększ

Na etapie budowy modelu danych projektowanej hurtowni twórcy systemu muszą wykonać kilka zadań. To przede wszystkim budowa logicznego modelu biznesowego systemu, z którym będą mieli do czynienia użytkownicy aplikacji DSS, budowa modelu fizycznego efektywnie spełniającego założenia modelu biznesowego oraz utworzenie warstwy pośredniczącej między modelem biznesowym końcowego użytkownika a modelem fizycznym hurtowni danych - metadanych systemu DSS.

Do rozwiązania każdego z tych zagadnień projektanci używają zazwyczaj różnych narzędzi. O ile budowę abstrakcyjnego modelu biznesowego można przeprowadzić za pomocą prostego narzędzia graficznego czy też kartki papieru, o tyle implementacja fizyczna wymaga użycia narzędzi tworzących polecenia języka definicji danych (DDL) do przyszłej hurtowni, a konfiguracja motoru systemu DSS - odpowiednich narzędzi tego środowiska.

Niezwykle ważny jest tu sposób rozwiązania budowy warstwy odwzorowującej model biznesowy w model fizyczny hurtowni danych - motor wykonawczy systemu DSS i istniejące już aplikacje DSS muszą łatwo asymilować kolejne modyfikacje stosowanego modelu danych.

Istotnym elementem architektury technicznej jest zbiór metadanych, w którym zapisana jest informacja o strukturze danych w minihurtowni tematycznej lub samej hurtowni oraz o sposobie odwzorowania danych źródłowych do hurtowni i ładowania danych.

Metadane zapewniają elastyczność przetwarzania danych. Zmiany struktury hurtowni danych są zapisywane w zbiorze metadanych. Usługi raportowania i analiz oraz oprogramowanie klientów uzyskują dostęp do danych hurtowni za pośrednictwem metadanych. Dzięki takiemu interfejsowi oraz wydzieleniu w odrębny moduł usług raportowania i analiz jest możliwych wiele zmian w strukturze hurtowni danych bez utraty funkcjonalności aplikacji klienckich.

Modele danych a infrastruktura techniczna

Ogólne zasady stosowania technologii systemów DSS/EIS

rozdzielanie transakcyjnych baz danych i hurtowni danych

serwer hurtowni danych powinien charakteryzować się bardzo dobrymi wynikami testów TPC-D

DSS/EIS powinny działać online i pozwalać na wykonanie dowolnej operacji analizy w dowolnej chwili.

Zanim skonstruujemy hurtownię danych i metadane, musimy określić wzajemną lokalizację tych zbiorów. W fazie wstępnej projektu hurtowni danych projektant wybiera narzędzia i decyduje, czy zastosować bazy wielowymiarowe czy relacyjne.

Następnie należy oszacować początkowy rozmiar danych, szybkość ich przyrostu w czasie, czas trwania ekstrakcji danych i zaangażowanie zasobów w procesie ładowania przyrostowego i przetwarzania analitycznego. Określenie tych parametrów pozwala na prawidłowy dobór platformy sprzętowej i systemowej dla projektowanej hurtowni danych.

Podejmowane czasami próby łączenia na jednej maszynie systemów transakcyjnych i systemów DSS/EIS kończą się zazwyczaj niepowodzeniem, ponieważ systemy transakcyjne i wspomagania podejmowania decyzji cechuje bardzo różny sposób obciążania zasobów systemowych.

Wyjątkiem od tej reguły mogą być specjalnie dobrane serwery centralne lub komputery mainframe, które umożliwią obsługę wszystkich systemów wspomagania zarządzania i systemów wspomagania podejmowania decyzji na jednej silnej maszynie.

Stosuje się trzy konfiguracje infrastruktury technicznej:

Konfiguracja jednowarstwowa (One-tier architecture)

hurtownia danych, metadane oraz oprogramowanie DSS posadowione na stacji klienta (PC)

Konfiguracja dwuwarstwowa (Two-tier architecture)

oprogramowanie końcowego użytkownika na stacji klienta

hurtownia danych i metadane posadowione na zdalnym serwerze

Konfiguracja trzywarstwowa (Three-tier architecture)

oprogramowanie końcowego użytkownika na stacji klienta (PC)

wspólne oprogramowanie DSS oraz metadane na serwerze środowiska DSS

hurtownia danych na serwerze baz danych

Należy pamiętać, że nie każdy zestaw narzędzi pozwala na stosowanie wszystkich wymienionych konfiguracji.

Wdrażanie systemu DSS/EIS i zazwyczaj niezbędny rozwój platformy sprzętowej są okazją do rozważenia koncepcji konsolidacji serwerów (platform) na jednym serwerze centralnym.

Powiększ

Tendencja do centralizacji zasobów powoduje, że wielu dostawców oferuje wysoko wydajne serwery unixowe, których moc obliczeniowa jest porównywalna z mocą komputerów mainframe. Jednak wydajność systemu nie wystarczy, by na takim serwerze skonsolidować wszystkie posiadane aplikacje i platformy. Często uzasadniona jest obawa, iż scentralizowana platforma nie zapewni właściwego poziomu niezawodności i bezpieczeństwa. Natomiast brak fizycznej separacji danych i aplikacji może stać się źródłem poważnych błędów, a awaria pojedynczego podzespołu spowoduje dezorganizację reszty systemu.

Modele logiczne

Początkiem procesu tworzenia hurtowni jest zdefiniowanie modelu logicznego. Etap ten rozpoczyna się od określenia wymagań dotyczących modelu. Wymagania te gromadzi się na podstawie wywiadów, konsultacji i analiz przeprowadzanych wśród końcowych użytkowników. Na podstawie przyjętych założeń tworzy się wielowymiarowy model danych, który będzie podstawą schematu hurtowni. Proces modelowania danych powinien zakończyć się stworzeniem diagramu, który zawiera definicje wymiarów hurtowni danych, atrybutów wymiarów, relacji między atrybutami wymiarów - powiązań i hierarchii oraz faktów (metryk).

Zadania realizowane w czasie procesu ekstrakcji danych

Przygotowanie mapy konwersji/transformacji danych

plan ogólny

przygotowanie lub dobór narzędzi

uszczegółowienie planu

Ładowanie tablic wymiarów

przeniesienie danych do wybranej statycznej tablicy wymiarów

przeniesienie danych do wybranej zmiennej tablicy wymiarów

przeniesienie danych do pozostałych tablic wymiarów

Ładowanie tablic faktów

opracowanie i przetestowanie algorytmów załadowania danych archiwalnych (tzw. pierwsze ładowanie)

opracowanie i przetestowanie algorytmów ładowania przyrostowego

opracowanie i przetestowanie algorytmów agregacji danych

automatyzacja procesu ładowania (głównie przyrostowego)

Kontrola poprawności

Przed jej rozpoczęciem należy określić standardowe kryteria, jakim podlegać będą dane hurtowni. Definiując te kryteria trzeba wziąć pod uwagę takie cechy, jak:

zgodność danych między systemami źródłowymi a danymi w hurtowni

kompletność danych (odpowiada na pytanie, czy wszystkie dane w systemach źródłowych mają odpowiedniki w hurtowni danych)

spójność danych

unikalność, która gwarantuje niepowtarzalność danych w hurtowni

częstotliwość aktualizacji danych w hurtowni (powinna być wystarczająca na potrzeby analizy danych i wspomagania podejmowania decyzji). Jednocześnie w danych pochodzących z systemów źródłowych występuje wiele usterek, które wymagają korekty, np.

niekonsekwentne używanie kodów i znaczników

pewne kolumny mogą być wykorzystywane do różnych celów, co nie jest zawsze udokumentowane

niektóre identyfikatory mogą mieć podwójną interpretację.

Pewne błędy można usunąć przed rozpoczęciem ekstrakcji przez identyfikację najbardziej wiarygodnego ze źródeł danych, sprawdzenie, w jakim stopniu systemy źródłowe zawierają niepoprawne dane oraz współpracę z autorami systemu transakcyjnego nad usuwaniem wad w danych. Pozostałe usterki należy usuwać w obszarze pośrednim, przed załadowaniem danych do hurtowni.

Wymiary hurtowni danych nie występują bezpośrednio w hurtowni, ale są pewną koncepcją oznaczającą obszary zainteresowań końcowego użytkownika (np. wymiar Produkt oznacza obszar dotyczący produktu, wymiar Geografia definiuje położenie, czyli miejsce wytwarzania lub sprzedaży produktu). Wymiary dostarczają perspektyw, z których będzie można analizować dane. Z reguły systemy mają trzy wymiary (np. Czas, Produkt, Geografia) lub ich więcej. Można sobie też wyobrazić system, który będzie miał tylko jeden wymiar. Wymiary składają się z jednego lub większej liczby atrybutów (np. wymiar Czas ma atrybuty: Rok, Półrocze, Kwartał, Miesiąc i inne).

Między atrybutami wchodzącymi w skład danego wymiaru zachodzą pewne relacje, np. menedżer zarządza jednym lub wieloma regionami. Relacje wyznaczają logiczne połączenia atrybutów w ramach wymiaru. Atrybuty danego wymiaru, między którymi nie zachodzi bezpośrednia relacja, mogą być powiązane nie wprost poprzez inne atrybuty w ramach tego samego wymiaru (przechodniość relacji). Atrybuty z różnych wymiarów są ze sobą powiązane tylko poprzez fakty występujące na przecięciu wymiarów.

Relacje między atrybutami są podstawą do zdefiniowania hierarchii w wymiarze. Hierarchie logicznie porządkują atrybuty w ramach wymiaru. W danym wymiarze może istnieć więcej niż jedna hierarchia.

Wyróżnia się hierarchię główną, która leży w centrum zainteresowań użytkowników (np. menedżer Ţ region Ţ rynek Ţ sklep) oraz hierarchie atrybutów dodatkowych - hierarchie opisowe budowane na podstawie hierarchii głównej (np. województwo Ţ sklep, kolor Ţ produkt). W kontekście aplikacji DSS relacje zachodzące między atrybutami definiują ścieżki przeglądania oraz analizy danych - ich rozwijania i zwijania.

Obserwowane w przedsiębiorstwie wielkości i dane (sprzedaż, stany magazynowe, pewne wartości wyliczone) są przechowywane w hurtowni jako fakty. Fakty są podstawą budowy metryk, które dalej podlegają wszechstronnej analizie biznesowej i służą do monitorowania głównych czynników biznesowych oraz szacowania wydajności przedsiębiorstwa. Należy pamiętać, że fakty znajdujące się w hurtowni danych mogą pochodzić z różnych systemów źródłowych i powinny, w docelowej tablicy faktów, być przechowywane w jednolitej postaci, być wyrażone w tych samych jednostkach.

Model fizyczny

Przed utworzeniem modelu fizycznego należy podjąć decyzję o wyborze schematu hurtowni danych. Podstawowe schematy to: model wielowymiarowy, relacyjne schematy nie znormalizowanej gwiazdy, znormalizowany schemat płatka śniegu, a także każda kombinacja tych modeli.

Wśród obiektów znajdujących się w hurtowni relacyjnej wyróżnia się tablice wymiarów, relacji i faktów. Tablice wymiarów opisują atrybuty danego wymiaru. W przypadku modelu gwiazdy tablice wymiarów zawierają identyfikator atrybutu (z reguły atrybut numeryczny) i jego opis (z reguły atrybut tekstowy) oraz ewentualnie pewne opisy dodatkowe.

Tablice relacji opisują powiązania między atrybutami modelu. W najprostszym przypadku zawierają one dwie kolumny identyfikatorów atrybutów, między którymi zachodzi relacja. Przykładowo, dla tablic wymiarów: Rynek i Sklep tworzy się tablicę relacji opisującą przynależność sklepu do danego rynku.

Tablice faktów zawierają kolumny identyfikujące fakt (identyfikatory atrybutów) oraz same fakty i niekiedy kolumny atrybutów wielowymiarowych (faktów tekstowych). Identyfikatory atrybutów wszystkich wymiarów przecinających się w tablicy faktów tworzą klucz główny tej tablicy, każdy identyfikator jest jednocześnie kluczem obcym z odpowiedniej tablicy wymiaru.

W przypadku bardzo dużych tablic faktów korzystne może się okazać podzielenie (partycjonowanie) tablicy na kilka mniejszych (według pewnego atrybutu). Użycie technik partycjonowania jest bardzo ważne przy tworzeniu hurtowni danych. Podzielone tablice faktów są łatwiejsze w zarządzaniu, łatwiej przetwarza się je wsadowo, a aplikacja DSS potrafi znacznie szybciej dostarczyć odpowiedzi na pytania dotyczące poszczególnych części tablicy niż tablicy w całości.

Powiększ

Odwzorowania wymiarów i atrybutów modelu biznesowego w fizycznie istniejące tabele hurtowni danych dokonuje się za pomocą motoru systemu DSS. Moduł ten w zarządzaniu systemem DSS posiłkuje się specjalną bazą danych zwaną metadanymi. Baza metadanych w szczególności zawiera informacje o danych i strukturach używanych w systemie DSS. Informacje te wykorzystywane są przy tłumaczeniu zapytań dotyczących wielowymiarowych obiektów DSS na odpowiadające im pytania SQL i odwrotnie - wyników tych zapytań w formie wielowymiarowych raportów. Na wykorzystaniu tych właśnie informacji zawartych w metadanych oparta jest budowa systemów ROLAP.

Uogólniając - baza metadanych powinna być globalnym repozytorium o całym systemie hurtowni danych i zawierać nie tylko informacje sterujące przepływem danych między hurtownią i aplikacją DSS, ale i definicje źródeł danych, aplikacji końcowych czy transformacji danych.

Ładowanie danych, czyli ekstrakcja

Ekstrakcja danych to jeden z etapów tworzenia i funkcjonowania hurtowni danych. Aby rozpocząć przenoszenie danych, muszą być wcześniej zrealizowane następujące zadania: rozpoznanie wymagań stawianych hurtowni danych, rozpoznanie struktury systemów transakcyjnych i zdefiniowanie architektury hurtowni.

Dopiero po wykonaniu tych zadań możliwe jest rozpoczęcie analizy problemu ekstrakcji danych. Poza problemami teoretycznymi należy wziąć pod uwagę możliwości techniczne: posiadany sprzęt i oprogramowanie. Ekstrakcja jest procesem bardzo obciążającym systemy komputerowe, stąd celowe jest zarezerwowanie zasobów przeznaczonych na rzecz tworzenia hurtowni danych. Warto również stworzyć środowisko pracy programistów, terminologię i nazewnictwo. Wszystkie te parametry powinny być znane przed przystąpieniem do właściwych prac projektowych i realizacyjnych. Ze względu na wielość i różnorodność zadań, które są realizowane podczas tworzenia systemu ekstrakcji danych, należy zwrócić znaczną uwagę na szczegółowe dokumentowanie tego procesu.

Gdy dane są już wyczyszczone, należy jeszcze sprawdzić poprawność odpowiedzi otrzymywanych z hurtowni. Można tego dokonać przez porównanie wyników z hurtowni z wynikami zapytań kierowanych do systemów źródłowych (można ten proces oczywiście zautomatyzować) albo poprzez sprawdzanie "ręczne", kiedy nie ma możliwości otrzymania pewnych wyników porównawczych.

Aplikacje DSS

Typowy projekt pilotażowy powinien zawierać

częściowe rozpoznanie wymagań biznesowych i technicznych

instalację oprogramowania

stworzenie modeli danych

implementację prototypowej hurtowni danych

opracowanie procedur ekstrakcji danych

przeprowadzenie ekstrakcji danych (w niezbędnym zakresie)

budowę prototypowych raportów DSS

testowanie i prezentację systemu.

Projekt pilotażowy nie obejmuje

przyrostowego procesu ekstrakcji

bezpieczeństwa systemu

optymalizacji pracy systemu

wyrafinowanych lub bardzo specjalizowanych funkcji (np. korzystanie z DSS przez Internet).

Relacje zachodzące w hurtowni między wymiarami, atrybutami i faktami definiują ścieżki przeglądania oraz analizy i drążenia danych. Obserwowane w przedsiębiorstwie wielkości i dane (np. sprzedaż, stany magazynowe itp.) są przechowywane w hurtowni jako fakty. Fakty są podstawą budowy metryk, które dalej podlegają wszechstronnej analizie biznesowej.

Aplikacje DSS klasy ROLAP to specjalizowane narzędzia dla użytkowników końcowych, które służą do wyszukiwania danych w hurtowni i sporządzania raportów. Są one tak przygotowane, by wspomagać pracę użytkownika. Opracowanie nowego wzoru raportu i jego wykonanie nie wymagają umiejętności programowania ani znajomości SQL-a. Tworząc raport, korzystamy z modelu logicznego i metadanych. Ponieważ większość użytkowników używa zwykle tych samych zestawień, a zapytania ad hoc tworzy w wyjątkowych sytuacjach, dlatego przygotowuje się przy użyciu narzędzi DSS zestaw typowych raportów EIS, których uruchomienie wymaga od użytkownika wyłącznie podstawowej znajomości interfejsu.

Organizacja pracy i zarządzania projektem

Przedstawiona metodyka Business Dimensional Lifecycle ma charakter jedynie ogólny. Należy ją uzupełnić strategią pracy zespołowej, podziałem ról, alokacją zasobów i harmonogramem realizacji. Poniżej zaprezentowano sprawdzony podział zespołu projektantów i realizatorów systemu na dwie grupy:

Front-end Team - realizujący zadania bezpośrednio w środowisku klienta, rozpoznaje wymagania i potrzeby, realizuje wdrożenie. W skład tego zespołu wchodzą użytkownicy biznesowi ze strony klienta.

Back-end Team - pracujący "w tle", np. w firmie dostarczającej technologię i wdrażającej projekt.

Grupy te powinny współpracować ze sobą i wymieniać informacje oraz przekazywać raporty o stanie pracy do kierownika projektu.

Do prawidłowego przebiegu pracy i uzyskania pozytywnego rezultatu końcowego konieczne jest zaangażowanie w realizację projektu przedstawicieli zleceniodawcy i końcowych użytkowników. Nie jest możliwe zrealizowanie dobrego systemu DSS bez współpracy z użytkownikiem. Nie ma uniwersalnych systemów DSS dla każdego. Nie istnieje modelowy DSS np. dla sprzedaży hurtowej lub do zarządzania elektrownią, który można powielać w kolejnych przedsiębiorstwach danego typu. Jednak zdobyte doświadczenia są zawsze pomocne.

Projekty pilotażowe

Tworzenie systemu DSS i hurtowni danych nie jest przedsięwzięciem ani prostym, ani tanim. Konieczne jest więc dobre przygotowanie projektu, prawidłowy wybór narzędzi i wykonawców. Doświadczenie autorów wskazuje, że najlepszym sposobem poprawnego podjęcia tych decyzji jest realizacja projektu pilotażowego. Celem projektu jest stworzenie prototypu aplikacji systemu DSS, działającego na reprezentatywnym przykładzie hurtowni danych.

Przed rozpoczęciem realizacji "pilota" należy rozpoznać wymagania biznesowe oraz określić cel i zakres systemu DSS. Dalsze etapy prac to stworzenie minihurtowni danych oraz kilku raportów wybranych do realizacji. Efektem końcowym jest w pełni funkcjonalny, lecz ograniczony co do zakresu danych i liczby raportów, podsystem DSS.

Czas i koszty realizacji projektu pilotażowego są znacznie krótsze. Zleceniodawca ma możliwość poznania wykonawców, ich sposobu pracy czy kompetencji. Może zapoznać się z zaletami oferowanego rozwiązania i proponowanych narzędzi.

Czas realizacji systemu pilotażowego zależy przede wszystkim od stopnia rozpoznania wymagań biznesowych, liczby danych przenoszonych do hurtowni i współpracy ze zleceniodawcą. W wielu przypadkach wystarczy od 2 do 4 tygodni, by stworzyć udaną prototypową hurtownię danych i w pełni funkcjonalny pilotażowy podsystem DSS.

--------------------------------------------------------------------------------

Marcin Gorawski i Andrzej Konopacki są specjalistami od systemów DW/DSS w firmie RR/Recovery Research - Gorawski Consulting Group.


TOP 200