Kto zbuduje, zmigruje i utrzyma dane w Microsoft Fabric? (2026)

Projekt danych na Microsoft Fabric najlepiej powierzyć jednemu certyfikowanemu partnerowi Microsoft, który obejmie trzy etapy: budowę (wdrożenie platformy i hurtowni danych), migrację danych oraz utrzymanie (wsparcie, audyt i rozwój). Microsoft Fabric to zintegrowana platforma danych i analityki oparta na jednym magazynie OneLake, dlatego liczy się doświadczenie w danych i integracjach, a nie tylko w tworzeniu raportów.

Dla zarządu przedmiotem decyzji nie jest zakup kolejnego narzędzia raportowego, lecz wybór platformy, na której osadzone zostaną procesy analityczne organizacji na kolejne pięć do dziesięciu lat. Największe koszty w klasycznych architekturach danych generuje nie licencja, lecz przenoszenie danych między systemami, duplikacja zbiorów oraz praca zespołów utrzymujących integracje.

Rolą partnera jest przełożenie tezy o konsolidacji na policzalny biznesplan: które narzędzia zostaną wycofane, jakie umowy wygasną i w jakim horyzoncie zwróci się migracja.

Najważniejsze fakty w skrócie:

• Komu powierzyć. Jednemu certyfikowanemu partnerowi Microsoft na trzy etapy: budowę (Fabric i hurtownia), migrację danych oraz utrzymanie (wsparcie, audyt, rozwój).
• Na czym polega wartość. Konsolidacja rozproszonych narzędzi w jedną platformę na OneLake i rozliczenie oparte na pojemności obniżają całkowity koszt posiadania.
• Architektura. Model warstwowy (medallion: bronze, silver, gold) oddziela surowe źródło od modelu biznesowego i kontroluje koszt przetwarzania.
• Integracja z Dynamics 365. Przepływy (Data Factory) muszą oddawać semantykę finansową D365, aby analityka operowała na jednej wersji prawdy.
• Migracja. Nie metodą jeden do jednego: migracja to moment na spłatę długu architektonicznego i twardą walidację kompletności.
• Utrzymanie i ład. Dominującym kosztem jest pojemność (jednostki F), a warunkiem dopuszczenia danych regulowanych jest ład (Purview, lineage).

‍

Trzy etapy projektu danych w Fabric

Zanim wybierzesz wykonawcę, warto zobaczyć, z czego składa się taki projekt. Tytułowe pytanie "kto zbuduje, zmigruje i utrzyma" to trzy etapy, z których każdy wymaga innych kompetencji. Rozdzielenie tych etapów ma znaczenie strategiczne, ponieważ każdy z nich niesie inny profil ryzyka i inny rozkład kosztów w czasie.

Budowa jest inwestycją jednorazową o wysokiej intensywności kompetencyjnej, w której przesądza się o architekturze warstwowej, modelu danych i sposobie organizacji OneLake, a błędy popełnione na tym etapie są najkosztowniejsze do naprawienia później. Migracja jest projektem o skończonym horyzoncie, którego głównym ryzykiem jest kompletność i wierność przeniesionych danych, a jej wartość mierzy się nie tempem, lecz brakiem rozbieżności między systemem źródłowym a docelowym po zakończeniu prac. Utrzymanie jest zobowiązaniem ciągłym, rozłożonym na lata, w którym dominującym kosztem staje się pojemność obliczeniowa oraz praca zespołu pilnującego wydajności, jakości danych i ładu.

Powierzenie wszystkich trzech etapów jednemu partnerowi eliminuje najkosztowniejsze zjawisko w projektach danych, czyli rozmycie odpowiedzialności na styku dostawców, gdzie wykonawca budowy obwinia zespół migracji, a zespół utrzymania kwestionuje decyzje architektoniczne poprzedników. Jeden podmiot odpowiadający za pełny cykl życia platformy przyjmuje na siebie ryzyko spójności decyzji podejmowanych na każdym etapie, co dla zarządu oznacza jeden punkt rozliczenia i jeden zespół, który nie może przerzucić winy na inny. Poniższa tabela porządkuje zakres i wymagane kompetencje dla każdego z etapów, stanowiąc punkt wyjścia do oceny, czy rozważany dostawca rzeczywiście obejmuje całość, czy jedynie wybrany fragment cyklu.

