Jak wdrożyć AI w SAP: mapa możliwości

Udostępnij

Five routes to implement AI in an SAP landscape: embedded features, platform extension, custom build, outside the stack, and partner solutions

Podejście firm do wykorzystania AI w systemach SAP uległo zmianie w ostatnim czasie. Czas eksperymentów się zakończył, obecnie budżety na wdrożenia są bardziej nastawione na wyniki, a SAP przebudował swoją narrację dookoła Autonomous Enterprise. Co się nie zmieniło, to pytanie: którymi drzwiami wchodzimy?

Jest 5 głównych dróg na włączenie sztucznej inteligencji w ekosystem SAP. Zazwyczaj mówi się o każdej z osobna. Brakuje mapy: możliwych dróg zestawionych ze sobą, ile każda kosztuje, jeśli chodzi o umiejętności zespołu, nakład na governance i dokąd każda z nich prowadzi. Poniższy artykuł jest taką mapą i otwiera serię, w której każda z dróg będzie dokładnie omówiona.

Większość organizacji będzie decydowała się na połączenie kilku z tych dróg, więc naszym celem jest ich przedstawienie, a nie wskazanie najlepszej.

Pięć dróg do AI w SAP: embedded AI, rozszerzenie platformy, budowa na AI Core, narzędzia poza SAP i partnerzy z SAP Store

Droga pierwsza: wykorzystaj to, co jest już dostępne

Najszybsza droga to AI, które masz już w pakiecie. Joule, asystent SAP, jest dostępny w S/4HANA Cloud, SuccessFactors, Ariba i pozostałych produktach chmurowych, a coraz szerszy zestaw funkcji embedded AI jest wbudowany bezpośrednio w procesy biznesowe: od rozliczania płatności w finansach po asystenta mapowania w usługach SAP BTP i narzędziach developerskich. Ich aktywacja wymaga jedynie konfiguracji, często nieprzekraczającej kilku dni.

Ceną za tę szybkość jest kontrola. Embedded AI działa tak, jak zaprojektował je SAP, rozwija się zgodnie z roadmapą SAP i jest rozliczane w modelu AI Units, który wymaga dokładnej analizy, zanim ktokolwiek obieca zarządowi szybkie efekty. Jako punkt wyjścia ta droga sprawdza się dobrze, natomiast przy konkretnym problemie biznesowym zwykle kończy się o krok za wcześnie, i właśnie tam zaczynają się kolejne drogi.

Droga druga: rozszerz platformę

Gdy funkcje embedded AI nie pokrywają twojego przypadku użycia, kolejną drogą jest budowanie na platformie AI od SAP, bez wychodzenia poza nią. To obszar SAP Business AI Platform: Joule Studio do własnych agentów i ich umiejętności, SAP Build do workflow i aplikacji wokół nich, a za tożsamość, dostęp i osadzenie w danych biznesowych odpowiada SAP.

Dla porządku dwie uwagi. Edytor workflow n8n, który SAP wbudowuje w Joule Studio jako warstwę orkiestracji, ma być ogólnie dostępny w trzecim kwartale 2026 roku, ale w chwili pisania tego tekstu jeszcze się nie pojawił. Nie trzeba jednak czekać: instancję self-hosted n8n możesz już dziś podłączyć do swojego BTP, a nawet uruchomić tam jako kontener.

Ta droga będzie odpowiednia dla organizacji, które chcą budować własne rozwiązania AI, ale ciężar governance wolą zostawić platformie. W praktyce wymaga to kompetencji BTP we własnym zespole albo partnera, który je wnosi.

Droga trzecia: zbuduj własne rozwiązanie

Niektóre problemy są na tyle specyficzne, że żaden gotowy agent ich nie rozwiąże. Na takie przypadki SAP udostępnia narzędzia do uruchamiania własnych modeli i aplikacji: SAP AI Core do wdrażania i utrzymania rozwiązań AI, Generative AI Hub do kontrolowanego dostępu do modeli bazowych oraz SAP HANA Cloud do wyszukiwania wektorowego i osadzania w danych.

