Czy Twoja firma jest gotowa na Microsoft Fabric? Co powinien wykazać audyt przed startem projektu

Zanim firma wyda pierwszą złotówkę na Microsoft Fabric, warto odpowiedzieć na pytanie, które przesądza o zwrocie z całej inwestycji: czy jest na tę platformę gotowa. Gotowość rozstrzyga się nie w dziale IT, lecz w tym, czy istnieje decyzja, którą platforma ma poprawić, i ktoś, kto weźmie za nią odpowiedzialność.

Audyt gotowości do Microsoft Fabric służy właśnie temu rozstrzygnięciu. Nie ocenia serwerów ani licencji, lecz to, czy projekt ma właściciela, cel i dane, na których da się dowieźć efekt. Ten tekst opisuje, co taki audyt powinien wykazać, zanim ruszy wdrożenie, i dlaczego to on, a nie sama technologia, przesądza o powodzeniu.

‍

Gotowość do Microsoft Fabric to nie gotowość techniczna, lecz decyzyjna

Kiedy pada pytanie o gotowość do nowej platformy danych, większość organizacji odruchowo sprawdza infrastrukturę: wersje systemów, jakość połączeń, dostępność zespołu. To jest jednak najmniej ważna warstwa gotowości, bo Microsoft Fabric obniża barierę techniczną tak mocno, że przestaje ona być wąskim gardłem. Wiążącym ograniczeniem staje się co innego: czy firma wie, którą decyzję chce podejmować lepiej, i czy ktoś poczuwa się do odpowiedzialności za jej efekt. Ta zmiana punktu ciężkości jest dla zarządu najważniejsza, bo przesuwa rozmowę o platformie z języka kosztu IT na język zwrotu z inwestycji.

Dlatego gotowość do Microsoft Fabric jest przede wszystkim gotowością decyzyjną, a nie techniczną. Platforma nie tworzy wartości sama z siebie; tworzy ją dopiero decyzja podjęta szybciej albo trafniej na jej podstawie. Jeśli nie ma takiej decyzji ani jej właściciela, najlepsza platforma świata zamieni się w kolejny system raportujący przeszłość, rozliczany kosztem, a nie efektem. Audyt gotowości sprawdza więc najpierw to, czego nie widać w żadnej specyfikacji technicznej. To także powód, dla którego wynik audytu bywa zaskakujący: firmy o skromnej infrastrukturze często okazują się gotowe, a te z rozbudowanym IT bywają nieprzygotowane.

Ma to konkretną konsekwencję dla tego, kto powinien zlecić i czytać wyniki takiego audytu. To nie jest dokument dla działu IT, lecz materiał decyzyjny dla zarządu, bo rozstrzyga o alokacji kapitału i o tym, kto weźmie odpowiedzialność za zwrot. Punktem wyjścia jest tu audyt przedwdrożeniowy, który zamiast opisywać stan techniczny, odpowiada na pytanie, czy projekt ma szansę się zwrócić i od czego powinien się zacząć. Bez tej odpowiedzi wdrożenie rusza na założeniach, a koszt błędnego założenia rośnie z każdym kolejnym etapem.

‍

Co powinien wykazać audyt gotowości do Microsoft Fabric

Dobry audyt Microsoft Fabric nie kończy się oceną w skali „gotowi lub niegotowi", lecz dostarcza materiału, na którym da się oprzeć decyzję o inwestycji. Bada kilka obszarów, z których każdy odpowiada na inne pytanie decyzyjne, i z których żaden nie jest czysto techniczny. Ich wspólnym celem jest ustalenie nie tego, czy platformę da się uruchomić, lecz czy jej uruchomienie się opłaci i od czego powinno się zacząć. Innymi słowy, audyt zamienia pytanie techniczne w pytanie inwestycyjne, bo to na nie odpowiada zarząd, a nie dział wdrożeniowy. Takie podejście jest bliższe praktyce audytu i zapewnienia opisywanej przez ISACA niż zwykłej ocenie technicznej, i dlatego wynik czyta zarząd.

Kluczowe jest przy tym, żeby audyt patrzył na te obszary łącznie, a nie osobno, bo gotowość jest ich iloczynem, a nie sumą. Firma może mieć znakomite dane i nie mieć właściciela decyzji, albo mieć wyraźny cel i dane rozsiane w sposób uniemożliwiający szybki start. Dopiero zestawienie wszystkich wymiarów pokazuje, czy projekt jest gotowy, a jeśli nie, to który element trzeba domknąć jako pierwszy, zanim w ogóle warto rozmawiać o harmonogramie. Ten iloczynowy charakter gotowości oznacza też, że pojedynczy mocny obszar nie przesądza sprawy, a pojedyncza luka potrafi wstrzymać projekt, dopóki nie zostanie domknięta.