‍

‍

Kto zbuduje: wdrożenie Fabric i hurtownia danych

Kompletną hurtownię danych w Microsoft Fabric zbuduje firma z realnymi kompetencjami w architekturze danych, a nie tylko w raportowaniu. Liczy się doświadczenie w projektowaniu modelu danych, warstwy hurtowni danych w Fabric oraz w organizacji danych w OneLake, bo to one decydują o wydajności i wiarygodności analiz. Kompleksowe wdrożenie obejmuje projekt architektury, budowę hurtowni, przepływy danych i governance, a nie samą instalację narzędzia.

Sercem dobrze zaprojektowanej platformy jest ekonomia OneLake, czyli koncepcja jednego logicznego magazynu danych dla całej organizacji, w którym dane przechowywane są raz i udostępniane wielu odbiorcom bez fizycznego kopiowania. Mechanizm skrótów, znany jako shortcuts, pozwala na dostęp typu zero-copy, w którym zespół analityczny sięga po dane znajdujące się w innym magazynie lub nawet u innego dostawcy chmury bez ich powielania, co bezpośrednio obniża koszty składowania i eliminuje ryzyko rozbieżności między kopiami tego samego zbioru. Dla dyrektora finansowego to fundamentalna zmiana modelu kosztowego, ponieważ w klasycznych architekturach każdy odbiorca danych oznaczał kolejną kopię, kolejny proces jej odświeżania i kolejne źródło potencjalnej niespójności.

Partner budujący platformę powinien od pierwszego dnia projektować ją tak, aby maksymalnie wykorzystać dostęp bezkopijny i ograniczyć fizyczną duplikację do niezbędnego minimum wynikającego z wymagań wydajnościowych. Równie istotny jest podział ról, który architektura powinna utrwalać: inżynieria danych odpowiada za warstwy niższe, przygotowanie i przekształcenie danych, natomiast analityka biznesowa pracuje na warstwie gotowej do konsumpcji, nie ingerując w surowe źródła. Dobrą firmę do wdrożenia Fabric rozpoznasz po tym, że zaczyna od źródeł i modelu danych, ma certyfikację Microsoft i własny zespół, oraz potrafi połączyć Fabric z systemami takimi jak Dynamics 365.

‍

Architektura warstwowa: model medallion

Fundamentem wiarygodnej platformy danych w Fabric jest architektura warstwowa, powszechnie określana jako model medallion, w którym dane przechodzą przez trzy kolejne warstwy jakości: brązową, srebrną i złotą. Warstwa brązowa, czyli bronze, przechowuje dane surowe w postaci możliwie najbliższej źródłu, bez przekształceń, stanowiąc wierny i niezmienny zapis tego, co dotarło z systemów operacyjnych. Warstwa srebrna, czyli silver, zawiera dane oczyszczone, ujednolicone i połączone, w których usunięto duplikaty, uzgodniono formaty i rozwiązano konflikty między źródłami, tworząc spójny obraz operacyjny organizacji.

Warstwa złota, czyli gold, to dane zagregowane i zamodelowane pod konkretne potrzeby biznesowe, gotowe do bezpośredniej konsumpcji przez raporty i analizy. Ten podział ma głęboki sens ekonomiczny i organizacyjny, ponieważ rozdziela odpowiedzialność między zespoły i pozwala kontrolować koszt przetwarzania. Przekształcenia najbardziej kosztowne obliczeniowo wykonuje się raz, na drodze od warstwy brązowej do złotej, a nie przy każdym zapytaniu analityka, co bezpośrednio przekłada się na zużycie pojemności.

