SAP Business Data Cloud czy Fabric: kryteria wyboru

SAP Business Data Cloud i Microsoft Fabric należy porównywać przez zdolność do zachowania znaczenia danych biznesowych, a nie samą szybkość ich kopiowania. Jeżeli raport finansowy po migracji inaczej rozumie przychód, okres lub jednostkę organizacyjną, szybsze zapytanie nie naprawia problemu. Dla firmy korzystającej z SAP koszt odtworzenia tych reguł może być ważniejszy od ceny przechowywania terabajta.

Wybór dotyczy sposobu dostarczania danych do decyzji. Nie musi oznaczać wymiany wszystkich narzędzi ani wskazania jednego producenta dla całej organizacji. Wymaga natomiast ustalenia, gdzie powstaje definicja wskaźnika, kto ją zatwierdza i jak trafia do odbiorców.

Co obejmuje SAP Business Data Cloud

SAP Business Data Cloud łączy możliwości zarządzania danymi, analityki i planowania. SAP wymienia w tym kontekście między innymi Datasphere, SAP Analytics Cloud, SAP BW, SAP HANA Cloud oraz SAP Databricks. Istotną częścią podejścia są produkty danych zawierające kontekst, semantykę biznesową i dokumentację. Opis Business Data Cloud producenta.

Lista składników nie oznacza, że każda firma otrzymuje wszystkie możliwości w jednej cenie i bez dodatkowej konfiguracji. W ofercie należy wskazać potrzebne usługi, region, zasoby i warunki dostępu. W pilotażu trzeba sprawdzić również, czy konkretny produkt danych odpowiada używanej wersji aplikacji oraz rzeczywistemu procesowi firmy.

Produkt danych nie jest synonimem dowolnej tabeli. Dla odbiorcy liczy się opis znaczenia pól, zakres historii, częstotliwość aktualizacji oraz odpowiedzialność za zmiany. Jeśli tych informacji brakuje, użytkownicy nadal muszą odgadywać, czy dana liczba nadaje się do podjęcia decyzji.

Co wnosi Microsoft Fabric

Fabric jest platformą SaaS obejmującą integrację, przetwarzanie i analitykę danych, z OneLake jako wspólną warstwą przechowywania. W jednym środowisku udostępnia różne sposoby pracy, między innymi hurtownię, lakehouse i Power BI. Przegląd Microsoft Fabric.

W firmie z SAP warto oceniać Fabric jako część konkretnego przepływu: od danych operacyjnych przez reguły przetwarzania do raportu lub zastosowania AI. Obecność narzędzi Microsoft w organizacji może ułatwiać pracę zespołu, ale nie dowodzi, że przeniesienie wszystkich danych SAP będzie proste lub opłacalne.

Wspólna platforma techniczna nie tworzy automatycznie wspólnego języka biznesowego. Jeżeli sprzedaż rozumie klienta jako odbiorcę zamówienia, a finanse jako płatnika, połączenie tabel wymaga świadomego modelu. Ten model trzeba przygotować niezależnie od wybranego narzędzia.

Pierwsze porównanie: gdzie znajduje się wartość

Pytanie	Co sprawdzić w SAP Business Data Cloud	Co sprawdzić w Microsoft Fabric
Czy zachowamy reguły SAP?	Dopasowanie produktów danych do procesu	Zakres reguł wymagających odtworzenia
Jak połączymy inne źródła?	Dostępne ścieżki i odpowiedzialność za model	Integrację oraz spójność identyfikatorów
Kto korzysta z wyniku?	Odbiorców analityki i planowania	Odbiorców raportów, danych i modeli
Co już mamy?	Modele BW, Datasphere i kompetencje zespołu	Modele Power BI i kompetencje zespołu
Jak utrzymamy rozwiązanie?	Właścicieli produktów danych i usług	Właścicieli potoków, modeli i pojemności

Przygotuj po jednym dowodzie dla każdego istotnego wiersza. Zamiast stwierdzenia „integruje się z SAP” zapisz, jakie dane pobrano, z jakiej wersji systemu i z jakim opóźnieniem. Zamiast „zachowuje semantykę” pokaż uzgodnienie wybranego wskaźnika z zatwierdzonym raportem.

Zacznij od procesu o czytelnych granicach. Analiza terminowości dostaw może łączyć zamówienia, przyjęcia i informacje od przewoźnika. W takim przypadku porównanie powinno uwzględniać zarówno dane SAP, jak i to zewnętrzne źródło. Test ograniczony do jednej łatwej tabeli pominie najważniejszą część pracy.

Konektor nie jest gotową integracją biznesową