To najbardziej wymagająca droga i zarazem ta z największym potencjałem. Dane pozostają w twoim BTP, rozwiązanie robi dokładnie to, czego potrzebuje twój proces, a wynik pracy pozostaje w firmie jako jej własne rozwiązanie, a nie jako subskrypcja usługi. Ceną są realne zasoby inżynierskie: utrzymanie modeli, ewaluacja promptów, zarządzanie cyklem życia rozwiązania. Dlatego ta droga jest zwykle drugim lub trzecim etapem wdrażania AI w organizacji, a rzadko pierwszym.

Droga czwarta: wyjdź poza ekosystem SAP

Rzetelna mapa pokazuje też drogi wyprowadzające poza ekosystem SAP: self-hosted n8n dla zespołów, którym wystarczy sam edytor workflow bez platformy, Workato do automatyzacji między aplikacjami z krokami AI, albo usługi AI hyperscalerów i bezpośredni dostęp przez API do najnowszych modeli, połączone z systemami SAP przez SAP Integration Suite.

Za tą drogą przemawiają konkretne powody: istniejące kompetencje, już wykupione licencje, przypadki użycia realizowane i tak głównie poza SAP. Przed decyzją trzeba jednak sprawdzić dwie rzeczy. Pierwsza to governance: poza ekosystemem SAP kontrola tożsamości, audytu i dostępu, którą droga druga zapewnia domyślnie, staje się obowiązkiem twojego zespołu. Druga jest nowsza i mniej znana: polityka API SAP, zaktualizowana w kwietniu 2026 roku, wprost ogranicza autonomiczne i generatywne systemy AI, które planują i wykonują sekwencje wywołań API na systemach SAP, do ścieżek zatwierdzonych przez SAP. Zanim wybierzesz tę drogę, sprawdź, czy planowany wzorzec mieści się w zatwierdzonej ścieżce i co trzeba zrobić, żeby się w niej zmieścił.

Droga piąta: kup gotowe rozwiązanie od partnera

Ostatnia droga to ta, którą działy IT dużych firm znają najlepiej: ktoś już to zbudował. SAP Store oferuje rosnący katalog rozwiązań AI od partnerów, instalowanych w twoim własnym subkoncie BTP, co znacząco skraca rozmowy o lokalizacji danych i o zakupach. Znamy tę drogę z obu stron, bo sami wprowadziliśmy do SAP Store produkt, który w całości powstał drogą trzecią.

Zakup ma sens, gdy problem jest na tyle powszechny, że istnieje na niego gotowy produkt, i na tyle specyficzny, że sama konfiguracja Joule go nie rozwiąże. Pytania przy ocenie są klasyczne: gdzie trafiają dane, co dzieje się przy odnowieniu umowy i kto odpowiada za wsparcie, gdy coś przestanie działać.

Jak wybrać w praktyce

W praktyce o wyborze decyduje sześć pytań:

  • Clean core. Mniej zależy tu od tego, którą drogę wybierzesz, a bardziej od tego, w jaki sposób rozwiązanie dotyka rdzenia systemu. Każda z opcji pozwala zachować czysty rdzeń, o ile korzysta z opublikowanych API i oficjalnych punktów rozszerzeń.
  • Lokalizacja danych (data residency). Gdzie fizycznie trafiają prompty, kontekst i wyniki? Drogi pierwsza i druga utrzymują dane w granicach SAP, natomiast na drodze czwartej granicę tę wyznacza już twoja organizacja.
  • Umiejętności zespołu. Droga pierwsza wymaga umiejętności administracyjnych, druga praktyków BTP, a trzecia pełnego zespołu inżynierskiego. Oceń realistycznie, którymi z nich twoja organizacja faktycznie dysponuje.
  • Model kosztów. AI Units, kredyty BTP rozliczane za zużycie, zewnętrzne subskrypcje i wewnętrzne koszty utrzymania zachowują się w skali zupełnie inaczej. Pilot, który w sandboxie wyglądał tanio, na produkcji może okazać się najdroższą pozycją w budżecie.
  • Czas do efektu. Dni na drodze pierwszej, tygodnie na drugiej i piątej, miesiące na trzeciej. Dopasuj drogę do cierpliwości sponsorów projektu.
  • Governance. Kto może zobaczyć to, co widziało AI, i kto zatwierdził to, co zrobiło? Na oba pytania trzeba odpowiedzieć przed go-live, bo dokładanie ścieżek audytu do działającego już rozwiązania AI jest drogie i rzadko kompletne.