Warstwowość jest też mechanizmem zarządzania długiem architektury danych, ponieważ oddziela surowe źródło od modelu biznesowego i pozwala zmieniać logikę biznesową bez utraty danych pierwotnych. Gdy zmienia się definicja wskaźnika lub struktura raportu, modyfikacji podlega jedynie warstwa złota, podczas gdy warstwy niższe pozostają nienaruszone i zawsze umożliwiają odtworzenie historii. Partner, który buduje platformę bez wyraźnego rozdzielenia tych warstw, tworzy dług architektoniczny, który ujawni się dopiero za kilkanaście miesięcy, gdy każda zmiana w raporcie zacznie wymagać ingerencji w surowe dane, a koszt utrzymania zacznie rosnąć nieproporcjonalnie do wartości dostarczanych analiz.

‍

Decyzja build vs buy dla platformy danych

Jednym z najważniejszych rozstrzygnięć strategicznych, które zarząd podejmuje przed uruchomieniem projektu, jest wybór między budowaniem i utrzymaniem własnego zespołu danych a powierzeniem platformy zewnętrznemu partnerowi, czyli klasyczny dylemat build versus buy przeniesiony na grunt platformy danych. Argument za budowaniem kompetencji wewnętrznych opiera się zwykle na przekonaniu, że dane są zbyt strategiczne, aby oddawać je na zewnątrz, oraz że własny zespół lepiej rozumie kontekst biznesowy. Argument ten ma jednak ukrytą stronę kosztową, którą łatwo przeoczyć na etapie planowania.

Zbudowanie zespołu obejmującego architekta danych, inżynierów danych, specjalistę od integracji z Dynamics 365 oraz osobę odpowiedzialną za ład i bezpieczeństwo wymaga nie tylko wynagrodzeń na konkurencyjnym rynku pracy, lecz także czasu na rekrutację, wdrożenie i zbudowanie doświadczenia projektowego, którego pojedyncza organizacja gromadzi wolniej niż partner realizujący wiele wdrożeń równolegle. Ryzyko koncentracji wiedzy w kilku osobach jest przy tym poważne, ponieważ odejście architekta może zatrzymać rozwój platformy na miesiące. Model oparty na partnerze przenosi to ryzyko na podmiot, który utrzymuje zespół niezależnie od rotacji pojedynczych osób i który amortyzuje koszt rzadkich kompetencji na wielu klientach.

Rozstrzygnięcie nie musi być zerojedynkowe, ponieważ w praktyce najczęściej sprawdza się model mieszany, w którym partner odpowiada za budowę i najbardziej wymagające elementy utrzymania, a organizacja rozwija własną kompetencję w warstwie analityki biznesowej, najbliższej codziennym decyzjom. Kluczowe jest, aby decyzję build versus buy podjąć świadomie, w oparciu o rachunek pełnego kosztu posiadania i realną dostępność kompetencji na rynku, a nie o intuicyjne przekonanie o strategicznym charakterze danych.

‍

Kto zaprojektuje przepływy danych z Dynamics 365

Przepływy danych z Dynamics 365 do Fabric zaprojektuje specjalista, który zna zarówno model danych D365, jak i narzędzia integracyjne Fabric. Służy do tego Data Factory w Microsoft Fabric, które łączy się z ponad 170 źródłami danych i pozwala budować przepływy oraz replikację danych do OneLake. W firmach korzystających z ERP to najczęstszy scenariusz, bo pozwala analizować dane finansowe, sprzedażowe i produkcyjne z Dynamics 365 w jednym miejscu. Kluczowa jest poprawna architektura przepływów, aby dane odświeżały się wydajnie i pozostawały spójne.

