Decyzja o migracji ponad 200 raportów z Google Looker do Microsoft Power BI i Fabric była podyktowana strategiczną chęcią unifikacji ekosystemu danych i obniżenia TCO. Pomyślna migracja to transformacja biznesowa, a nie projekt IT, oparta na czterech fazach: dekonstrukcji, tłumaczenia, odbudowy i wdrożenia. To mapa drogowa, jak przekształcić wyzwanie technologiczne w szansę na redukcję długu technicznego, wdrożenie solidnego ładu danych i prawdziwą demokratyzację analityki.
Kontekst strategiczny: Więcej niż zmiana narzędzia
Nasza podróż rozpoczęła się nie od pytania „jakie narzędzie jest lepsze?”, ale od strategicznej decyzji o unifikacji naszego ekosystemu danych. Przejście z Google Looker, dojrzałej i cenionej przez naszych analityków platformy, na Microsoft Power BI i Fabric było podyktowane dążeniem do stworzenia zintegrowanego środowiska, które obejmuje inżynierię danych, analitykę i self-service BI. Chodziło o obniżenie całkowitego kosztu posiadania (TCO) poprzez konsolidację narzędzi i wykorzystanie natywnych integracji w ramach stosu technologicznego, z którego już korzystaliśmy, jak Azure. Decyzja o migracji rzadko jest podyktowana wyłącznie cechami samego narzędzia analitycznego. Znacznie częściej jest to objaw szerszej strategii IT, która w naszym przypadku zakładała maksymalizację zwrotu z inwestycji w platformę Microsoft. Wybór Power BI nie wynikał z jego abstrakcyjnej wyższości nad Lookerem, ale z jego głębokiej synergii z istniejącą i planowaną infrastrukturą firmy.
Skala wyzwania: Transformacja, nie projekt IT
Staliśmy przed zadaniem migracji ponad 200 kluczowych raportów, które były krwiobiegiem analitycznym dla setek użytkowników w różnych działach. Szybko zrozumieliśmy, że nie jest to proste ćwiczenie „lift-and-shift”. To była transformacja sposobu, w jaki nasza organizacja myśli o danych, zarządza nimi i je konsumuje. Sama skala przedsięwzięcia natychmiast zasygnalizowała, że największym ryzykiem nie będzie technologia, lecz zarządzanie złożonością, ludźmi i procesami. Historia projektów BI uczy, że największe problemy mają charakter ludzki - brak zaangażowania, wewnętrzna polityka - oraz procesowy, jak niejasne wymagania czy niedocenienie skali zadania. Dlatego od samego początku postrzegaliśmy tę migrację jako program zmiany organizacyjnej, wymagający silnego sponsoringu na poziomie zarządczym.
200+
Zmigrowanych Raportów
6
Miesięcy Realizacji
150+
Użytkowników w Organizacji
Projekt był odpowiedzią na strategiczną migrację klienta z Google Workspace do Microsoft 365, wymagającą przeniesienia całego ekosystemu analitycznego.
Mapa Drogowa: 4 Fazy Sukcesu
Dekonstrukcja
Audyt, priorytetyzacja i bezwzględna racjonalizacja istniejących zasobów.
Tłumaczenie
Migracja logiki z LookML do DAX, budowa modeli i integracja źródeł danych.
Odbudowa
Przeprojektowanie wizualizacji i UX zorientowane na realne potrzeby użytkowników.
Wdrożenie
Implementacja governance, dystrybucja przez aplikacje i budowanie adopcji.
Wynik Audytu Zasobów
Wykres pokazuje proporcję zasobów, które zostały zmigrowane, w porównaniu do tych zarchiwizowanych lub usuniętych.
Faza I: Dekonstrukcja monolitu – audyt, planowanie i racjonalizacja
Zgodnie z najlepszymi praktykami, naszym pierwszym krokiem był głęboki audyt istniejącego środowiska. Zamiast polegać na anegdotycznych dowodach, zanurzyliśmy się w twarde dane. Przeanalizowaliśmy logi użytkowania w Lookerze, aby obiektywnie zrozumieć, które raporty są krytyczne dla biznesu, a które stanowią jedynie „szum informacyjny”. Stworzyliśmy kompleksowy inwentarz wszystkich raportów, pulpitów nawigacyjnych, źródeł danych i grup użytkowników. Ta praca u podstaw pozwoliła nam na bezwzględną, opartą na danych priorytetyzację i uniknięcie najczęstszego błędu w projektach migracyjnych: przenoszenia wszystkiego „na wszelki wypadek”.
Sztuka odpuszczania: Racjonalizacja i redukcja długu technicznego
Audyt ujawnił znaczną redundancję i marnotrawstwo. Zidentyfikowaliśmy duplikaty, nieznaczne warianty tych samych analiz oraz raporty nieużywane od ponad sześciu miesięcy. Angażując interesariuszy biznesowych, wspólnie zdecydowaliśmy o archiwizacji lub całkowitym usunięciu blisko 30% dotychczasowych zasobów. To była nasza pierwsza wielka wygrana. Migracja stała się świadomą okazją do posprzątania, uproszczenia i spłatę długu technicznego, zamiast bezmyślnego przenoszenia go do nowego środowiska. Każdy zarchiwizowany raport to zaoszczędzone dziesiątki godzin pracy deweloperskiej.
Inżynieria odwrotna logiki biznesowej
Najtrudniejszym zadaniem była inżynieria odwrotna logiki biznesowej, zaszytej głęboko w modelach LookML. Wiele kluczowych założeń i definicji metryk nie było udokumentowanych poza kodem. Nasz zespół przeprowadził „archeologię danych”, analizując kod LookML i konfrontując go z wiedzą użytkowników biznesowych, aby zrozumieć nie tylko „co” jest liczone, ale przede wszystkim „dlaczego”. Dokumentacja tych „niepisanych zasad” stała się fundamentem dla powodzenia kolejnej fazy, zmuszając organizację do skonfrontowania się z ukrytymi, często niespójnymi definicjami.
Tworzenie mapy drogowej i rejestr audytowy
Zamiast podejścia „big bang”, podzieliliśmy projekt na iteracyjne sprinty, zgrupowane według domen biznesowych (Sprzedaż, Marketing, Finanse). Każda faza kończyła się dostarczeniem działającego zestawu raportów, co pozwalało na wczesne zbieranie informacji zwrotnej i budowanie zaufania. Poniższa tabela przedstawia uproszczony fragment naszego rejestru audytowego, który stał się centralnym narzędziem zarządczym projektu.
| Domena Biznesowa | Nazwa Raportu/Dashboardu | Częstotliwość Użycia (miesięcznie) | Liczba Użytkowników | Krytyczność (1-5) | Priorytet Migracji (1-3) | Decyzja | Komentarz |
|---|---|---|---|---|---|---|---|
| Sprzedaż | Kwartalny Pipeline Sprzedaży | 250 | 45 | 5 | 1 | Przeprojektowanie | Kluczowy raport dla zarządu. Migracja jako okazja do dodania prognoz. |
| Marketing | Skuteczność Kampanii Online | 120 | 15 | 4 | 1 | Migracja 1:1 | Raport dobrze spełnia swoją rolę. Wymaga podłączenia do HubSpot. |
| Finanse | Miesięczne Zestawienie Kosztów | 80 | 10 | 5 | 2 | Przeprojektowanie | Należy zintegrować dane z nowego systemu ERP i uprościć wizualizacje. |
| Operacje | Czas Realizacji Zamówień (wersja A) | 5 | 3 | 2 | 3 | Archiwizacja | Raport zduplikowany. Funkcjonalność pokryta przez "Dashboard Logistyki". |
| Sprzedaż | Aktywność Handlowców (stary) | 0 | 1 | 1 | - | Usunięcie | Nieużywany od 12 miesięcy. Zastąpiony przez nowy dashboard w Hubspot CRM. |
Faza II: Wielkie tłumaczenie – od LookML do Power Platform
Faza tłumaczenia to serce technicznej części migracji. Siłą Lookera jest LookML - potężna, scentralizowana warstwa semantyczna gwarantująca spójność metryk. Naszym celem nie było zniszczenie tej fortecy, ale zbudowanie jej na nowo. Kluczem było konsekwentne wykorzystanie certyfikowanych i promowanych modeli semantycznych w usłudze Power BI. Stworzyliśmy centralne, zoptymalizowane modele dla każdej domeny, które po testach były oznaczane jako „certyfikowane”, stając się nowym, zaufanym źródłem danych - jedno źródło prawdy realizowane w ramach ekosystemu Power BI.
Odpowiedniki koncepcji: Słownik tłumacza
Przetłumaczenie logiki z LookML na DAX i Power Query było największym wyzwaniem. DAX jest potężny, ale ma stromą krzywą uczenia. Power Query okazał się cichym bohaterem, pozwalając przenieść logikę ETL bliżej analityków biznesowych. Najważniejszą zmianą architektoniczną było jednak świadome przesuwanie transformacji „w górę” strumienia - do widoków SQL i Dataflows Gen2 w Fabric. Dzięki temu nasze modele w Power BI pozostały „lekkie” i zoptymalizowane. Poniższa tabela była naszą mapą w tym procesie.
| Koncept w Looker | Odpowiednik w Power BI/Fabric | Kluczowe Różnice | Wskazówka Implementacyjna |
|---|---|---|---|
| Looker Explore | Certyfikowany model semantyczny Power BI | Explore jest zdefiniowany w kodzie (LookML). Model PBI jest budowany w interfejsie graficznym. | Użyj deployment pipelines i wersjonowania plików .pbip w Git, aby naśladować kontrolę wersji z Lookera. |
| LookML Join | Relacje w modelu danych Power BI + transformacje Merge w Power Query | Join w LookML jest realizowany w czasie zapytania. W PBI relacje są zmaterializowane. | Zawsze dąż do budowy czystego modelu gwiazdy. Złożone łączenia przenieś do Power Query/Dataflows. |
| Looker Table Calculation | Miara DAX lub kolumna obliczeniowa | Table Calculations działają na zagregowanych wynikach. Miary DAX działają w kontekście filtra. | To największa pułapka! Zawsze testuj wyniki na różnych poziomach agregacji, aby uniknąć błędów. |
| Persistent Derived Table (PDT) | Zmaterializowany widok w hurtowni danych lub tabela z Dataflow Gen2 | PDT jest zarządzane z Lookera. Dataflow jest częścią platformy Fabric. | Użyj Dataflows Gen2 do tworzenia reużywalnych, pośrednich tabel, promując zasadę DRY. |
Faza III: Odbudowa fasady – wizualizacja i doświadczenie użytkownika
Zamiast ślepo odtwarzać raporty, wykorzystaliśmy migrację jako okazję do ich fundamentalnego ulepszenia. Każdy istotny raport przechodził przez mini-warsztat z użytkownikami, gdzie pytaliśmy: „jakie decyzje biznesowe ten raport ma wspierać?”. Świadomie wykorzystaliśmy elastyczność Power BI w zakresie personalizacji wizualizacji, interaktywności (zakładki, przyciski) i niestandardowych wizualizacji z AppSource, aby tworzyć angażujące narzędzia analityczne. Zaakceptowaliśmy, że nie każdą funkcję da się odtworzyć 1:1, a celem jest większa wartość dla użytkownika, a nie idealna kopia starego systemu. To wymagało aktywnego zarządzania zmianą i szkolenia w zakresie nowych metod pracy.
Faza IV: Wdrożenie – governance, dystrybucja i zdobywanie serc użytkowników
Technicznie udana migracja bez solidnej strategii zarządzania prowadzi do chaosu. Wdrożyliśmy fundamentalną zasadę: oddzielne obszary robocze (workspaces) dla modeli semantycznych i oddzielne dla raportów. Nasze certyfikowane modele semantyczne były publikowane w dedykowanych, ściśle kontrolowanych workspace'ach. Cała dystrybucja treści do setek użytkowników odbywała się poprzez Aplikacje Power BI, które oferowały czysty, brandowany interfejs i możliwość tworzenia różnych grup odbiorców. Paradoksalnie, to właśnie dobrze wdrożony ład danych (governance) zbudował zaufanie do nowego systemu, stając się gwarantem jakości, a nie barierą.
Czynnik ludzki: Jak przekonać organizację do zmiany?
Najlepsza technologia jest bezwartościowa, jeśli ludzie nie chcą z niej korzystać. Kluczem do adopcji było powołanie Centrum Kompetencyjnego (CoE), które działało jako grupa wsparcia i ewangelizacji. Nasze szkolenia były szyte na miarę, zorientowane na role i zadania biznesowe, odpowiadając na pytanie „co ja z tego będę miał?”. Budowaliśmy społeczność użytkowników, wspierając „mistrzów” w działach biznesowych, którzy pomagali swoim kolegom.
Podsumowanie: Czy było warto?
Patrząc wstecz, migracja była nie tylko warta zachodu, ale i konieczna. Największym wyzwaniem było przetłumaczenie całej filozofii zarządzania danymi. Najważniejszą lekcją było to, że migracja to jedyny w swoim rodzaju moment na spłatę długu technicznego i wdrożenie porządku od zera. Korzyści były zarówno wymierne (obniżenie TCO), jak i niewymierne (wzrost adopcji self-service BI, fundamentalne zwiększenie zaufania do danych). Przejście na Fabric otworzyło przed nami nowe horyzonty w analityce czasu rzeczywistego i AI. Jeśli stoisz przed podobnym wyzwaniem, potraktuj migrację nie jako projekt techniczny, ale program transformacji danych. Nie przenoś bałaganu – posprzątaj go.
Najczęściej Zadawane Pytania (FAQ)
Decyzja rzadko wynika z porównania funkcji samych narzędzi. W naszym przypadku była to decyzja strategiczna o unifikacji ekosystemu danych na platformie Microsoft (Azure, Fabric), aby obniżyć całkowity koszt posiadania (TCO) i wykorzystać głębokie, natywne integracje, a nie z powodu abstrakcyjnej wyższości Power BI nad Lookerem.
Zdecydowanie przetłumaczenie logiki biznesowej z LookML na język DAX w Power BI. Prosta kalkulacja w Lookerze często wymagała w DAX złożonej formuły z użyciem funkcji CALCULATE i modyfikatorów kontekstu. Wymagało to głębokiego zrozumienia różnic w filozofii obu języków, zwłaszcza sposobu, w jaki obsługują kontekst filtru i agregacje.
Absolutnie nie. To jeden z najczęstszych i najkosztowniejszych błędów. Dogłębny audyt użycia i bezwzględna racjonalizacja są kluczowe. W naszym przypadku usunęliśmy lub zarchiwizowaliśmy prawie 30% raportów, co zaoszczędziło setki godzin pracy i pozwoliło skupić się na tym, co naprawdę krytyczne dla biznesu.
Zaakceptowaliśmy, że nie da się tego odtworzyć 1:1. Zastosowaliśmy obejścia: tworzenie dedykowanych stron z wizualizacją macierzy, edukację w zakresie eksportu danych do Excela oraz promowanie funkcji "Analizuj w programie Excel". Kluczem było zarządzanie oczekiwaniami i pokazywanie, jak osiągnąć cel innymi, nowymi metodami.
Potraktujcie migrację nie jako projekt IT, ale jako program transformacji organizacyjnej i jedyną w swoim rodzaju szansę na spłatę długu technicznego. Zacznijcie od ludzi, procesów i bezwzględnej racjonalizacji. Nie przenoście bałaganu do nowego domu – posprzątajcie go. To jedyna droga do zbudowania rozwiązania, które przetrwa próbę czasu.
Tak. Dla naszych największych zbiorów danych zaoferował wydajność zbliżoną do trybu Import, ale bez konieczności kopiowania i odświeżania danych. To fundamentalna zmiana, która eliminuje kompromis między wydajnością a aktualnością danych, i jest kluczowym argumentem za strategicznym przejściem na ekosystem Fabric.
Było absolutnie fundamentalne dla sukcesu. Włączenie ich w proces racjonalizacji i przeprojektowywania raportów zmieniło postrzeganie projektu z "przymusowej przeprowadzki" na "okazję do ulepszeń". Zapewniło to, że końcowe produkty odpowiadały na realne potrzeby biznesowe, a nie były tylko techniczną kopią starych rozwiązań.