W praktyce najczęstszą odpowiedzią jest połączenie kilku dróg: Joule aktywowany tam, gdzie przynosi korzyść, własny agent dla procesu, który naprawdę tego wymaga, gotowy produkt tam, gdzie problem został już rozwiązany, oraz integracja, która to wszystko łączy i pozwala monitorować.

A jeśli nadal pracujesz na ECC

Spora część firm, które pytają o AI, pracuje na SAP ECC, a większość publikowanych wskazówek dotyczy edycji chmurowych. Faktyczny obraz jest taki: droga pierwsza jest na ECC w dużej mierze zamknięta, bo Joule i funkcje embedded AI należą do edycji chmurowych. Jeden niuans: S/4HANA Cloud Private Edition w ramach RISE dostaje Joule, udostępniany przez subkonto BTP, a nie w samym systemie, ale to nie obejmuje ECC ani klasycznych instalacji on-premise. Pozostałe drogi są otwarte: druga, trzecia i piąta działają na BTP obok dowolnego rdzenia, a czwarta nigdy nie zależała od wersji twojego ERP.

Wzorzec side-by-side dla AI na ECC: dane replikowane do SAP HANA Cloud na BTP, rozwiązanie AI przetrwa migrację do S/4HANA

Sprawdzonym wzorcem jest side-by-side. Zreplikuj lub udostępnij potrzebne dane poza rdzeń, na przykład do SAP HANA Cloud, i zbuduj rozwiązanie AI tam, a nie bezpośrednio na ECC. Rozwiązanie komunikuje się z warstwą danych i z API, więc wersja ERP, która za nimi stoi, nie ma dla niego znaczenia. Ten szczegół jest o tyle istotny, że agent lub aplikacja zbudowane w ten sposób mają dużą szansę przejść późniejszą migrację na S/4HANA bez zmian, podczas gdy wszystko, co zostało wpięte bezpośrednio w ECC, będzie trzeba przebudować. Przy takim podejściu prace nad AI stają się pierwszym etapem przygotowań do migracji.

Od czego zacząć

Środowisko hybrydowe brzmi jak więcej decyzji, ale w praktyce sprowadza się do jednej: co wdrożyć najpierw. Zacznij od przypadku użycia i nazwij, czym on właściwie jest: asystentem, którego aktywujesz, agentem, którego budujesz, workflow, który orkiestrujesz, czy aplikacją, którą rozwijasz. Samo nazwanie zwykle zawęża wybór z pięciu dróg do dwóch. Na pierwsze wdrożenia właśnie takich elementów istnieją dziś programy finansowania prowadzone przez partnerów, które opłaca się sprawdzić przed jakąkolwiek rozmową o budżecie.

W kolejnych częściach serii omówimy drogi po kolei: czym naprawdę jest SAP Business AI Platform, co Joule Studio potrafi dziś, a czego jeszcze nie, czego nauczyło nas budowanie na AI Core, gdzie AI realnie pomaga w utrzymaniu integracji i jak wypadają rozwiązania poza ekosystemem SAP.

W Sygeon mamy kompetencję SAP Business AI Platform Expert, najwyższy poziom w programie kompetencji partnerskich SAP, i pracujemy na każdej z dróg z tej mapy, również tych wyprowadzających poza ekosystem SAP. Jeśli zastanawiasz się, którymi drzwiami wejść, skontaktuj się z nami, a pomożemy ci podjąć tę decyzję.

Picture of Autor:

Autor:

Radosław Ruciński

Are you looking for a solution tailored to your needs?

Powiązane artykuły