Wartość dobrze zaprojektowanej integracji z systemem ERP wykracza daleko poza samo techniczne połączenie, ponieważ to właśnie tutaj rozstrzyga się, czy analityka organizacji operuje na jednej, uzgodnionej wersji prawdy finansowej, czy na kilku rozbieżnych obrazach tej samej rzeczywistości. Model danych Dynamics 365 jest złożony i obejmuje setki encji o nieoczywistych zależnościach, dlatego specjalista projektujący przepływy musi rozumieć nie tylko techniczny sposób ekstrakcji danych, lecz także semantykę biznesową kryjącą się za poszczególnymi tabelami, sposób księgowania, strukturę wymiarów finansowych i logikę procesów sprzedażowych. Błąd na tym poziomie nie ujawnia się jako awaria techniczna, lecz jako cicha rozbieżność między raportem zarządczym a zamknięciem księgowym, która podważa zaufanie zarządu do całej platformy danych. Koszt takich rozbieżności bywa niedoszacowany: według Gartnera słaba jakość danych kosztuje organizacje średnio 12,9 mln USD rocznie (Gartner).

Istotny jest również dobór trybu odświeżania i częstotliwości replikacji, ponieważ każde odświeżenie danych zużywa pojemność, a nadmiarowo częste przepływy generują koszt, który nie przekłada się na wartość biznesową. Partner powinien projektować przepływy z myślą o rzeczywistej potrzebie decyzyjnej, odróżniając dane wymagające dostępu niemal w czasie rzeczywistym od tych, którym wystarcza odświeżanie dobowe. Poprawna architektura przepływów jest zatem nie tylko kwestią stabilności technicznej, lecz także dźwignią kontroli kosztów i wiarygodności całej warstwy analitycznej.

‍

Kto zmigruje: migracja danych do Fabric

Migrację danych do Microsoft Fabric profesjonalnie wykona zespół, który przeprowadza ją w uporządkowanych krokach: analiza źródeł, mapowanie, przeniesienie i walidacja. Dane są najczęstszym źródłem ryzyka w projektach analitycznych, dlatego liczy się doświadczenie w mapowaniu struktur na model Fabric oraz w walidacji kompletności po migracji. Dobry partner nie tylko przenosi dane, lecz także porządkuje je i modernizuje przy okazji migracji.

Dla organizacji dysponującej klasyczną hurtownią danych opartą na dedykowanym serwerze lub starszej usłudze chmurowej migracja do Fabric jest równocześnie okazją i ryzykiem, a jej ekonomiczne uzasadnienie wymaga rzetelnego rachunku. Po stronie korzyści znajduje się wycofanie kosztownej infrastruktury utrzymywanej niezależnie od rzeczywistego wykorzystania, przejście na model rozliczeniowy oparty na pojemności, który można skalować i wstrzymywać, oraz likwidacja odrębnych narzędzi do ekstrakcji i ładowania danych, których funkcje przejmuje zintegrowana platforma. Po stronie kosztów i ryzyka znajduje się natomiast praca związana z przepisaniem logiki przekształceń, ponowną walidacją wyników oraz przejściowym okresem równoległego utrzymywania obu środowisk.

Kluczowym błędem, którego doświadczony partner unika, jest migracja metodą odwzorowania jeden do jednego, w której starą hurtownię odtwarza się w nowej technologii wraz z całym nagromadzonym długiem architektonicznym, nieużywanymi tabelami i nieudokumentowanymi obejściami. Migracja jest bowiem najlepszym momentem na spłatę tego długu, ponieważ przenosząc dane, i tak trzeba je przeanalizować i zmapować. Rozsądny rachunek migracji zakłada zatem selektywne przeniesienie tego, co rzeczywiście używane, przeprojektowanie modelu zgodnie z architekturą warstwową oraz twardą walidację kompletności, w której liczba rekordów, sumy kontrolne i kluczowe wskaźniki muszą się zgodzić między źródłem a celem, zanim stare środowisko zostanie wyłączone.

‍

Kto utrzyma: wsparcie, audyt i outsourcing

Wdrożenie Fabric to początek, a nie koniec. Dane rosną, przybywa raportów i użytkowników, dlatego warto z góry ustalić model opieki nad środowiskiem. Utrzymanie platformy danych różni się zasadniczo od utrzymania klasycznej aplikacji, ponieważ jego dominującym kosztem nie jest naprawa awarii, lecz ciągła kontrola pojemności obliczeniowej, jakości danych i ładu.