Poniższa tabela zestawia obszary, które audyt gotowości powinien zbadać, z tym, co z każdego z nich wynika dla decyzji o wdrożeniu. Warto czytać ją nie jako listę kontrolną do odhaczenia, lecz jako zestaw pytań, na które zarząd musi znać odpowiedź, zanim zaangażuje budżet. Brak odpowiedzi na którekolwiek z nich jest sam w sobie ważnym wynikiem audytu:

‍

‍

Po czym poznać, że firma jest gotowa

Gotowość do wdrożenia Microsoft Fabric ma kilka sygnałów, które łatwo rozpoznać, jeśli wie się, czego szukać, i które nie mają nic wspólnego z zaawansowaniem technicznym organizacji. Wszystkie sprowadzają się do jednego: czy istnieje konkretna decyzja biznesowa, którą platforma ma poprawić, i otoczenie, w którym da się na niej dowieźć efekt. Firma, która potrafi wskazać taką decyzję i jej właściciela, jest gotowa nawet wtedy, gdy jej dane nie są idealne. Gotowość jest więc cechą sytuacji decyzyjnej, a nie stanu technicznego, i dlatego bywa wyższa w firmie z prostym stosem narzędzi niż w organizacji z rozbudowaną, lecz bezpańską analityką. Ten wniosek bywa dla zarządów zaskakujący, bo odwraca intuicję, że im więcej technologii, tym bliżej do gotowości.

Odwrotna sytuacja jest równie pouczająca. Organizacja o dojrzałej infrastrukturze, ale bez właściciela decyzji i bez jasnego celu, w praktyce nie jest gotowa, choć technicznie mogłaby uruchomić platformę choćby jutro. To dlatego audyt gotowości waży sygnały biznesowe wyżej niż techniczne, a doświadczony wykonawca potrafi je rozpoznać już w pierwszej rozmowie, po tym, jak organizacja opisuje swój cel. Ta umiejętność nie jest wróżeniem, lecz efektem powtarzalności: firmy gotowe mówią o konkretnej decyzji i jej właścicielu, a niegotowe o narzędziach i funkcjach, których potrzebują. To rozróżnienie w języku jest jednym z najszybszych testów gotowości, jakie w ogóle istnieją.

Poniższe sygnały zebrane są w jednym miejscu, żeby dało się je szybko sprawdzić na własnej organizacji jeszcze przed formalnym audytem. Im więcej z nich jest spełnionych, tym większa szansa, że pierwszy przypadek użycia dowiezie efekt w tygodniach, a nie utknie na uzgadnianiu podstaw:

• Jest sponsor z własnym P&L. Ktoś, kto odpowiada za wynik biznesowy, a nie tylko za działanie systemu.
• Znasz jedną decyzję do przyspieszenia. Konkretną i policzalną, a nie „lepszą analitykę w ogóle".
• Dane już istnieją. Pierwszy przypadek użycia da się zbudować na tym, co firma ma dziś.
• Definicje da się uzgodnić. Jest szansa na zgodę co do tego, jak liczyć kluczowe wskaźniki.
• Jest gotowość działać na wynikach. Ktoś zmieni postępowanie, gdy dane coś pokażą.
• Budżet wiąże się z wynikiem. Projekt ma właściciela biznesowego, a nie tylko pozycję w kosztach IT.

‍

Proof of concept: najtańszy sposób, żeby sprawdzić założenia i wycenić projekt

Audyt gotowości odpowiada na pytanie, czy zaczynać, ale najuczciwszą odpowiedź na pytanie, ile to będzie kosztować i czy się uda, daje dopiero proof of concept. Jest to celowo wąski projekt na jednym obszarze i na danych, które firma już ma, którego celem nie jest gotowe rozwiązanie, lecz dowód: że metoda działa, że dane wystarczają i że efekt jest wart dalszej inwestycji. Proof of concept dla Microsoft Fabric zamienia założenia z arkusza w konkretną liczbę opartą na rzeczywistości. Dzięki temu decyzja o dużej inwestycji zapada na dowodzie, a nie na obietnicy, co jest różnicą, którą zarząd odczuwa wprost.

