Rozważmy przedsiębiorstwo, którego platforma analityczna już łączy transakcje SAP z danymi spoza SAP, ale dział finansowy nadal kwestionuje raport marży. Decyzja zakupowa nie dotyczy tego, czy SAP Business Data Cloud brzmi jak bardziej zintegrowane rozwiązanie. Chodzi o to, czy proponowany dodatek rozwiąże konkretny problem z dostępem, definicjami biznesowymi lub kontrolą lepiej niż usprawnienie obecnej architektury.
Ocenę SAP Business Data Cloud zacznij od wymagania raportowego, które ma właściciela biznesowego i uzgodnioną miarę. Porównaj utrzymanie obecnej architektury, dodanie wąsko określonej funkcjonalności obsługi danych SAP oraz szersze wdrożenie Business Data Cloud. Pakiet produktów i pozycjonowanie wokół AI nie powinny zastępować dowodów na to, że otrzymasz dodatkową, potrzebną funkcjonalność.
Określ lukę, zanim wybierzesz zakres platformy
Opisz problem z raportowaniem bez wskazywania proponowanego rozwiązania. Być może wymagane obiekty SAP są niedostępne przez obecną ścieżkę dostępu, obliczenie nie ma uzgodnionej definicji biznesowej albo raport nie spełnia wymagań dotyczących aktualności danych. Potraktuj te kwestie jako hipotezy do sprawdzenia, a nie automatyczne uzasadnienie zakupu kolejnej platformy.
Praktyczna zasada przedstawiona w dyskusji o transformacji przedsiębiorstw polega na wybraniu użytecznego zastosowania i postawieniu dostawcy zadania zademonstrowania go w działaniu. W rozmowie Business Data Cloud, Databricks i Azure pojawiają się jako możliwe platformy, bez wskazania preferowanego produktu. Zastosuj tę zasadę do wyniku raportowania, niezależnie od decyzji dotyczącej AI czy aktualizacji ERP.
Utrzymanie obecnej architektury zasługuje na rzetelne porównanie. SAP podaje w FAQ, że obecni klienci SAP Datasphere i SAP Analytics Cloud mogą nadal korzystać ze swoich rozwiązań, a przejście na Business Data Cloud przedstawia jako opcję dostępną z czasem. Poproś zespół odpowiedzialny za obecną platformę o propozycję rozwiązania problemu według tych samych kryteriów odbioru co nowa oferta.
- Utrzymaj i usprawnij: wybierz ten wariant, gdy obecna architektura potrafi zapewnić wymagany dostęp, miarę i mechanizmy kontroli przy akceptowalnym nakładzie pracy operacyjnej.
- Dodaj wąski zakres: wybierz go, gdy konkretna funkcjonalność obsługi danych SAP usuwa potwierdzoną lukę, a obecna platforma zachowuje odpowiedzialność za pozostałą analitykę.
- Wdróż szerzej: rozważ ten wariant, gdy kilka zatwierdzonych wymagań uzasadnia proponowany zakres, a zespół potrafi wyjaśnić, które obecne obowiązki zostaną przeniesione, pozostaną lub znikną.
Nie pozwól, by wąskie wymaganie techniczne przerodziło się w zakup o niejasnym zakresie handlowym. FAQ SAP Business Data Cloud wskazuje, że dostęp do produktów danych SAP wymaga zakupu odpowiedniej aplikacji Intelligent Application. Przyporządkuj każdy wymagany produkt danych do proponowanych uprawnień i potwierdź je we właściwych opisach usług oraz formularzu zamówienia.
Zbuduj arkusz oceny wokół wymagania raportowego
Arkusz oceny powinien łączyć miarę biznesową z obiektami źródłowymi, ścieżką dostępu i osobą odpowiedzialną za utrzymanie. Przy każdej pozycji umieść odwołanie do dowodu, osobę odpowiedzialną za weryfikację i pole na nierozstrzygnięte pytania. Nazwa produktu czy zrzut ekranu z demonstracji nie zastąpią takiej identyfikowalności.
| Obszar oceny | Co zapisać i o co poprosić | Dowody wymagane do odbioru |
|---|---|---|
| Obiekty i definicje biznesowe | Wymagane obiekty SAP, pola niestandardowe, reguły obliczeń, zasady obsługi walut i poziom szczegółowości raportowania. | Mapowanie obiektów na miarę zatwierdzone przez właściciela biznesowego. |
| Obsługiwane źródła | Zainstalowane wersje systemów źródłowych, warunki wstępne, proponowany region i status dostępności. | Dokumentacja wsparcia dla dokładnie proponowanej konfiguracji, oddzielająca funkcje zapowiedziane od dostępnych. |
| Aktualność i uzgodnienie danych | Wymagany moment odcięcia danych do raportu, sposób odświeżania, opóźnione zmiany i reguły uzgadniania. | Powtarzalne wyniki uzgodnienia danych od źródła do raportu oraz pomiar aktualności względem uzgodnionego wymagania. |
| Tożsamość i autoryzacja | Mapowanie użytkowników, tożsamości usługowe, ograniczenia na poziomie wierszy, odbieranie uprawnień i dostęp administracyjny. | Wyniki testów użytkowników z dostępem, bez dostępu oraz po odebraniu uprawnień na całej ścieżce. |
| Przepływ danych | Ekstrakcja, udostępnianie, replikacja, pamięci podręczne, lokalizacje przechowywania i dalsze kopie. | Schemat ścieżki dostępu pokazujący, gdzie dane są utrwalane i który zespół je kontroluje. |
| Odpowiedzialność operacyjna | Błędy odświeżania, zmiany schematów, utrzymanie modeli, monitoring i eskalacja incydentów. | Rejestr odpowiedzialności zaakceptowany przez zespoły, które mają utrzymywać rozwiązanie. |
| Zużycie i nakładanie się zakresów | Uprawnienia, mierniki wykorzystania zasobów, zobowiązania, opłaty za transfer i koszty utrzymywanych platform. | Model zużycia powiązany z ofertą cenową, obejmujący całą ścieżkę raportowania. |
| Wyjście i eksport | Formaty eksportu, definicje możliwe do ponownego wykorzystania, prawa umowne, dostęp po zakończeniu umowy i obowiązki usunięcia danych. | Przetestowana ścieżka eksportu oraz właściwe warunki pisemne, ocenione oddzielnie. |
W przypadku semantyki wymagaj więcej niż zgodności nazw pól. W hipotetycznym raporcie marży uzgodnij, jak zwroty, anulowania, przeliczenia walut i opóźnione księgowania wpływają na miarę. Następnie ustal, gdzie wykonywana jest każda reguła i kto zatwierdza zmiany. Jeżeli proponowane rozwiązanie wymaga równoległej definicji, wyraźnie wskaż to powielenie przed zatwierdzeniem zakupu.
Tak samo potraktuj zakres utrzymania. SAP odróżnia pakiety treści biznesowych Datasphere i Analytics Cloud, które klienci samodzielnie konfigurują, wdrażają, a następnie utrzymują, od ofert zarządzanych. Zapytaj, które elementy propozycji są treściami utrzymywanymi przez klienta, a które obejmuje usługa zarządzana. Przypisz odpowiedzialność do konkretnych elementów zamiast akceptować ogólne określenie „platforma zarządzana”.
Zamień demonstrację w test odbiorowy
Uzgodnij wymagane dowody przed demonstracją. Dla hipotetycznego raportu marży wybierz zatwierdzony okres raportowy i zbiór danych źródłowych, udokumentuj oczekiwane obliczenie oraz określ sposób wyjaśniania różnic. Poproś zespół o odtworzenie miary w proponowanej architekturze i wyjaśnienie rozbieżności na poziomie rekordów źródłowych.
Przekonujący wynik powinien dać się odtworzyć przez twój zespół, bez zależności od niejasno skonfigurowanego środowiska demonstracyjnego. Zachowaj zapytania lub transformacje, dobór danych źródłowych, konfigurację i dokumentację wykonania potrzebne do odtworzenia wyniku. Dopracowany pulpit z niewyjaśnioną sumą powinien prowadzić do dalszej weryfikacji, nie do odbioru.
Aktualność danych testuj oddzielnie od poprawności. Zapisz, kiedy kontrolowana zmiana w źródle staje się widoczna w raporcie, a następnie powtórz próbę z opóźnioną korektą i przerwanym odświeżaniem. Poproś zespół wdrożeniowy o zademonstrowanie przywracania działania i wskazanie osoby odpowiedzialnej za obsługę wyjątku. Określ akceptowalne zachowanie na podstawie wymagania biznesowego zamiast przyjmować nieprecyzyjną deklarację terminowej dostępności danych.
Autoryzacja również wymaga osobnego testu. Porównaj użytkowników z różnymi uprawnieniami, spróbuj uzyskać dostęp do wykluczonych rekordów i sprawdź odebranie uprawnień. Udokumentuj, czy ograniczenia są egzekwowane w źródle, warstwie pośredniej czy platformie korzystającej z danych. Nie zakładaj, że działające połączenie dowodzi równoważnego działania autoryzacji.
W propozycji łączącej SAP Business Data Cloud z Databricks odróżnij usługę SAP Databricks od środowiska Databricks, które już utrzymujesz. FAQ SAP podaje, że usługi SAP Databricks są dostępne jako Capacity Services w podstawowej subskrypcji Business Data Cloud, bez dodatkowej licencji Databricks. Nie traktuj tego stwierdzenia jako dowodu uprawnień do istniejącego obszaru roboczego ani integracji z nim. Wymagaj udokumentowania i przetestowania konkretnego obszaru roboczego, tożsamości, dostępu i granic odpowiedzialności operacyjnej.
Oceń dodatkową wartość, pełne koszty i realną możliwość wyjścia
Przełóż zademonstrowaną architekturę na zakres handlowy. Poproś o wskazanie właściwych jednostek i mierników wykorzystania zasobów, minimalnych zobowiązań, zasad naliczania opłat za przekroczenia, kosztów przechowywania i transferu oraz opłat powstających na obecnej platformie analitycznej. Uwzględnij wdrożenie i bieżącą pracę operacyjną. Traktuj zapis o licencjonowaniu z FAQ jako kwestię uprawnień do wyjaśnienia, a nie pełny model kosztów.
Oznacz każdy istniejący potok danych, model semantyczny, pulpit i obowiązek monitorowania jako pozostający, zastępowany lub wycofywany. Jeżeli szersze wdrożenie pozostawia je wszystkie bez zmian, wymagaj jasnego wyjaśnienia, jaka dodatkowa funkcjonalność uzasadnia nakładanie się zakresów. Z drugiej strony nie przypisuj oszczędności do wycofania rozwiązania, dopóki odpowiedzialna osoba nie zaakceptuje jego zastępstwa, a dotychczasowe zobowiązanie rzeczywiście nie będzie mogło wygasnąć.
Oddziel techniczną przenośność od praw umownych. Poproś zespół o wyeksportowanie wymaganych danych i definicji w użytecznej postaci, a następnie dział zakupów o potwierdzenie praw do ich zachowania i wykorzystania, dostępu po zakończeniu umowy, wsparcia przy wyjściu oraz obowiązków usunięcia danych. Działający eksport sam w sobie nie rozstrzyga tych warunków.
Zakończ ocenę notatką decyzyjną: kup szerszy zakres, gdy potwierdzone wymagania go uzasadniają; kup wąski zakres, gdy określona funkcjonalność usuwa lukę; albo odłóż decyzję, gdy obecna architektura spełnia wymaganie lub kluczowe warunki odbioru pozostają nierozstrzygnięte. Zapisz, jakie dowody zmieniłyby decyzję i kto odpowiada za ich uzyskanie.
Przed zatwierdzeniem wydatku poproś właściciela biznesowego oraz osoby odpowiedzialne za SAP i analitykę o podpisanie tego samego protokołu odbioru obejmującego ścieżkę od źródła do raportu. Jeśli potrzebujesz pomocy w określeniu ścieżek dostępu do danych SAP, reguł biznesowych lub odpowiedzialności za integrację, omów ocenę ze specjalistami SAP w Digiventi.