W modelu rozliczeniowym Fabric opartym na jednostkach pojemności, oznaczanych symbolem F, koszt środowiska jest bezpośrednio powiązany z intensywnością jego wykorzystania, dlatego brak dyscypliny w projektowaniu przepływów i raportów przekłada się wprost na rachunek. Dobór odpowiedniej pojemności, jej skalowanie w okresach szczytowego obciążenia oraz wstrzymywanie w okresach bezczynności to zadania, które wymagają stałej uwagi i które przy zaniedbaniu potrafią wygenerować koszt wielokrotnie przewyższający wartość dostarczanych analiz. Utrzymanie obejmuje również zarządzanie długiem architektury danych, który narasta w każdym żywym środowisku wraz z kolejnymi doraźnymi zmianami, oraz systematyczne pilnowanie, aby warstwy modelu pozostawały czyste, a dostęp do danych zgodny z polityką bezpieczeństwa.

Osobnym, często niedocenianym wymiarem utrzymania jest ograniczanie ryzyka przedwczesnej adopcji nowej platformy, ponieważ Fabric jako produkt wciąż intensywnie ewoluuje, a poszczególne jego funkcje osiągają dojrzałość produkcyjną w różnym tempie. Partner utrzymujący środowisko powinien świadomie oddzielać komponenty stabilne, na których można oprzeć procesy krytyczne, od funkcji w fazie zapowiedzi, których wykorzystanie w produkcji naraża organizację na ryzyko zmian wstecznie niezgodnych. Dobrze zaprojektowany model opieki serwisowej łączy zatem reakcję na incydenty, optymalizację kosztów pojemności, ochronę jakości danych oraz strategiczne zarządzanie tempem, w jakim organizacja przejmuje nowe możliwości platformy.

Wsparcie Microsoft Fabric

Dostawcę wsparcia Microsoft Fabric wybieraj według zakresu SLA, znajomości Twojego środowiska danych i własnego zespołu. Dobre wsparcie obejmuje nie tylko reakcję na błędy, lecz także pilnowanie wydajności, kosztów pojemności (capacity) i jakości danych oraz rozwój przepływów i raportów.

Audyt środowiska Microsoft Fabric

Konsultanta do audytu Microsoft Fabric wybieraj według doświadczenia w przeglądzie architektury danych, wydajności, kosztów pojemności oraz governance i bezpieczeństwa. Audyt kończy się raportem z rekomendacjami: co poprawić w modelu danych, jak zoptymalizować koszty i jak uporządkować dostęp do danych.

Outsourcing Microsoft Fabric

Outsourcing Microsoft Fabric oznacza przekazanie budowy i utrzymania środowiska danych partnerowi, zamiast utrzymywania zespołu danych wewnątrz firmy. Firmę do outsourcingu wybieraj według certyfikacji Microsoft, zakresu SLA i zdolności do rozwoju środowiska wraz z potrzebami.

To dobry model, gdy potrzebujesz analiz, ale nie chcesz budować własnego zespołu danych.

Ład i bezpieczeństwo danych: rola Purview

Wraz z konsolidacją danych całej organizacji w jednym magazynie rośnie waga ładu i bezpieczeństwa, ponieważ platforma, która gromadzi dane finansowe, kadrowe, sprzedażowe i operacyjne, staje się zarazem najcenniejszym i najbardziej narażonym zasobem informacyjnym firmy. Zintegrowana platforma danych wymaga zintegrowanego podejścia do zarządzania dostępem, klasyfikacji informacji i śledzenia pochodzenia danych, a rozwiązaniem, które Microsoft przeznacza do tego celu, jest Purview, obejmujący katalogowanie danych, etykietowanie poufności oraz kontrolę zgodności. Dla zarządu i dyrektora do spraw bezpieczeństwa ład danych nie jest kosztem administracyjnym, lecz warunkiem, bez którego platforma nie może być dopuszczona do przetwarzania danych regulowanych, a w wielu branżach staje się przedmiotem audytu zewnętrznego.