Wartość tego kroku jest przede wszystkim finansowa, bo drastycznie obniża ryzyko dużej decyzji. Zamiast wyceniać cały program na podstawie ogólnych szacunków, firma poznaje faktyczny koszt i czas na małej próbce, przy ograniczonej ekspozycji. Jeśli proof of concept dowiezie efekt, staje się fundamentem i pierwszym elementem docelowej platformy; jeśli nie, jego koszt jest znikomy wobec kosztu programu, który ruszyłby na błędnym założeniu i załamał się w połowie. To jest właśnie sens tego kroku: kupujesz pewność za ułamek ceny programu, zanim zdecydujesz o jego pełnej skali.

Dla dyrektora proof of concept ma jeszcze jedną, mniej oczywistą wartość: jest testem wykonawcy równie ostrym jak testem technologii. Pokazuje, jak dostawca pracuje, jak komunikuje ryzyko i czy dowozi w umówionym czasie, zanim zapadnie decyzja o dużym kontrakcie. Dostawca pewny swoich kompetencji przyjmie taki układ bez oporu, bo widzi w nim okazję, żeby udowodnić wartość. Właśnie dlatego dobrze poprowadzony projekt zaczyna się od audytu i proof of concept, a nie od podpisania wielkiego zakresu z góry.

‍

Ile kosztuje Microsoft Fabric: TCO, cennik pojemności i koszt status quo

Rozmowa o koszcie Microsoft Fabric zwykle zaczyna się i kończy na cenniku licencji, a to najmniej istotna liczba w całym rachunku. Prawdziwy koszt posiadania, czyli TCO Microsoft Fabric, składa się z kilku warstw, z których część jest widoczna na fakturze, a część, często większa, pozostaje ukryta. Zrozumienie tej struktury jest zadaniem audytu, bo bez niej porównuje się cenę platformy z zerem, zamiast z faktycznym kosztem obecnego stanu. Zadaniem audytu jest więc nie tylko wycena platformy, ale i nazwanie tej drugiej, ukrytej liczby, bez której cały rachunek jest niepełny. Niezależne analizy zwrotu, jak te prowadzone przez Nucleus Research, pokazują, że największa wartość projektów danych leży nie w cięciu kosztu narzędzi, lecz w szybszych i trafniejszych decyzjach.

Pierwsza połowa rachunku jest policzalna. Cennik Microsoft Fabric opiera się na modelu pojemności, w jednostkach F-SKU, które można skalować i wstrzymywać, więc wydatek podąża za wykorzystaniem. Do tego dochodzi praca wdrożeniowa oraz utrzymanie, i to one, a nie licencja, są zwykle największą pozycją. Druga połowa rachunku jest jednak niewidoczna: to koszt utrzymywania danych rozproszonych, czyli godziny tracone na uzgadnianie liczb i decyzje podejmowane po omacku, których nikt nie wpisuje do arkusza, bo nie mają jednej faktury. Właśnie dlatego rozmowa o cenniku bez rozmowy o koszcie status quo prowadzi do fałszywego wniosku, że taniej jest nie robić nic.

Poniższa tabela rozkłada TCO na składniki i pokazuje, na co w każdym z nich uważać. Kluczowy wniosek jest taki, że uczciwe porównanie nie brzmi „ile kosztuje Microsoft Fabric", lecz „ile już płacimy za to, że dane siedzą w kilkunastu miejscach". Dla większości dużych firm ta druga liczba, rozbita na czas ludzi i utracone decyzje, przewyższa koszt uporządkowanej platformy:

‍

‍

Kiedy audyt mówi „jeszcze nie" i dlaczego to dobra wiadomość

Nie każdy wynik audytu gotowości brzmi „zaczynajcie". Czasem najuczciwszą i najbardziej wartościową rekomendacją jest „jeszcze nie", bo wskazuje ona element, który trzeba domknąć, zanim inwestycja ma szansę się zwrócić. Taki werdykt oszczędza firmie najdroższego scenariusza, w którym projekt rusza bez fundamentu, pochłania budżet i kończy się jako droższa wersja dotychczasowego raportowania. Rekomendacja wstrzymania nie jest porażką audytu, lecz jego największą wartością. Zarząd, który to rozumie, traktuje ją nie jako stratę pieniędzy na audyt, lecz jako najtańsze ubezpieczenie, jakie mógł kupić. Koszt audytu jest wtedy ułamkiem kosztu projektu, który ruszyłby bez fundamentu i rozsypał się po miesiącach.

