Co dalej z SAP BW?

Działająca hurtownia danych to sprawdzone modele danych, krytyczne raporty, definicje KPI i wiedza biznesowa budowana latami. Ale też elementy, które warto uprościć albo zastąpić nowym podejściem. Dlatego najważniejsze pytanie brzmi, co z obecnego środowiska warto zabrać ze sobą.

Z perspektywy kalendarza sytuacja jest już dość czytelna. Starsze wersje SAP BW oparte na SAP NetWeaver 7.4 i wcześniejszych zakończyły mainstream maintenance 31 grudnia 2020 r. Firmy korzystające z SAP BW 7.5 mają więcej czasu, ale również stoją przed realnym horyzontem decyzji, co dalej: mainstream maintenance dla ich wersji trwa do końca 2027 r., a optional extended maintenance do końca 2030 r. Z kolei SAP BW/4HANA ma perspektywę utrzymania co najmniej do 2040 r.

Jednocześnie byłoby błędem patrzeć na ten temat wyłącznie przez pryzmat dat zakończenia maintenance. W wielu organizacjach pytanie „co dalej z SAP BW?” wraca dziś również dlatego, że rosną koszty utrzymania obecnego systemu, użytkownicy oczekują prostszego interfejsu, a biznes potrzebuje szerszego zakresu raportowania i szybszego dostępu do danych. Firmy porządkują krajobraz wokół SAP S/4HANA, rozważają model cloud i coraz częściej zaczynają myśleć o danych jako o fundamencie nowoczesnej analityki, planowania i AI.

Dlatego pytanie o przyszłość SAP BW rzadko dotyczy dziś wyłącznie wsparcia producenta. Znacznie częściej obejmuje jednocześnie zakres raportowania, ponoszone koszty, poziom ryzyka, odpowiedzialność za logikę danych i to, jaką rolę dane mają pełnić w firmie przez najbliższe lata. Dwie organizacje mogą mieć tę samą wersję systemu i ten sam kalendarz maintenance, a mimo to dojść do zupełnie różnych wniosków dotyczących kierunków rozwoju hurtowni.

W tym miejscu warto rozróżnić trzy sytuacje wyjściowe.

• Pierwsza to firmy pracujące na starszych wersjach SAP BW, czyli 7.4 i wcześniejszych. Dla nich pytanie nie brzmi już „czy coś robić”, ale raczej „jak szybko i rozsądnie uporządkować dalszą drogę”.
• Druga grupa to firmy pracujące na SAP BW 7.5. To właśnie tutaj najczęściej pojawia się pytanie, czy celem jest zyskanie dodatkowego czasu, uproszczenie systemu, przejście do SAP BW/4HANA, czy przygotowanie się do szerszej modernizacji z użyciem SAP Datasphere i SAP BDC.
• Trzecia grupa to firmy na SAP BW/4HANA. W ich przypadku presja czasu jest mniejsza, a rozmowa częściej dotyczy tego, czy obecny system ma pozostać stabilnym core na lata, czy stać się etapem do dalszej modernizacji.

W praktyce nie ma jednej dobrej odpowiedzi dla wszystkich. Najczęściej sensowne są trzy ścieżki do wyboru: modernizacja istniejącego BW w kierunku BW private cloud edition w ramach SAP BDC, podejście greenfield w SAP Business Data Cloud (SAP BDC) oraz migracja do SAP BW/4HANA.

Hurtownią danych nowej generacji osadzoną w chmurze jest SAP Datasphere, będąca częścią SAP Business Data Cloud. Samo SAP BDC jest pojęciem szerszym, to w pełni zarządzane środowisko typu Software as a Service (SaaS), które łączy dane SAP i zewnętrzne, wspiera analitykę i otwiera drogę do nowych scenariuszy opartych na AI.

To ważne rozróżnienie. SAP Datasphere odpowiada przede wszystkim za integrację danych, katalogowanie, modelowanie semantyczne, federację i wirtualizację. SAP BDC obejmuje więcej: nie tylko warstwę danych, ale cały nowoczesny model pracy z nimi – od analityki i planowania przez data products po gotowe scenariusze biznesowe i aplikacje oparte na AI. To właśnie dlatego dla wielu organizacji BDC staje się nie tylko kolejnym narzędziem, ale realnym kandydatem na docelowe środowisko pracy z danymi. W tej logice ważną rolę odgrywają data products, czyli uporządkowane, gotowe do użycia zasoby danych z zachowanym kontekstem biznesowym, przygotowane tak, aby można je było bezpiecznie współdzielić i wykorzystywać dalej w analityce oraz AI.

SAP Analytics Cloud z kolei stanowi w architekturze SAP BDC narzędzie do tworzenia interaktywnych dashboardów, planowania i prognozowania. W tym narzędziu użytkownicy końcowi analizują dane i wyciągają wnioski na ich podstawie, również wykorzystując narzędzia AI.