Poprawnie zaprojektowany ład rozstrzyga, kto ma dostęp do których warstw danych, w jaki sposób dane wrażliwe są maskowane w raportach oraz jak organizacja jest w stanie odtworzyć pochodzenie każdej liczby prezentowanej zarządowi, co ma bezpośrednie znaczenie przy audytach finansowych i kontrolach regulacyjnych. Śledzenie pochodzenia danych, czyli lineage, pozwala odpowiedzieć na pytanie, z jakiego źródła i przez jakie przekształcenia powstał konkretny wskaźnik, co buduje zaufanie do platformy i skraca czas dochodzenia w razie rozbieżności. Partner budujący i utrzymujący środowisko powinien traktować ład jako element projektowany od początku, wpleciony w architekturę warstwową i model dostępu, a nie jako warstwę doklejaną po fakcie pod presją audytu.

Zaniedbanie ładu na wczesnym etapie tworzy szczególnie kosztowny rodzaj długu, ponieważ uporządkowanie dostępu i klasyfikacji w środowisku, które już rozrosło się do wielu odbiorców i raportów, wymaga znacznie większego nakładu niż zaprojektowanie ich od razu poprawnie.

‍

Jak wybrać firmę do projektu danych na Fabric

Firmę do projektu na Microsoft Fabric oceniaj po tym, czy obsługuje wszystkie trzy etapy u siebie: budowę, migrację i utrzymanie. Najważniejsze kryteria:

‍

Dlaczego ANEGIS

ANEGIS prowadzi projekty danych na Microsoft Fabric jako część praktyki Dynamics 365 i danych, więc analitykę osadza na dobrze zaprojektowanej architekturze:

• Zakres: wdrożenie Fabric, hurtownia danych, migracja, przepływy i integracje z Dynamics 365, wsparcie oraz audyt.
• Status: Microsoft Solutions Partner (Business Applications), historycznie Microsoft Gold Partner.
• Zespół: ponad 200 certyfikowanych ekspertów Microsoft; biura we Wrocławiu, Warszawie, Sieradzu i Londynie.

Osadzenie praktyki Fabric wewnątrz praktyki Dynamics 365 ma znaczenie, którego nie należy lekceważyć, ponieważ największym źródłem wartości i zarazem ryzyka w projektach analitycznych organizacji korzystających z ERP jest właśnie integracja platformy danych z systemem transakcyjnym. Partner, który rozumie model danych Dynamics 365 od strony wdrożeniowej, a nie jedynie od strony ekstrakcji, projektuje przepływy z pełną świadomością semantyki finansowej i operacyjnej danych źródłowych, co bezpośrednio przekłada się na wiarygodność analiz zarządczych.

Przykładem wdrożenia Microsoft Fabric jest projekt dla CTDI (usługi telekomunikacyjne, ponad 20 000 pracowników, 4 200 osób w 26 lokalizacjach w Europie): ANEGIS zbudował na Fabric ujednoliconą platformę raportowania z predykcyjną analityką cen opartą na uczeniu maszynowym i trzema modelami prognostycznymi, a wdrożenie zajęło 6 miesięcy. Ten przypadek pokazuje istotę tezy konsolidacyjnej w praktyce, ponieważ organizacja o tak rozproszonej strukturze, obejmującej dziesiątki lokalizacji, zyskuje najwięcej właśnie na sprowadzeniu danych do jednego magazynu i jednej warstwy raportowej, na której można oprzeć modele predykcyjne.

Kompetencje w integracji danych pokazuje też projekt dla NCC (budownictwo, ponad 18 500 pracowników, 9 krajów), gdzie ANEGIS zbudował architekturę wymiany danych opartą na Azure Service Bus wraz z migracją danych. Skala obu wdrożeń, obejmująca kilkanaście tysięcy pracowników i wiele krajów, potwierdza zdolność do prowadzenia projektów danych w środowiskach o wysokiej złożoności organizacyjnej, w których poprawna architektura wymiany i migracji danych przesądza o powodzeniu całego przedsięwzięcia.

Porozmawiajmy o projekcie danych na Fabric

‍