Microsoft dokumentuje konektor SAP HANA dla Data Factory w Fabric, obejmujący między innymi odczyt w Dataflow Gen2, działania potoku i Copy job. Wskazuje również bramę lokalną oraz obsługiwane sposoby uwierzytelnienia. To konkretna ścieżka techniczna, której nie należy utożsamiać z pełnym odwzorowaniem procesów aplikacji SAP. Możliwości konektora SAP HANA.

Nie przenoś założeń między produktami tylko dlatego, że ich nazwy są podobne. Możliwości Azure Data Factory nie muszą odpowiadać konkretnej funkcji Data Factory w Fabric. Sprawdź dokumentację dokładnie tego konektora i rodzaju zadania, które zamierzasz uruchomić.

Dla wybranej ścieżki ustal sposób pierwszego zasilenia, pobierania zmian i obsługi usunięć. Zmiana istniejącej pozycji dokumentu jest innym zdarzeniem niż dodanie nowego rekordu. Jeżeli integracja rozpoznaje tylko przyrost identyfikatorów, może pozostawić nieaktualne wartości w raporcie.

Zapytaj również o obciążenie źródła i okno wykonywania ekstrakcji. Raport analityczny nie powinien zakłócać pracy operacyjnej. Testuj z administratorem SAP, na uzgodnionym zakresie i przy kontrolowanych uprawnieniach. Potwierdź warunki korzystania z danych oraz integracji w umowach firmy, zamiast wyprowadzać je z samej dostępności przycisku w narzędziu.

Semantyka: pięć rzeczy, które łatwo zgubić

Po pierwsze, zdefiniuj jednostki i waluty. Kwota w walucie dokumentu, walucie lokalnej i walucie raportowej może opisywać ten sam dokument, ale nie jest wymienna. Ustal kurs, datę przeliczenia oraz sposób traktowania korekt.

Po drugie, sprawdź kalendarze. Rok obrotowy nie zawsze pokrywa się z kalendarzowym, a okres raportowy może zostać ponownie otwarty. Model powinien wyjaśniać, czy pokazuje aktualny stan, czy stan zatwierdzony na konkretny moment.

Po trzecie, zachowaj hierarchie i ich historię. Przeniesienie produktu do innej kategorii może zmienić porównanie wyników między okresami. Odbiorca musi wiedzieć, czy historia jest prezentowana według dawnej, czy obecnej struktury.

Po czwarte, uzgodnij statusy dokumentów. Zamówienie, anulowanie, zwrot i faktura opisują różne etapy procesu. Proste sumowanie kwot z kilku obiektów może dwukrotnie policzyć tę samą sprzedaż.

Po piąte, odtwórz ograniczenia dostępu. Osoba mogąca zobaczyć wynik całej spółki nie musi mieć prawa do szczegółów wszystkich pracowników lub kontrahentów. Sprawdź widok raportu, eksport i bezpośrednią ścieżkę do danych, a nie tylko ekran startowy aplikacji.

Pilotaż powinien zakończyć się uzgodnieniem wyniku

Wybierz zestaw dokumentów, który obejmuje zwykłe przypadki i wyjątki. Niech właściciel procesu wskaże oczekiwane sumy i sposób interpretacji różnic. Zespół techniczny powinien móc przejść od komórki raportu do dokumentów, które ją tworzą.

Próba	Pytanie odbiorowe	Oczekiwany dowód
Sprzedaż i zwrot	Czy wynik uwzględnia właściwe znaki i statusy?	Uzgodnienie z dokumentami źródłowymi
Korekta po zamknięciu	Czy historia zmienia się zgodnie z zasadą firmy?	Wynik przed korektą i po niej
Zmiana hierarchii	Według jakiej struktury pokazujemy przeszłość?	Porównanie dwóch okresów
Brak danych zewnętrznych	Czy raport sygnalizuje niekompletność?	Widoczny status i reakcja zespołu
Odebranie uprawnień	Czy użytkownik traci właściwy dostęp?	Test raportu, eksportu i źródła

Zdefiniuj dopuszczalne różnice wynikające z zaokrągleń, ale nie używaj ogólnej tolerancji do ukrywania błędów modelu. Niewielka różnica procentowa w sumie może maskować duży błąd dla pojedynczej spółki. Kontrola powinna obejmować zarówno całość, jak i istotne przekroje.

Mierz również czas wyjaśnienia rozbieżności. Jeśli specjalista potrzebuje dwóch dni, aby odnaleźć źródło jednej kwoty, rozwiązanie będzie kosztowne w utrzymaniu. Czytelne pochodzenie danych i udokumentowane reguły mają wartość operacyjną, nawet gdy nie zmieniają czasu wykonania zapytania.