Mocną stroną BDC są też intelligent applications – gotowe, w pełni zarządzane aplikacje oparte na AI, budowane na certyfikowanych data products. SAP opisuje je jako aplikacje, które rozumieją kontekst biznesowy, wykorzystują predefiniowane metryki, modele AI i elementy planowania, a ich zadaniem jest szybsze przekładanie danych na decyzje i działania. Dla firmy oznacza to, że nie wszystko trzeba budować od zera: część scenariuszy może być uruchamiana jako gotowe komponenty, osadzone w konkretnych obszarach biznesowych.

Dodatkowym atutem jest SAP Databricks, natywnie dostępny w SAP BDC. Jest to wbudowane środowisko do data engineering, machine learning i bardziej zaawansowanej pracy z danymi, z dostępem do danych SAP i third-party oraz wsparciem dla zero-copy Delta Sharing. To ważne zwłaszcza tam, gdzie organizacja chce nie tylko raportować, ale także rozwijać bardziej zaawansowane scenariusze analityczne i AI bez budowania osobnej, rozproszonej architektury od podstaw.

W tym modelu ważnym pojęciem jest też BW private cloud edition (BW PCE), czyli BW w chmurze prywatnej. To właśnie ono staje się punktem wyjścia dla pierwszej ze ścieżek modernizacji, w której na podstawie obiektów SAP BW mogą być wygenerowane produkty danych SAP BDC, które można poddawać dalszemu modelowaniu w SAP Datasphere, analizować za pomocą AI w SAP Databricks czy też wizualizować w SAP Analytics Cloud.

Wybór właściwej drogi przejścia z istniejącego BW w stronę nowych rozwiązań jest tematem złożonym. Trzeba uwzględnić zakres raportowania, skalę zmian, koszty utrzymania i migracji, umiejętności użytkowników, gotowość biznesu oraz to, jak ważne jest zachowanie obecnej logiki danych. Poniżej prezentujemy trzy możliwe scenariusze.

BW private cloud edition w SAP BDC (BW PCE)

Jedną z najbardziej praktycznych ścieżek jest dziś przeniesienie istniejącego SAP BW 7.5 lub SAP BW/4HANA do private cloud edition w SAP BDC. W takim modelu środowisko może zostać przeniesione as is, bez natychmiastowego przebudowywania całego rdzenia. To rozwiązanie daje ciągłość, zdejmuje z firmy ciężar infrastruktury, wydłuża perspektywę utrzymania (do 2030 r. w przypadku SAP BW7.5) oraz otwiera drogę do nowych narzędzi w ramach SAP BDC i lepszej integracji z nowymi systemami.

Na tym nie kończy się jednak wartość tej ścieżki. Dane z BW mogą być następnie wykorzystywane w SAP Datasphere, raportowane i wizualizowane w SAP Analytics Cloud, udostępniane jako data products oraz używane w nowych scenariuszach AI. W praktyce właśnie tak należy rozumieć logikę lift, shift, innovate w ramach tej ścieżki: najpierw przenosisz środowisko (lift), potem udostępniasz i wykorzystujesz dane w pozostałych narzędziach SAP BDC (shift), a dopiero później budujesz nowe modele i reimplementujesz obecne rozwiązanie w nowej technologii (innovate). W ten sposób, wykorzystując w pełni obecne przetwarzanie danych w SAP BW, można korzystać z nowych technologii, AI i przyjaznego interfejsu.

Na schemacie poniżej przedstawiono możliwości przejścia z systemu SAP BW do SAP BW PCE w zależności od wersji obecnego systemu.

Takie rozwiązanie jest przede wszystkim dedykowane dla rozbudowanych hurtowni danych SAP BW oraz SAP BW/4HANA, w których uproszczenie i reimplementacja obecnego systemu raportowego mogą być czasochłonne i skomplikowane. Podejście to umożliwia jednocześnie korzystanie w pełni z danych przetworzonych na obecnym systemie w ramach narzędzi dostępnych w SAP BDC.

SAP BDC greenfield

Druga ścieżka to podejście greenfield w SAP BDC. Ma ono sens przede wszystkim dla mniejszych hurtowni danych SAP BW, dla których uporządkowanie, uproszczenie i reimplementacja obecnego rozwiązania nie są zbyt czasochłonne ani biznesowo ryzykowne. W takim wariancie organizacja nie przenosi starego systemu w całości, tylko buduje nowe środowisko w logice docelowej architektury z wykorzystaniem inteligentnych aplikacji, hurtowni danych SAP Datasphere czy AI w SAP Databricks.

W tym podejściu możemy uzyskać prostszy model danych, szybsze odcięcie się od historycznego balastu i lepsze dopasowanie do nowych potrzeb. Wymaga jednak większej gotowości organizacyjnej, dobrej znajomości potrzeb raportowych i świadomej oceny, czy rzeczywiście opłaca się budować nowe środowisko zamiast chronić istniejące inwestycje.

