Efektywne wdrożenie BI
- z notatnika praktyka
WLODEK BIELSKI
ITMAGINATION
Agenda
• Architektura DWH/BI
• 7 kluczowych błędów
• Metodyki zarządzania projektem
• Najlepsze praktyki
Klasyczna architektura DWH/BI
Dlaczego projekty BI są trudne?
Mniej niż 30% projektów BI osiąga zakładane cele biznesowe
(Gartner, 2012)
• Wiele różnorodnych i słabo rozpoznanych źródeł danych
• Potrzeba zbudowania hurtowni (do 80% czasu projektu)
• Brak wystarczających kompetencji i doświadczenia
• Niska jakość danych
Błąd 1: Brak wsparcia sponsora projektu
• DWH/BI angażuje wiele działów w organizacji
• Rozbieżne cele i interesy
• IT
• Księgowość
• Produkcja
• Sytuacje patowe – gdy zawodzą procesy
• Problemy z angażowaniem zasobów biznesu
• Rozstrzygnięcie, ustalenie priorytetów, angażowanie
Błąd 2: Zakładanie statyczności DWH/BI
• Zmienne warunki otoczenia
• Systemy źródłowe (OLTP)
• Strategiczne inicjatywy biznesu
• Apetyt przychodzi w miarę jedzenia
• Rosnące oczekiwania biznesu
• Większa dojrzałość analityczna (what-if, predykcja)
• Ograniczenia czasowe projektu
• Fizyczna niedostępność kluczowych użytkowników
• Ograniczony budżet roczny
Błąd 3: Brak zdefiniowanej strategii BI
• Koncentracja na korzyści „tu i teraz”
• Brak współpracy i synergii między działami
• Właściwa strategia determinuje m.in.:
• Wybór technologii i narzędzi
• Priorytety produktów
• Przyszłość rozwiązania (lokalne/taktyczne/strategiczne)
Błąd 4: Koncentrowanie się na tym co widoczne
• „Just give me a dashboard. Now!” (Gartner 2008)
• Brak zrozumienia szerszego kontekstu:
• Wielości i złożoności źródłowych systemów
• Przepływów danych
• Istniejących problemów infrastrukturalnych
Błąd 5: Przywiązanie do istniejących raportów
• Odtworzenie stanu istniejącego nie ma sensu!
• Wypadkowa wielu czynników, często przypadkowych
• Konserwuje istniejące wady i ograniczenia
• Trudność weryfikacji poprawności danych
• Często powtarzany fałsz staje się prawdą
• Niemożliwość odtworzenia pełnej logiki (np. „Excel hell”)
• Błędy ludzkie
Błąd 6: Zbytnia koncentracja na technologii
• Użycie „modnej” technologii
• Wybór pod wpływem subiektywnych czynników
• Brak właściwej ewaluacji narzędzi
• Użycie przestarzałej technologii
• Ignorowanie kontekstu organizacyjnego
• Wsparcie techniczne i utrzymanie
• Koszty, licencje
• Harmonogramowanie bez uwzględnienia ryzyka technologii
Błąd 7: Niewłaściwy dobór członków zespołu
• Rzadko spotykane połączenie umiejętności
• SQL, MDX, DAX, R
• Analiza, komunikacja, prototypowanie
• Proaktywne proponowanie rozwiązań
• Specjalizacja czy rozproszenie umiejętności?
• BI Developer + BI Analyst = BI Consultant
Metodyki prowadzenia projektów DWH/BI
• Mniej rozpowszechnione niż w przypadku inżynierii oprogramowania
• Różnorodne, trwające w czasie projekty – wiele produktów
• Często więcej biznesu niż technologii
• Własne propozycje (dziedzinowe, autorskie)
• Dostosowanie ogólnych metodyk (PMI, PRINCE2)
• Metodyki vendorów (MSF/MOF, OUM, ASAP)
Metodyki formalne vs zwinne
BI
ETL
DWH
Maksymalizacja
wartości
Minimalizacja
ryzyka
Metodyki formalne vs zwinne
BI
ETL
DWH
Zwinne
Formalne
Proponowane metodyki
• PMI, PRINCE, MSFDWH
• PMI, PRINCE, MSFETL
• Agile, SCRUMBI
• ITIL, MOFSupport
Najlepsze praktyki
• Wczesne zaangażowanie biznesu
• Kick-off, Fit-Gap – właściwe zasoby i wymiarowanie spotkań
• Wczesne prototypowanie w lekkich narzędziach
• PrototypowanieGUI, inspiracje
• Model danych – np. PowerPivot
• Wczesne testowanie produktów
• Self-service BI
• Nie jesteśmy w stanie zaimplementować wszystkich raportów
• Planowanie wsparcia i rozwoju
Podsumowanie
• Architektura DWH/BI
• 7 kluczowych błędów
• Metodyki zarządzania projektem
• Najlepsze praktyki
Dziękuję za uwagę!
WLODEK.BIELSKI@OUTLOOK.COM