Koszt obejmuje odtworzenie wiedzy o procesie

Wycena powinna uwzględniać usługi platformy, integrację, przechowywanie, przetwarzanie, dostęp odbiorców i wsparcie. Oddziel koszt pracy nad regułami biznesowymi od kosztu technicznego przesyłania danych. Ten pierwszy bywa ukryty w czasie ekspertów finansowych, logistycznych i sprzedażowych.

Przykład syntetyczny: wariant wymagający odtworzenia modelu pochłania 120 godzin pracy specjalistów przy przyjętej stawce 200 zł za godzinę, czyli 24 000 zł. W drugim wariancie dopasowanie istniejącego modelu zajmuje 40 godzin, czyli 8 000 zł. Różnica wynosi 16 000 zł. Jeżeli drugi wariant kosztuje miesięcznie o 1 000 zł więcej, sam ten nakład odpowiada 16 miesiącom różnicy opłat. To ilustracja rachunku, a nie cennik SAP lub Microsoft.

Do kalkulacji dodaj późniejsze zmiany procesu. Nowy typ dokumentu, reorganizacja spółek i aktualizacja aplikacji mogą wymagać modyfikacji modelu. Porównaj, kto wykona tę pracę, jak ją przetestuje i ile potrwa wdrożenie. Jednorazowy koszt pilota nie pokazuje całego cyklu życia rozwiązania.

Przygotuj osobny wariant kosztowy dla współistnienia platform. Uwzględnij monitorowanie przepływu między nimi i obsługę incydentów, przy których każdy zespół może widzieć tylko swoją część problemu. Oszczędność na jednej usłudze nie jest oszczędnością całego procesu, jeśli powstaje dodatkowy stały dyżur integracyjny.

Współistnienie wymaga jednej definicji odpowiedzialności

Firma może zachować produkty danych i reguły związane z SAP, a inne zastosowania rozwijać w Fabric. Taki układ ma sens, kiedy granica między platformami jest opisana i sprawdzona. Nie należy zakładać bezpośredniego udostępniania bez kopii dla dowolnej pary usług wyłącznie na podstawie ogólnego hasła marketingowego.

Ustal, która strona odpowiada za jakość danych, która za dostęp, a która za termin dostarczenia raportu. W kontrakcie danych zapisz właściciela, schemat, znaczenie pól, świeżość i zasady zapowiadania zmian. Odbiorca powinien wiedzieć, do kogo zgłosić problem bez analizowania diagramu wszystkich komponentów.

Przećwicz awarię połączenia i późniejsze nadrobienie zmian. Raport ma pokazać, że dane są nieaktualne, a wznowienie zasilania nie może tworzyć duplikatów. Ustal również, czy wyniki opublikowane podczas awarii wymagają ponownego zatwierdzenia po odzyskaniu kompletności.

Przygotuj także próbę zmiany schematu. Dodaj pole, zmień dopuszczalny status dokumentu albo wycofaj kolumnę w kontrolowanym środowisku. Obserwuj, czy odbiorca otrzymuje ostrzeżenie, czy raport przestaje działać jawnie, czy też nadal pokazuje pozornie poprawny wynik. Ten ostatni przypadek jest szczególnie trudny do zauważenia podczas zwykłego monitorowania dostępności.

Dla ważnego wskaźnika zachowaj krótki opis pochodzenia: system źródłowy, użyty produkt danych, przekształcenia, model i raport końcowy. Opis powinien być zrozumiały również dla właściciela biznesowego. Jeśli można go utrzymać tylko dzięki pamięci jednego konsultanta, projekt nie przekazał jeszcze wiedzy potrzebnej do samodzielnej eksploatacji.

Jak podjąć decyzję bez przebudowy całej firmy

SAP Business Data Cloud zasługuje na pilotaż, gdy dużą część wartości stanowią istniejące procesy, modele i kontekst SAP. Fabric warto sprawdzić, gdy ważny jest wspólny przepływ dla wielu źródeł i zespół potrafi określić koszt zachowania lub odtworzenia semantyki. Żaden z tych warunków samodzielnie nie przesądza wyniku.

Zacznij od jednej decyzji biznesowej i dwóch możliwych dróg dostarczenia potrzebnych danych. Odbierz poprawność, dostęp, świeżość i koszt utrzymania. Dopiero wtedy rozszerzaj zakres. Takie podejście łączy wybór platformy z budową systemu pracy z danymi i AI. Kolejny krok to uporządkowanie architektury danych z Microsoft Fabric i wskazanie miejsca, w którym pozostają reguły SAP.