Powody, dla których audyt zaleca poczekać, są niemal zawsze biznesowe, a nie techniczne, i prawie zawsze da się je usunąć w rozsądnym czasie. Brakujący właściciel, niedookreślony cel, sporne definicje albo dane wymagające najpierw uporządkowania to problemy do rozwiązania, a nie wyroki. Firma, która pozna je przed startem, wchodzi w projekt z fundamentem; firma, która je zignoruje, odkryje je w trakcie, gdy naprawa jest najdroższa. Warto podkreślić, że wszystkie te powody dotyczą organizacji, a nie technologii, i dlatego leżą w zasięgu decyzji zarządu, a nie możliwości dostawcy. Innymi słowy, gotowość jest w rękach firmy, a audyt jedynie ją ujawnia, zamiast ją tworzyć, dlatego rekomendacja poczekać jest zaproszeniem do domknięcia braków, a nie końcem rozmowy.

Poniżej zebrane są najczęstsze powody, dla których audyt gotowości do wdrożenia Microsoft Fabric kończy się rekomendacją „jeszcze nie". Warto potraktować tę listę jako wczesne ostrzeżenie i sprawdzić ją na własnej organizacji, bo każdy z tych punktów taniej domknąć przed projektem niż w jego trakcie:

• Brak właściciela z P&L. Projekt jest niczyj, więc nikt nie rozliczy go z efektu.
• Brak jednej konkretnej decyzji. Cel opisany jako „chcemy więcej danych" nie da się dowieźć ani zmierzyć.
• Dane wymagają najpierw uporządkowania. Start bez tego przeniesie tylko niespójność do nowej platformy.
• Definicje są sporne. Bez zgody co do znaczenia liczb każdy raport będzie podważał inny.
• Projekt napędza moda na AI. Sztuczna inteligencja jako cel sam w sobie zwykle grzęźnie na jakości danych.
• Nikt nie zamierza zmienić postępowania. Jeśli wynik niczego nie zmieni, platforma nie ma jak się zwrócić.

‍

Dowód: od jednej decyzji do platformy, a nie odwrotnie

Jak wygląda właściwa kolejność w praktyce, pokazuje wdrożenie zrealizowane przez ANEGIS dla CTDI Europe, globalnego dostawcy usług dla telekomunikacji obecnego w kilkudziesięciu lokalizacjach w Europie. Punktem wyjścia nie była decyzja „zbudujmy platformę", lecz konkretny problem biznesowy: rozproszone środowisko analityczne i wiele źródeł danych sprawiały, że raportowanie i prognozowanie sprzedaży były wolne i trudne. To jest dokładnie ten rodzaj wyraźnej potrzeby, którego szuka audyt gotowości.

Na Microsoft Fabric zbudowano centralną platformę, która zintegrowała dane z wielu systemów, zautomatyzowała raportowanie i dołożyła modele uczenia maszynowego do prognozy cen i sprzedaży. Kolejność była właściwa: najpierw obszar o wyraźnym właścicielu i mierzalnym efekcie, czyli prognoza cen i sprzedaży, a dopiero potem rozbudowa fundamentu. Efektem nie był kolejny magazyn danych, lecz szybsza, oparta na danych decyzja i prognoza sterująca wprost działaniem.

Ten przypadek jest praktyczną ilustracją tego, co powinien wykazać dobry audyt gotowości. Zaczyna się nie od pytania „czy chcemy platformy", lecz „którą decyzję chcemy podejmować lepiej i ile jest warta". Firma, która potrafi odpowiedzieć na to pytanie, jest gotowa; firma, która nie potrafi, powinna najpierw znaleźć odpowiedź, a nie kupować technologię. Dla zarządu najważniejsza lekcja brzmi więc: gotowość mierzy się jasnością celu, a nie zaawansowaniem infrastruktury. Ta jedna zasada, postawiona na początku, chroni przed większością kosztownych błędów, które zdarzają się później.

Jeśli zastanawiasz się, czy Twoja firma jest gotowa na Microsoft Fabric i od którego obszaru zacząć, zacznijmy od audytu gotowości i wyceny pierwszego kroku. Krótka rozmowa o tym, którą decyzję chcesz podejmować szybciej i na jakich danych, zwykle wystarcza, żeby wskazać, czy warto już ruszać, i co powinien objąć pierwszy, rozliczalny etap.

‍

‍

‍

‍

‍

‍

‍