Budowa systemu BI

Budowa systemu wspomagającego
podejmowanie decyzji
Metodyka projektowo – wdrożeniowa
Agenda
Systemy wspomagające decyzje – Business Intelligence (BI)
Rodzaje systemów BI
Korzyści z wdrożeń BI
Zagrożenia dla wdrożeń
Dobre praktyki wdrożeń systemów BI
Systemy wspomagające decyzje
– Business Intelligence (BI)
Koncepcja architektury systemów BI w
przedsiębiorstwie
Interfejs między systemami operacyjnymi a działem kontrolingu, finansów, kadrą kierowniczą
Warstwy systemów w przedsiębiorstwie
Przepływ danych między warstwami
Obszar Business Intelligence
Rola baz danych
Koncepcja architektury systemów BI w
przedsiębiorstwie
Systemy firmy
Dane nieprzetworzone
Funkcjonalności specyficzne dla danego obszaru
Przeznaczone do obsługi operacyjnej – NIE RAPORTOWANIA
Heterogeniczne źródła danych i metadanych
Współdzielone słowniki, np. klienci (w „Idealnym Świecie”)
Koncepcja architektury systemów BI w
przedsiębiorstwie
Hurtownia danych
Zintegrowane dane (narzędzia ETL: Extract-Transform-Load)
Dane wstępnie przetworzone
Struktury i hierarchie (metadane)
Współdzielone słowniki (metadane)
Łączenie i „czyszczenie” danych z wielu źródeł
Przechowywanie historii
Dane na poziomie transakcji
Koncepcja architektury systemów BI w
przedsiębiorstwie
Data-marty
Obszary danych dla grupy odbiorców
Słowniki (metadane) biznesowe
Dane przetworzone
Wydajniejsze, szybsze raportowanie
Dane na poziomie transakcji lub pozycji raportowych
Koncepcja architektury systemów BI w
przedsiębiorstwie
Aplikacje EPM
Ograniczone do danych dedykowanych dla obszarów biznesowych
Metadane biznesowe (wspólne słowniki)
Wbudowane funkcje kalkulacyjne
Interakcja z użytkownikiem – edycja danych, uruchamianie kalkulacji
Wbudowane funkcjonalności specyficzne dla obszaru biznesowego
Zasilone danymi zewnętrznymi (narzędzia ETL)
Koncepcja architektury systemów BI w
przedsiębiorstwie
Raportowanie
Niezbędny element każdej warstwy systemów BI
Zapewnia wizualizację danych z innych warstw
Różnice między analizą a raportowaniem
Wiele kanałów dostępu do danych – przeglądarka, MS Office, inne
Zwykle łączy wiele źródeł
Możliwe wykorzystanie jako samodzielnego elementu
Podział logiczny systemów BI
Systemy Informowania Kierownictwa (SIK, MIS, EIS)
Zwykle hurtowania danych w połączeniu z data-mart, aplikacjami EPM i
raportowaniem
Systemy wspomagania decyzji (DSS)
Zwykle data-mart w połączeniu z raportowaniem
Systemy informacji geograficznej (GIS)
Zwykle data-mart (specyficzne dane) w połączeniu z raportowaniem
Rodzaje systemów BI
Podstawowy podział systemów
Sposób wdrożenia systemu
Systemy „z pudełka”
Wpierane przez firmy lub organizacje rozwijające oprogramowanie. Zwykle wdrożenie polega na parametryzacji i
wykorzystaniu wbudowanych funkcjonalności.
Systemy „custom”
Budowane w całości przez wewnętrzne lub zewnętrzne zespoły projektowe.
Systemy mieszane
Oparte na oprogramowaniu „z pudełka” rozbudowanym przez zespół projektowy o dodatkowe moduły/funkcjonalności.
Podział ze względu na obsługiwane
obszary biznesowe
Podział ze względu na odbiorców biznesowych
Zintegrowane systemy BI – cała firma
Raportowanie dedykowane – marketing, sprzedaż, HR
Planowanie i budżetowanie – kontroling
Sprawozdawczość finansowa – zarząd, regulator, instytucje zewnętrzne
Podział ze względu na koncepcję
rozwiązania
Sposób przechowywania raportowanych danych
Systemy wielowymiarowe Multidimensional OLAP (MOLAP)
Systemy relacyjne Relational OLAP (ROLAP)
Systemy mieszane Hybrid OLAP (HOLAP)
Sposób przechowywania danych determinuje sposób definiowania zapytań, raportów, kalkulacji a w
związku z tym również przydatność do poszczególnych zastosowań.
Podział ze względu na koncepcję
rozwiązania
Rodzaj pamięci wykorzystywanej do przechowywania raportowanych
danych
Systemy bazodanowe (dyskowe)
Systemy „in-memory” (pamięć operacyjna)
Systemy typu „in-memory” powinny być szybsze i wydajniejsze, znacznie większe są ich wymagania
sprzętowe. Duże systemy „in-memory” BI są jednak dopiero rozwijane.
Decyzja o wyborze powinna być oparta na analizie wymagań.
Producenci systemów BI
+ Dostawcy z Polski
Korzyści z wdrożeń BI
Korzyści z wdrożeń systemów
raportowych
Korzyści biznesowe
Metadane biznesowe zamiast technicznych
Szybsze raportowanie
Samodzielna (mniejszy udział IT) obsługa raportowania (teoria a praktyka)
„Jedna wersja prawdy”
Lepsze informacje pozwalające podejmować lepsze decyzje
Korzyści z wdrożeń systemów
raportowych
Korzyści technologiczne (IT)
Standaryzacja
Bezpieczeństwo
Kontrola
Mniejsze obciążenie systemów źródłowych raportami (hurtownia, data-marty)
Clustering, Workload Management i Deployment
Korzyści z wdrożeń systemów EPM
Korzyści biznesowe
Kontrola procesu planowania, budżetowania, konsolidacji
Procesy akceptacji danych
Kontrolki walidacyjne
Automatyzacja:
Zasilania danymi
Przeliczeń modeli
Przechowywanie wersji danych i historii
Korzyści z wdrożeń systemów EPM
Korzyści technologiczne (IT)
Standaryzacja
Bezpieczeństwo
Kontrola
Mniejsze obciążenie systemów źródłowych raportami
Clustering, Workload Management i Deployment
Zagrożenia dla wdrożeń
Etap sprzedaży
KLIENT
„Wszystko albo nic”
„Fixed price”
Ograniczenia czasowe
OFERTA
Konkurencja
Możliwości
oprogramowania
WYKONAWCA
Wycena przed analizą
Wymagania „na wszelki
wypadek”
Excel, Excel, Excel 
Brak czasu
Brak precyzji
ANALIZA
Zamrożenie wymagań
Niezrozumienie
wymagań
WYKONAWCA
KLIENT
Etap analizy wymagań
Etap budowy
KLIENT
SYSTEM
Jakość danych i
metadanych
Błędne założenia
WYKONAWCA
Wydajność
SYSTEM
Wymagania
Wykonanie
WYKONAWCA
KLIENT
Zagrożenia dla wdrożeń
Metody zapobiegania zagrożeniom
Zarządzanie wymaganiami
„Quick-win”
„Twardy” Project Management
Metodologia mieszana
Dobre praktyki wdrożeń BI
Dobre praktyki wdrożeń BI
Baza wiedzy (np. w aplikacji Mantis)
Konsultanci przeszkoleni w metodyce realizacji projektów
Kierownicy Projektów doświadczeni we wdrożeniach BI
Łączenie ekspertyzy biznesowej z wiedza techniczną i znajomością narzędzia
Dobre praktyki wdrożeń BI
Podsumowanie
Podejście projektowe łączące metodykę Waterfall i Agile pozwala uniknąć długich i kosztownych zmian do sparametryzowanego
systemu na etapie testów rozwiązania lub po jego uruchomieniu produktywnym.
Rundy weryfikacji aplikacji z Klientem wymuszają większe zaangażowanie kluczowych użytkowników wdrażanej aplikacji co
pozwala na płynne jej przejęcie na etapie wdrożenia produktywnego przez pracowników Klienta.
Weryfikacja wdrażanych funkcjonalności zapewnia poczucie własności implementowanego systemu u jego odbiorców.
Podejście mieszane pozwala uniknąć sytuacji, kiedy wdrożony system działa inaczej niż oczekiwali tego użytkownicy a
zakończona jest już faza implementacji rozwiązania. Weryfikacja oczekiwań Klienta z możliwościami oprogramowania pomaga
negocjować i zarządzać wymaganiami użytkownika.
DZIĘKUJEMY ZA UWAGĘ