Przejście do SAP BW/4HANA

Trzecia ścieżka to przejście do SAP BW/4HANA. Dla wielu organizacji może to być nadal bardzo rozsądna opcja, szczególnie wtedy, gdy firma chce utrzymać klasyczną hurtownię danych SAP, uprościć rdzeń, a jednocześnie nie wchodzić od razu w szerszą transformację chmurową. Taki wariant daje dłuższy horyzont utrzymania, niższe ryzyko architektoniczne oraz lepszą integrację z nowszymi systemami SAP.

To nie jest jednak decyzja uniwersalna. Jeżeli głównym celem firmy jest szersza modernizacja danych, większa otwartość na źródła spoza SAP albo nowe scenariusze AI i data products, sama droga do BW/4HANA może być zbyt zachowawcza. Jeśli natomiast organizacja nie jest gotowa na przejście na infrastrukturę docelową (SAP BDC), SAP BW/4HANA może jak najbardziej stanowić etap przejściowy.

W wielu firmach zagadnienie „co dalej z BW?” okazuje się w pewnym momencie nie tyle problemem technologii, ile problemem ownershipu. Kto jest właścicielem definicji KPI (Key Performance Indicator)? Kto decyduje, które raporty są jeszcze krytyczne, a które są tylko historyczne? Kto odpowiada za jakość i spójność logiki danych? Bez odpowiedzi na te pytania nawet dobra architektura szybko zaczyna żyć własnym, mało kontrolowanym życiem.

Podobnie jest z kosztami. Uczciwe porównanie wariantów powinno obejmować nie tylko licencję lub subskrypcję, ale także infrastrukturę lub hosting, projekt migracji lub konwersji, porządkowanie raportów i modeli, testy, zmianę organizacyjną, późniejsze koszty utrzymania oraz koszt zaniechania. Najtańsza licencja lub subskrypcja nie musi oznaczać najtańszej decyzji.

To jest jeden z najważniejszych etapów całej decyzji. Bo przyszłość SAP BW nie sprowadza się do wyboru nowej nazwy technologii. Najpierw trzeba odpowiedzieć na trzy bardzo praktyczne pytania.

• Co warto zachować. Chodzi o krytyczną logikę biznesową, raporty realnie używane, obszary, od których rzeczywiście zależą decyzje zarządcze, kontroling, finanse, sprzedaż oraz planowanie. Zachować warto nie to, co istnieje od dawna, ale to, co nadal tworzy wartość;
• Co warto uprościć. Tu najczęściej mieszczą się martwe raporty, historyczne zależności, duplikaty logiki i obiekty utrzymywane tylko dlatego, że od dawna nikt nie zdecydował, czy są jeszcze potrzebne;
• Co rozwijać dalej. To właśnie tu zaczyna się rozmowa o nowych potrzebach, których nie warto już na siłę wpychać do klasycznego modelu BW, na przykład o danych spoza SAP, produktach danych, nowych modelach konsumpcji informacji albo scenariuszach związanych ze sztuczną inteligencją.

W praktyce dobrym pierwszym krokiem bywa uporządkowany assessment obecnego środowiska business intelligence. Pozwala on ocenić, które obszary są nadal aktywnie wykorzystywane, gdzie warto uprościć logikę i raportowanie, a gdzie rzeczywiście zaczyna się obszar dalszej modernizacji. Dzięki temu łatwiej oddzielić to, co nadal tworzy wartość, od tego, co jest już raczej historycznym ciężarem.

Dojrzała decyzja nie polega więc na tym, żeby wszystko zachować albo wszystko wymienić. Chodzi o to, żeby rozdzielić aktywa od ciężaru i nie próbować przenosić w przyszłość wszystkiego w tej samej formie.

Najpierw warto sobie uświadomić, czy główny problem dotyczy dziś utrzymania, raportowania, ownershipu czy już szerszej architektury danych. Potem ocenić, co w obecnym środowisku jest realnie używane i wartościowe. Następnie oddzielić to, co warto zachować, od tego, co warto uprościć i tego, co powinno być rozwijane już w nowej logice.

Bo pytanie „co dalej z SAP BW?” nie jest w gruncie rzeczy pytaniem o technologię. To jest pytanie o to, czy obecna warstwa danych nadal odpowiada na potrzeby organizacji teraz i w przyszłości. A jeśli nie – co należy zachować, co uprościć i co rozwinąć, żeby następny krok był naprawdę rozsądny.

Jeśli przyszłość SAP BW jest dziś jednym z dyskutowanych u Państwa tematów, zapraszamy do kontaktu. Pomożemy uporządkować możliwe scenariusze i wybrać strategię najlepiej dopasowaną do potrzeb biznesu, danych i architektury.