Włodek Bielski: Efektywne wdrożenie BI - z notatnika praktyka

  • 1.
    Efektywne wdrożenie BI -z notatnika praktyka WLODEK BIELSKI ITMAGINATION
  • 2.
    Agenda • Architektura DWH/BI •7 kluczowych błędów • Metodyki zarządzania projektem • Najlepsze praktyki
  • 3.
  • 4.
    Dlaczego projekty BIsą trudne? Mniej niż 30% projektów BI osiąga zakładane cele biznesowe (Gartner, 2012) • Wiele różnorodnych i słabo rozpoznanych źródeł danych • Potrzeba zbudowania hurtowni (do 80% czasu projektu) • Brak wystarczających kompetencji i doświadczenia • Niska jakość danych
  • 5.
    Błąd 1: Brakwsparcia sponsora projektu • DWH/BI angażuje wiele działów w organizacji • Rozbieżne cele i interesy • IT • Księgowość • Produkcja • Sytuacje patowe – gdy zawodzą procesy • Problemy z angażowaniem zasobów biznesu • Rozstrzygnięcie, ustalenie priorytetów, angażowanie
  • 6.
    Błąd 2: Zakładaniestatyczności DWH/BI • Zmienne warunki otoczenia • Systemy źródłowe (OLTP) • Strategiczne inicjatywy biznesu • Apetyt przychodzi w miarę jedzenia • Rosnące oczekiwania biznesu • Większa dojrzałość analityczna (what-if, predykcja) • Ograniczenia czasowe projektu • Fizyczna niedostępność kluczowych użytkowników • Ograniczony budżet roczny
  • 7.
    Błąd 3: Brakzdefiniowanej strategii BI • Koncentracja na korzyści „tu i teraz” • Brak współpracy i synergii między działami • Właściwa strategia determinuje m.in.: • Wybór technologii i narzędzi • Priorytety produktów • Przyszłość rozwiązania (lokalne/taktyczne/strategiczne)
  • 8.
    Błąd 4: Koncentrowaniesię na tym co widoczne • „Just give me a dashboard. Now!” (Gartner 2008) • Brak zrozumienia szerszego kontekstu: • Wielości i złożoności źródłowych systemów • Przepływów danych • Istniejących problemów infrastrukturalnych
  • 9.
    Błąd 5: Przywiązaniedo istniejących raportów • Odtworzenie stanu istniejącego nie ma sensu! • Wypadkowa wielu czynników, często przypadkowych • Konserwuje istniejące wady i ograniczenia • Trudność weryfikacji poprawności danych • Często powtarzany fałsz staje się prawdą • Niemożliwość odtworzenia pełnej logiki (np. „Excel hell”) • Błędy ludzkie
  • 10.
    Błąd 6: Zbytniakoncentracja na technologii • Użycie „modnej” technologii • Wybór pod wpływem subiektywnych czynników • Brak właściwej ewaluacji narzędzi • Użycie przestarzałej technologii • Ignorowanie kontekstu organizacyjnego • Wsparcie techniczne i utrzymanie • Koszty, licencje • Harmonogramowanie bez uwzględnienia ryzyka technologii
  • 11.
    Błąd 7: Niewłaściwydobór członków zespołu • Rzadko spotykane połączenie umiejętności • SQL, MDX, DAX, R • Analiza, komunikacja, prototypowanie • Proaktywne proponowanie rozwiązań • Specjalizacja czy rozproszenie umiejętności? • BI Developer + BI Analyst = BI Consultant
  • 12.
    Metodyki prowadzenia projektówDWH/BI • Mniej rozpowszechnione niż w przypadku inżynierii oprogramowania • Różnorodne, trwające w czasie projekty – wiele produktów • Często więcej biznesu niż technologii • Własne propozycje (dziedzinowe, autorskie) • Dostosowanie ogólnych metodyk (PMI, PRINCE2) • Metodyki vendorów (MSF/MOF, OUM, ASAP)
  • 13.
    Metodyki formalne vszwinne BI ETL DWH Maksymalizacja wartości Minimalizacja ryzyka
  • 14.
    Metodyki formalne vszwinne BI ETL DWH Zwinne Formalne
  • 15.
    Proponowane metodyki • PMI,PRINCE, MSFDWH • PMI, PRINCE, MSFETL • Agile, SCRUMBI • ITIL, MOFSupport
  • 16.
    Najlepsze praktyki • Wczesnezaangażowanie biznesu • Kick-off, Fit-Gap – właściwe zasoby i wymiarowanie spotkań • Wczesne prototypowanie w lekkich narzędziach • PrototypowanieGUI, inspiracje • Model danych – np. PowerPivot • Wczesne testowanie produktów • Self-service BI • Nie jesteśmy w stanie zaimplementować wszystkich raportów • Planowanie wsparcia i rozwoju
  • 17.
    Podsumowanie • Architektura DWH/BI •7 kluczowych błędów • Metodyki zarządzania projektem • Najlepsze praktyki
  • 18.