Firma wdrażająca Microsoft Fabric: sześć kryteriów, które odróżniają wykonawcę wdrożenia od sprzedawcy licencji
Firma wdrażająca Microsoft Fabric i sprzedawca licencji Microsoft potrafią wyglądać na rynku identycznie: ten sam status partnera, ta sama prezentacja, ta sama obietnica nowoczesnej platformy danych. Różnica ujawnia się dopiero wtedy, gdy projekt trzeba faktycznie dowieźć, a wtedy jest już po podpisaniu umowy i po przelewie.
Dla zarządu, który wybiera firmę do wdrożenia Microsoft Fabric, to nie jest niuans proceduralny, lecz decyzja przesądzająca o tym, czy platforma zacznie zwracać się w miesiącach, czy zamieni się w kolejny porzucony projekt IT. Ten tekst opisuje sześć kryteriów, które pozwalają oddzielić wykonawcę wdrożenia od sprzedawcy dostępu, zanim koszt pomyłki stanie się nieodwracalny.
Dlaczego „partner Microsoft Fabric" to dziś najbardziej mylące słowo w projekcie danych
Słowo „partner" w ekosystemie Microsoftu obejmuje dwie zupełnie różne firmy, które łączy jedynie ten sam logotyp w stopce. Pierwsza odsprzedaje licencje i pojemność chmury, a jej model zarabiania opiera się na marży od transakcji; sukcesem jest dla niej podpisana umowa, a nie działająca hurtownia. Druga projektuje i buduje platformę danych, a jej przychód zależy od tego, czy wdrożenie faktycznie ruszy i przyniesie efekt. Obie mają prawo nazywać się partnerem Microsoft Fabric i obie z tego prawa korzystają.
To rozróżnienie ma znaczenie finansowe, ponieważ oba modele optymalizują co innego. Sprzedawca licencji jest wynagradzany za wolumen i tempo sprzedaży, więc jego naturalnym interesem jest zamknąć transakcję szybko i przejść do następnej; głębokie zaangażowanie we wdrożenie obniża jego marżę. Wykonawca wdrożenia jest rozliczany z dostarczonego zakresu i utrzymania, więc jego interes jest zbieżny z Twoim: platforma ma zadziałać, bo inaczej on nie zarobi. Ta zbieżność albo jej brak waży w projekcie więcej niż każda deklaracja w prezentacji. Dlatego dobry partner do wdrożenia Microsoft Fabric wiąże swój przychód z Twoim wynikiem, a nie z liczbą sprzedanych licencji.
W polskich realiach rynek dodatkowo zaciera tę granicę, bo wielu dostawców chmury i resellerów dopisało Microsoft Fabric do katalogu, nie budując zespołu inżynierii danych. Dla organizacji, które rozważają outsourcing wdrożenia Microsoft Fabric, pytanie nie brzmi więc „czy zlecić na zewnątrz", lecz „komu", bo to od charakteru dostawcy, a nie od samej decyzji o outsourcingu, zależy wynik. Koszt pomyłki jest wymierny: porzucona platforma to nie tylko utopiony budżet licencji, ale też miesiące zwłoki, nadszarpnięta wiarygodność projektu w organizacji i konieczność powtórzenia całego postępowania od nowa.
Sześć kryteriów, które oddzielają wykonawcę wdrożenia od sprzedawcy licencji
Kryteria pozwalające odróżnić wykonawcę od sprzedawcy nie są listą certyfikatów do odhaczenia, lecz zestawem pytań o to, na czym dostawca faktycznie zarabia i co dzieje się, gdy projekt napotyka trudność. Certyfikat partnerski potwierdza status handlowy, a nie zdolność dowiezienia platformy danych; jedno i drugie bywa mylone i właśnie na tym pomyleniu opiera się część rynku. Dlatego poniższe sześć kryteriów patrzy nie na to, co dostawca deklaruje, lecz na to, jak jest zbudowany i rozliczany. Innymi słowy, patrzymy na strukturę i model przychodu firmy, a nie na jej materiały marketingowe.
Każde z tych kryteriów da się sprawdzić przed podpisaniem umowy, o ile zadamy właściwe pytanie i nie zadowolimy się ogólną odpowiedzią. Różnica między firmą wdrażającą Microsoft Fabric a sprzedawcą licencji ujawnia się najszybciej tam, gdzie kończy się prezentacja, a zaczyna konkret: skład zespołu, plan migracji, model utrzymania i sposób wyceny. W każdym z tych miejsc integrator danych mówi konkretami, a sprzedawca ucieka w ogólniki o „dostępie do ekspertów" i „elastycznej współpracy". Status partnera Microsoft potwierdza przy tym jedynie relację handlową z producentem, a nie liczbę dowiezionych wdrożeń, a to dwie różne rzeczy, które łatwo pomylić. Firma do wdrożenia Microsoft Fabric warta zaufania udowodni tę drugą portfelem projektów, a nie samym logo w programie partnerskim.
Poniższa tabela zestawia oba profile w sześciu wymiarach, które w praktyce przesądzają o powodzeniu projektu. Warto czytać ją nie jako opis dwóch typów firm, lecz jako sześć testów do przeprowadzenia na każdym oferencie z osobna, bo zdarza się, że dostawca wypada wiarygodnie w jednym wymiarze, a odpada w innym. Wynik tego zestawienia bywa bardziej jednoznaczny niż wrażenie z rozmowy handlowej:
Kryterium, które waży najwięcej: inżynieria danych, nie kolejny raport
Gdyby sześć kryteriów trzeba było zredukować do jednego, brzmiałoby ono: kto w tym zespole projektuje przepływ danych, a nie tylko rysuje raport. Warstwa raportowa w Power BI jest widoczna, efektowna i stosunkowo łatwa do pokazania na demie, dlatego sprzedawcy koncentrują na niej całą prezentację. Prawdziwa trudność wdrożenia Microsoft Fabric leży jednak piętro niżej, w inżynierii danych: w projektowaniu potoków, modelu lakehouse, migracji z istniejących hurtowni i w tym, żeby platforma działała wydajnie i przewidywalnie kosztowo pod obciążeniem.
To rozróżnienie ma bezpośrednie przełożenie na ryzyko projektu. Raport da się poprawić w tydzień; źle zaprojektowany model danych albo nieudana migracja potrafią zatrzymać cały program na kwartały i pochłonąć budżet wielokrotnie większy niż licencje. Dlatego od firmy do wdrożenia Microsoft Fabric należy wymagać imiennych inżynierów danych z certyfikatami Microsoftu, przypisanych do projektu, a nie ogólnej deklaracji o „zespole ekspertów". Konkretne kompetencje, poparte opisem zrealizowanych migracji, są najlepszym dostępnym przed startem prognostykiem powodzenia. Dostawca, który nie potrafi wskazać takich osób z imienia, w praktyce zamierza je dopiero znaleźć albo podnająć, a to ryzyko przechodzi w całości na Twój projekt.
Pomocnym punktem odniesienia jest tu mapa wdrożenia Microsoft Fabric opublikowana przez Microsoft, która pokazuje, że dojrzałe wdrożenie to program obejmujący ład, kompetencje i własność danych, a nie jednorazowa instalacja narzędzia. Dostawca, który rozumie tę mapę, rozmawia o etapach, rolach i punktach kontrolnych; dostawca, który jej nie zna, rozmawia wyłącznie o funkcjach produktu. Ta sama różnica widać w tym, jak oferent podchodzi do integracji i danych: czy traktuje ją jako rdzeń projektu, czy jako dodatek do sprzedaży licencji.
Co się dzieje po starcie: managed services i model pojemności
Moment odbioru wdrożenia to nie koniec projektu, lecz początek życia platformy, i właśnie tutaj różnica między wykonawcą a sprzedawcą staje się najbardziej kosztowna. Microsoft Fabric rozlicza się w modelu pojemności, w jednostkach mocy obliczeniowej opisanych jako F-SKU, które można powiększać, zmniejszać i wstrzymywać. Ten model daje elastyczność, ale ma drugą stronę: pozostawiona bez nadzoru pojemność potrafi po cichu generować koszt znacznie wyższy, niż wynika z faktycznego zapotrzebowania, bo nikt nie wyłącza tego, czego akurat nie widać. Ten koszt nie znika sam z siebie, lecz rośnie po cichu dokładnie dlatego, że nie ma jednej osoby rozliczanej z jego kontroli.
Tu wkracza pojęcie, które sprzedawca licencji pomija, a integrator traktuje jako część oferty: managed services dla Microsoft Fabric, czyli utrzymanie, monitoring i optymalizacja kosztu pojemności po starcie. Dobry wykonawca prowadzi platformę jak usługę: pilnuje wydajności, dostosowuje F-SKU do rzeczywistego obciążenia i rozwija kolejne przypadki użycia w rytmie, w jakim zwracają się poprzednie. Konsulting Microsoft Fabric nie kończy się więc na uruchomieniu, lecz przechodzi w ciągłą opiekę, w której koszt jest aktywnie zarządzany, a nie tylko fakturowany.
Dla zarządu ma to wymiar wprost finansowy, który łatwo zestawić z cennikiem pojemności Microsoft Fabric. Pytanie kontrolne brzmi: kto po starcie odpowiada za to, żeby firma nie płaciła za nieużywaną moc, i czy ta odpowiedzialność jest zapisana w umowie jako mierzalny poziom usługi. Sprzedawca licencji nie ma na to odpowiedzi, bo jego rola kończy się na dostarczeniu dostępu; wykonawca wdrożenia odpowiada konkretem, bo utrzymanie jest częścią jego modelu przychodu, a nie uprzejmością po fakcie. Pytanie o właściciela kosztu pojemności po starcie jest jednym z najważniejszych, jakie warto zadać przed umową.
Ład danych, bezpieczeństwo i zgodność jako warunek, nie dodatek
Ład danych, bezpieczeństwo i zgodność to obszar, w którym sprzedawca licencji i wykonawca wdrożenia rozchodzą się najdalej, bo jeden traktuje go jako koszt do pominięcia, a drugi jako warunek działania platformy. Governance nie jest ozdobą projektu danych; to warstwa, bez której decydenci przestają ufać liczbom, a platforma, której nikt nie ufa, jest bezużyteczna niezależnie od mocy obliczeniowej. Pochodzenie danych, uprawnienia, klasyfikacja informacji wrażliwych i zgodność z RODO muszą być zaprojektowane od pierwszego dnia, a nie doklejone projektem na końcu.
W środowisku regulowanym i przy rosnącym użyciu AI ta warstwa przestaje być komfortem, a staje się wymogiem, który trzeba udowodnić audytorowi i własnemu zarządowi. Dostawca poważnie traktujący dane wpisuje w ofertę konkretne mechanizmy i odwołuje się do uznanych norm, takich jak ISO/IEC 27001 dla bezpieczeństwa informacji; dostawca sprzedający dostęp milczy o tym albo odsyła do „możliwości platformy". Ta różnica jest jednym z najszybszych testów: zapytaj, jak oferent zapewni ślad pochodzenia każdej liczby, a usłyszysz, z kim rozmawiasz. Poważny wykonawca potrafi też wyjaśnić, jak rozdziela dostęp do danych wrażliwych i jak wykazuje zgodność wobec audytora, bo robił to już w projektach objętych regulacją; sprzedawca licencji traktuje ten temat jako cudzy problem, co samo w sobie jest odpowiedzią.
Poniższe sygnały ostrzegawcze zbierają w jednym miejscu zachowania, które w praktyce zdradzają sprzedawcę licencji podszywającego się pod wykonawcę wdrożenia. Żaden z nich nie przesądza sprawy w pojedynkę, ale ich nagromadzenie jest wiarygodnym ostrzeżeniem, że rozmowa dotyczy transakcji, a nie projektu. Warto mieć tę listę przy sobie podczas pierwszych spotkań, bo najłatwiej wychwycić te sygnały właśnie wtedy, zanim zaangażowanie w proces utrudni wycofanie się:
• Rozmowa zaczyna się od licencji, nie od problemu. Oferent pyta o liczbę użytkowników i pojemność, zanim zapyta, którą decyzję chcesz podejmować szybciej.
• Brak imiennego zespołu inżynierów danych. Prezentacja mówi o „dostępie do ekspertów", ale nikt konkretny nie jest przypisany do projektu.
• Demo to gotowy pulpit, nie architektura. Pokaz koncentruje się na wyglądzie raportu, a nie na tym, skąd i jak popłyną dane.
• Migracja pojawia się jako „szczegół techniczny". Zejście z obecnego środowiska jest zbywane jednym zdaniem, bez planu i bez wyceny.
• Oferta milczy o utrzymaniu. Nie ma słowa o tym, kto prowadzi platformę po starcie ani jak kontrolowany jest koszt pojemności.
• Jedna cena za wszystko. Koszt licencji i koszt pracy są zlane w jedną liczbę, więc nie widać, ile z niej to faktyczne wdrożenie.
Jak napisać zapytanie ofertowe (RFP), które odsieje sprzedawców
Najskuteczniejszym narzędziem oddzielającym wykonawców od sprzedawców jest dobrze napisane zapytanie ofertowe, bo zmusza oferenta do konkretu tam, gdzie prezentacja pozwala na ogólniki. Wiele organizacji szuka gotowego wzoru RFP na hurtownię danych i kopiuje formularz skupiony na funkcjach produktu, a to właśnie błąd, który gra na korzyść sprzedawcy: pytania o funkcje platformy Microsoft Fabric wypełni tak samo dobrze każdy, kto ma do niej dostęp. Wartość zapytania bierze się z pytań o zespół, metodę, migrację, utrzymanie i model wyceny, bo na te sprzedawca licencji nie ma dobrej odpowiedzi.
Dobrze skonstruowane zapytanie ofertowe przenosi więc ciężar z opisu narzędzia na dowód zdolności wykonawczej. Zamiast pytać, czy platforma obsługuje dany format danych, pyta, kto imiennie poprowadzi migrację i z jakiego środowiska już ją przeprowadzał. Zamiast prosić o listę funkcji, prosi o rozbicie wyceny na licencje i pracę wdrożeniową, bo dopiero to ujawnia, ile dostawca faktycznie zamierza wykonać. Taki dokument działa jak filtr: oferenci nastawieni na sprzedaż dostępu albo odpadają sami, albo ujawniają się w jakości odpowiedzi. Im bardziej zapytanie wymaga konkretu, tym trudniej odpowiedzieć na nie samą deklaracją gotowości do współpracy.
Poniższa tabela zbiera elementy, które warto umieścić w zapytaniu ofertowym na wdrożenie Microsoft Fabric, wraz z tym, czego wymagać i dlaczego dany punkt odsiewa sprzedawcę licencji. Można ją potraktować jako szkielet wzoru RFP, uzupełniony o specyfikę Twojej organizacji, na przykład o wymogi branżowe albo istniejące środowisko do migracji. Kolejność punktów nie jest przypadkowa: zaczyna się od dowodu doświadczenia, a kończy na modelu wyceny, bo to właśnie sposób rozliczenia najczęściej zdradza, z kim mamy do czynienia:
Due diligence, czyli jak sprawdzić firmę do wdrożenia Microsoft Fabric przed umową
Nawet najlepsze zapytanie ofertowe nie zastąpi kilku prostych ruchów, które można wykonać samodzielnie i które w praktyce mówią o dostawcy więcej niż formalna oferta. Due diligence przy wyborze firmy do wdrożenia Microsoft Fabric nie musi być długim procesem; wystarczy kilka celnych testów sprawdzających nie deklaracje, lecz zachowanie. Kluczem jest przeniesienie rozmowy z poziomu handlowego na poziom wykonawczy, bo dopiero tam widać, czy za ofertą stoi zespół zdolny dowieźć platformę. Właśnie dlatego rozmowa techniczna waży w tym wyborze więcej niż referencje na papierze.
Najważniejszy z tych ruchów to zacząć od małego, rozliczalnego zakresu, zanim podpisze się duży kontrakt. Audyt przedwdrożeniowy i jeden dobrze wybrany przypadek użycia są najtańszym i najuczciwszym testem wykonawcy: pokazują, jak pracuje, jak komunikuje ryzyko i czy dowozi w umówionym czasie, przy ograniczonej ekspozycji finansowej. Dostawca pewny swoich kompetencji przyjmie taki układ bez oporu; sprzedawca licencji będzie naciskał na duży kontrakt od razu, bo w małym, rozliczanym z efektu zakresie nie ma dla niego marży. Ta asymetria jest sama w sobie testem: reakcja dostawcy na propozycję małego startu mówi o jego modelu więcej niż cała prezentacja. Wykonawca widzi w takim zakresie okazję, by pokazać, jak pracuje, a sprzedawca widzi stratę czasu, bo jego przychód nie zależy od jakości dostawy, tylko od wielkości zamówienia.
Poniższe ruchy warto wykonać jeszcze przed wyborem, niezależnie od tego, ilu oferentów bierze udział w postępowaniu. Każdy z nich jest tani, szybki i trudny do obejścia pustą deklaracją, bo wymaga od dostawcy pokazania konkretu, a nie opowiedzenia o sobie. Razem tworzą krótką listę kontrolną, która w większości przypadków wystarcza, by oddzielić wykonawcę wdrożenia od sprzedawcy dostępu:
• Poproś o rozmowę z inżynierem, nie z handlowcem. Kompetencja techniczna zespołu ujawnia się w pięć minut właściwej rozmowy.
• Zażądaj opisu jednej zrealizowanej migracji. Konkret, z jakiego środowiska, w jakim czasie i z jakim ryzykiem, mówi więcej niż logo klienta na slajdzie.
• Rozdziel w wycenie licencje od pracy. Dopiero rozbita oferta pokazuje, za co faktycznie płacisz.
• Zapytaj o model utrzymania i optymalizacji pojemności. Odpowiedź odróżnia partnera od dostawcy dostępu.
• Zacznij od audytu gotowości i jednego przypadku użycia. Mały, rozliczalny zakres jest najlepszym testem wykonawcy przed dużym kontraktem.
Dowód: wdrożenie, które zaczęło się od problemu, nie od licencji
Jak ta różnica wygląda w praktyce, dobrze 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 sprzedaż licencji, lecz 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 właśnie sytuacja, w której sprzedawca dostępu dostarczyłby narzędzie i wycofał się, zostawiając trudną część po stronie klienta.
Wykonawca zadziałał inaczej. Na Microsoft Fabric ANEGIS zbudował 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. Efektem nie był kolejny pulpit, lecz szybsza, oparta na danych decyzja i prognoza sterująca wprost działaniem. Widać tu wszystkie sześć kryteriów naraz: inżynierię danych, metodę, integrację jako rdzeń, a nie dodatek, oraz zakotwiczenie w konkretnym problemie biznesowym, a nie w katalogu funkcji.
Ten przypadek jest też dowodem na tezę o kolejności. Zaczęto od obszaru o wyraźnym właścicielu i mierzalnym efekcie, czyli od prognozy cen i sprzedaży, a nie od budowy kompletnej hurtowni na zapas. Dopiero z tego zwrotu rozbudowuje się fundament danych, co jest dokładnie tym, czego sprzedawca licencji nie zaproponuje, bo jego model nie przewiduje towarzyszenia klientowi po transakcji. Dla organizacji wybierającej dziś dostawcę najważniejsza lekcja z tego wdrożenia brzmi: pytaj nie o to, co dostawca sprzeda, lecz co i w jakim czasie faktycznie zbuduje oraz utrzyma.
Jeśli wybierasz dziś firmę do wdrożenia Microsoft Fabric i chcesz mieć pewność, że rozmawiasz z wykonawcą, a nie ze sprzedawcą dostępu, porozmawiajmy o zakresie pierwszego, rozliczalnego kroku. Krótka rozmowa o tym, którą decyzję chcesz podejmować szybciej i z jakiego środowiska trzeba przenieść dane, zwykle wystarcza, żeby wskazać właściwy punkt startu i oszacować przewidywany zakres prac.
FAQs
Czym różni się firma wdrażająca Microsoft Fabric od sprzedawcy licencji?
Sprzedawca licencji zarabia na marży od odsprzedanej pojemności i dostępu do platformy, więc jego zaangażowanie kończy się na podpisaniu umowy i uruchomieniu środowiska. Firma wdrażająca Microsoft Fabric zarabia na dowiezionym efekcie: zaprojektowaniu przepływu danych, migracji z istniejących systemów, zbudowaniu modelu i utrzymaniu platformy po starcie.
Praktyczna różnica jest taka, że sprzedawca dostarcza narzędzie, a wykonawca dostarcza działającą platformę i odpowiedzialność za jej efekt. Najszybciej rozpoznasz jedno i drugie po tym, od czego zaczyna się rozmowa: sprzedawca pyta o liczbę użytkowników i pojemność, wykonawca pyta o problem biznesowy i decyzję, którą chcesz podejmować szybciej. Ta pozornie drobna różnica przekłada się wprost na to, czy platforma zacznie się zwracać, czy trafi do kategorii porzuconych projektów. Warto też pamiętać, że jedna firma potrafi pełnić obie role w różnych projektach, dlatego liczy się nie etykieta, lecz to, jak dostawca zachowuje się w Twoim konkretnym przypadku i za co bierze odpowiedzialność w umowie. Odpowiedzialność zapisana w umowie jest tu ważniejsza niż deklaracja złożona na spotkaniu.
Jak wybrać firmę do wdrożenia Microsoft Fabric?
Zacznij od sprawdzenia sześciu wymiarów: na czym dostawca zarabia, jakie ma kompetencje inżynierii danych, czy ma udokumentowaną metodykę i plan migracji, jak podchodzi do ładu i bezpieczeństwa, co oferuje po starcie oraz czy rozumie Twój model biznesowy. Każdy z nich da się zweryfikować przed umową właściwym pytaniem.
Najskuteczniejszym testem jest jednak zaczęcie od małego, rozliczalnego zakresu, na przykład od audytu gotowości i jednego przypadku użycia, zamiast od dużego kontraktu. Taki układ przy ograniczonej ekspozycji finansowej pokazuje, jak dostawca faktycznie pracuje, jak komunikuje ryzyko i czy dowozi w umówionym czasie. Poproś też o rozmowę z inżynierem, a nie tylko z handlowcem, oraz o rozbicie wyceny na licencje i pracę wdrożeniową, bo dopiero to ujawnia, ile z oferty to faktyczne wdrożenie. Na koniec sprawdź, czy dostawca zgadza się rozpocząć od ograniczonego zakresu rozliczanego z efektu, bo gotowość do takiego układu jest jednym z najpewniejszych sygnałów, że masz do czynienia z wykonawcą, a nie ze sprzedawcą dostępu.
Czy warto zlecić wdrożenie Microsoft Fabric w modelu outsourcingu?
Dla większości organizacji tak, bo zbudowanie i utrzymanie własnego zespołu inżynierii danych jest kosztowne i trudne w rekrutacji, a wdrożenie ma charakter projektowy, po którym zapotrzebowanie na te kompetencje spada. Pytanie nie brzmi więc „czy zlecić na zewnątrz", lecz „komu zlecić", bo od charakteru dostawcy zależy wynik.
Kluczowe jest odróżnienie dostawcy, który w modelu outsourcingu faktycznie prowadzi platformę, od takiego, który jedynie odsprzedaje dostęp i wycofuje się po uruchomieniu. Dobry partner w tym modelu bierze odpowiedzialność za utrzymanie, monitoring i optymalizację kosztu pojemności, a nie tylko za jednorazowe wdrożenie. Więcej o tym, kto powinien budować, migrować i utrzymywać dane w Fabric, piszemy w osobnym opracowaniu poświęconym temu, komu powierzyć ten zakres. Dobrym testem jest zapytanie, kto po uruchomieniu odpowiada za koszt pojemności i rozwój kolejnych przypadków użycia; wykonawca ma na to gotową odpowiedź w postaci warunków utrzymania, a sprzedawca odsyła do możliwości platformy, i to rozróżnienie decyduje, czy outsourcing przyniesie oszczędność, czy tylko przeniesie problem na zewnątrz.
Co powinno znaleźć się w zapytaniu ofertowym (RFP) na wdrożenie Microsoft Fabric?
Dobry wzór RFP na hurtownię danych w Microsoft Fabric nie skupia się na funkcjach produktu, bo te wypełni każdy dostawca mający dostęp do platformy. Skupia się na dowodzie zdolności wykonawczej: referencjach z opisem zakresu i efektu, imiennym składzie zespołu z certyfikatami, metodyce dostawy i planie migracji z obecnego środowiska.
Powinien też wymagać opisu modelu ładu i bezpieczeństwa, warunków utrzymania po starcie wraz z poziomami usługi oraz, co najważniejsze, rozdzielenia wyceny na koszt licencji i pojemności oraz koszt pracy wdrożeniowej. To właśnie rozbita wycena najszybciej odsłania, ile dostawca zamierza faktycznie wykonać, a ile jedynie odsprzedać. Tak skonstruowane zapytanie działa jak filtr, który sprzedawcy dostępu odsiewa samą swoją strukturą, jeszcze zanim porównasz oferty. Dobrze jest też poprosić o wskazanie głównych ryzyk projektu i sposobu ich ograniczenia, bo uczciwe nazwanie ryzyka odróżnia dostawcę, który już przeszedł podobne wdrożenie, od takiego, który zamierza się go dopiero nauczyć na Twoim budżecie. Taki wykaz ryzyk jest też najlepszym sprawdzianem, czy oferent rozumie specyfikę migracji, czy zna ją wyłącznie z opisu produktu.
Czym są managed services dla Microsoft Fabric i czy są potrzebne?
Microsoft Fabric to utrzymanie platformy po jej uruchomieniu: monitoring wydajności, reagowanie na incydenty, rozwój kolejnych przypadków użycia oraz optymalizacja kosztu pojemności rozliczanej w jednostkach F-SKU. Bez tej warstwy platforma działa, ale jej koszt i kondycja pozostają bez nadzoru.
Są potrzebne, ponieważ model pojemności Microsoft Fabric jest elastyczny, ale wymaga aktywnego zarządzania: pozostawiona bez kontroli pojemność potrafi generować koszt wyższy, niż wynika z faktycznego zapotrzebowania. Dobry wykonawca traktuje utrzymanie jako część oferty i zapisuje je w umowie jako mierzalny poziom usługi, a nie jako uprzejmość po fakcie. Sprzedawca licencji tej warstwy nie oferuje, bo jego rola kończy się na dostarczeniu dostępu, i to właśnie brak odpowiedzi na pytanie o utrzymanie jest jednym z najpewniejszych sygnałów, z kim rozmawiasz. W praktyce warto zapisać zakres utrzymania jako mierzalny poziom usługi z czasami reakcji, bo dopiero wtedy managed services są zobowiązaniem, a nie hasłem w ofercie, i dopiero wtedy można rozliczyć dostawcę z kondycji platformy.
Ile kosztuje konsulting i wdrożenie Microsoft Fabric?
Koszt dzieli się na dwie różne pozycje, które warto rozpatrywać osobno. Pierwsza to licencja i pojemność platformy, rozliczana w modelu zużycia w jednostkach F-SKU, którą można skalować w górę i w dół oraz wstrzymywać, gdy platforma nie pracuje. Druga to praca wdrożeniowa i konsulting Microsoft Fabric, czyli projektowanie, migracja, budowa modelu i utrzymanie.
Uczciwa wycena rozdziela te dwie pozycje, bo dopiero wtedy widać, ile płacisz za dostęp, a ile za faktycznie wykonaną pracę. Dostawca, który podaje jedną cenę za wszystko, ukrywa właśnie tę proporcję. Najrozsądniejszym sposobem poznania faktycznego kosztu jest zaczęcie od audytu gotowości i jednego przypadku użycia o ograniczonym zakresie, który daje konkretną liczbę i podstawę do zaplanowania kolejnych kroków, zamiast dużego kontraktu wycenianego z góry na podstawie założeń. Taki start zamienia rozmowę o cenie z abstrakcyjnego szacunku w konkretną liczbę opartą na Twoich danych, a przy okazji pokazuje, jak dostawca pracuje i jak komunikuje ryzyko, zanim zaangażujesz w projekt duży budżet.
Porozmawiajmy o Twoim projekcie
Napisz, z czym przychodzisz: wdrożenie, migracja, rozwój systemu albo pytanie, na które szukasz odpowiedzi. Wracamy z konkretną propozycją następnego kroku, nie z prezentacją handlową.
