W projektach SAP Fiori największe znaczenie ma nie sam wygląd ekranu, tylko to, czy aplikacja pasuje do procesu, roli i wersji systemu. Dlatego katalog aplikacji jest tak ważny: pozwala szybko sprawdzić, co naprawdę da się wdrożyć, jakie są wymagania techniczne i czy dany wybór ma sens biznesowy.
Ja patrzę na to narzędzie jak na połączenie dokumentacji, mapy decyzyjnej i listy kontrolnej dla zespołu wdrożeniowego. To właśnie ten katalog, na który wiele osób skrótowo mówi fiori apps library, łączy dokumentację z decyzją wdrożeniową. W tym artykule pokazuję, jak czytać informacje o aplikacjach, jak wykorzystać je przy wyborze rozwiązania i gdzie najłatwiej popełnić kosztowny błąd.
Najkrócej: to katalog, który łączy wybór aplikacji, konfigurację i decyzje wdrożeniowe
- Biblioteka SAP Fiori pokazuje gotowe aplikacje, ich wersje, wymagania techniczne i powiązania z rolami biznesowymi.
- Najbardziej użyteczne pola to App ID, wersja produktu, konfiguracja, zależności i historia poprzednich wersji.
- W praktyce pomaga przy doborze aplikacji, migracji z SAP GUI i Web Dynpro oraz przy ocenie wpływu aktualizacji.
- Wyszukiwanie działa najlepiej po tytule, App ID, semantic object, action i roli użytkownika.
- Rekomendacje z analizy są wskazówką, ale nie zastępują weryfikacji procesu, uprawnień i landscape’u.
Czym jest biblioteka aplikacji SAP Fiori i co właściwie w niej znajdziesz
Oficjalna biblioteka SAP Fiori to centralny katalog, w którym SAP publikuje informacje o gotowych aplikacjach dla różnych obszarów produktu. Znajdziesz tam rozwiązania dla SAP S/4HANA, SAP Business Suite, scenariuszy lighthouse oraz aplikacji na SAP BTP, a także informacje o klasycznych aplikacjach SAP GUI i Web Dynpro, jeśli są one integrowane z launchpadem.
To ważne, bo w projektach biznesowych nie chodzi wyłącznie o „ładny interfejs”. Chodzi o to, czy dana aplikacja wspiera konkretną rolę, czy jest dostępna w danej wersji produktu i jakie kroki są potrzebne, aby ją uruchomić. Z mojego punktu widzenia to właśnie dlatego ten katalog jest bardziej użyteczny niż zwykła lista ekranów. Daje kontekst: funkcjonalny, techniczny i wdrożeniowy.
W praktyce biblioteka odpowiada na trzy pytania naraz: czy ta aplikacja istnieje, co trzeba zrobić, żeby ją uruchomić i czy pasuje do mojego procesu. To właśnie odróżnia ją od luźnych opisów produktu i sprawia, że korzystają z niej nie tylko konsultanci funkcjonalni, ale też architekci, administratorzy i osoby odpowiedzialne za uprawnienia.
To prowadzi do następnego kroku: jeśli katalog ma pomagać w decyzji, trzeba umieć czytać pojedynczą kartę aplikacji bez pomijania technicznych szczegółów.
Jak czytać kartę aplikacji, żeby nie zgubić ważnych zależności
Największy błąd popełnia się wtedy, gdy patrzy się wyłącznie na nazwę aplikacji i krótki opis. W katalogu liczą się też pola, które mówią o wymaganiach wdrożeniowych. Jeśli je zignorujesz, możesz wybrać aplikację, która dobrze wygląda w katalogu, ale w Twoim systemie wymaga dodatkowej konfiguracji, aktywacji usług albo zmiany ról.
| Co sprawdzam | Dlaczego to ma znaczenie | Na co uważam |
|---|---|---|
| App ID | To jednoznaczny identyfikator aplikacji i najpewniejszy punkt odniesienia w dokumentacji. | Nie myl go z nazwą biznesową, bo ta bywa podobna dla kilku aplikacji. |
| Wersja produktu | Pokazuje, w którym wydaniu aplikacja jest dostępna i wspierana. | Ta sama aplikacja może nie być dostępna w każdym systemie lub release. |
| Konfiguracja i prerequisites | Mówią, jakie usługi, role lub komponenty trzeba przygotować przed uruchomieniem. | To zwykle miejsce, w którym wychodzą koszty i czas projektu. |
| Powiązania z rolami biznesowymi | Pomagają ustalić, kto faktycznie ma korzystać z aplikacji. | Nie zakładaj, że sama aplikacja automatycznie rozwiązuje temat uprawnień. |
| Poprzednie wersje | Ułatwiają porównanie zmian i ocenę ryzyka przy upgrade. | Przy większych wdrożeniach to oszczędza czas na analizę regresji. |
| Related resources | Odsyłają do dokumentacji aplikacji, Product Availability Matrix i Maintenance Planner. | To najlepsza droga, gdy trzeba przejść od opisu do realnego planu wdrożenia. |
Wyszukiwanie też jest ważniejsze, niż mogłoby się wydawać. Katalog pozwala szukać nie tylko po tytule, ale również po App ID, semantic object i action. Semantic object to biznesowy obiekt nawigacji, a action to wykonywana na nim operacja. Dzięki temu można znaleźć aplikację nawet wtedy, gdy jej nazwa nie brzmi tak samo jak proces opisywany przez dział biznesowy.
Jeśli chcesz z tego narzędzia wyciągnąć wartość, nie wystarczy „wpisać nazwę i kliknąć”. Trzeba je czytać jak dokument decyzyjny, a to naturalnie prowadzi do pytania, jak użyć go w całym projekcie, a nie tylko przy jednej aplikacji.
Jak korzystać z katalogu w projekcie wdrożeniowym
W dobrze prowadzonym projekcie katalog aplikacji nie jest końcowym etapem, tylko punktem startowym. Najpierw definiuję proces biznesowy i rolę użytkownika, dopiero potem szukam aplikacji, która ma to sensownie obsłużyć. Bez tej kolejności łatwo wpaść w pułapkę „wybraliśmy ekran, teraz dopiero szukamy zastosowania”.
- Opisz proces i rolę - np. księgowy, planista produkcji, handlowiec lub osoba zatwierdzająca dokumenty.
- Wyszukaj kilka wariantów - sprawdź tytuł, App ID, role, semantic object i action, zamiast zatrzymywać się na pierwszym trafieniu.
- Przejrzyj wymagania techniczne - aktywacje, usługi, komponenty backendowe i konfigurację launchpada.
- Porównaj wersje - szczególnie jeśli system jest po aktualizacji albo dopiero planujesz upgrade.
- Zapisz zestaw aplikacji - przy większym scope warto zbudować app selection lub użyć CSV z listą App ID.
- Zweryfikuj dokumentację pomocniczą - to tam zwykle znajdują się szczegóły, których nie widać w samym widoku listy.
W projektach, które analizuję, szczególnie przydatne jest porównanie ról po stronie biznesu i IT. Dla konsultanta funkcjonalnego biblioteka odpowiada głównie na pytanie „czy to wspiera proces”. Dla administratora ważniejsze jest „co trzeba aktywować”. Dla osoby od bezpieczeństwa liczy się „jakie role i katalogi trzeba zbudować”. Tabela poniżej dobrze pokazuje ten podział myślenia.
| Rola w projekcie | Po co zagląda do biblioteki | Najważniejszy filtr lub sekcja |
|---|---|---|
| Konsultant funkcjonalny | Dobiera aplikację do procesu i użytkownika końcowego. | Opis biznesowy, rola, App ID, typ aplikacji. |
| Administrator / basis | Sprawdza wymagania instalacyjne i konfigurację. | Prerequisites, komponenty, konfiguracja, related resources. |
| Specjalista od uprawnień | Mapuje aplikację na katalogi i role biznesowe. | Business role, business catalog, target mapping. |
| Project manager | Ocenia zakres, zależności i ryzyko wdrożenia. | Wersje, lista aplikacji, zależności, zmiany między release'ami. |
Gdy patrzy się na to w ten sposób, biblioteka przestaje być „miejscem do szukania ekranów”, a zaczyna działać jak wspólny język zespołu. I właśnie wtedy najlepiej widać jej wartość przy analizie rekomendacji oraz upgrade'ów.
Dlaczego biblioteka pomaga przy rekomendacjach i aktualizacjach
Jedną z mocniejszych funkcji jest analiza rekomendacji aplikacji. SAP pozwala oprzeć ją na profilu użycia i profilach systemowych, żeby wskazać aplikacje najlepiej pasujące do tego, co użytkownicy rzeczywiście robią w systemie. To szczególnie przydatne, gdy zaczynasz od istniejącego środowiska SAP GUI i chcesz rozsądnie przejść w stronę Fiori, zamiast przenosić wszystko bez selekcji.
Nie traktuję jednak rekomendacji jak automatycznej decyzji. To raczej dobrze przygotowana sugestia. Jeśli w danych źródłowych brakuje porządnych informacji o użyciu transakcji, wynik też będzie tylko tak dobry, jak ten input. Dlatego w praktyce trzeba go jeszcze potwierdzić z biznesem i z technicznym stanem systemu.
W podobny sposób działa analiza wpływu aktualizacji. Jeśli planujesz upgrade, chcesz wiedzieć, które aplikacje mogą się zmienić, które wymagają dodatkowej weryfikacji i gdzie pojawi się ryzyko regresji. W katalogu można też analizować poprzednie wersje aplikacji, co bardzo ułatwia porównanie przed i po zmianie.
| Sytuacja | Co daje biblioteka | Jakiej odpowiedzi szukam |
|---|---|---|
| Start migracji z SAP GUI | Wskazuje aplikacje odpowiadające używanym transakcjom. | Czy da się zastąpić klasyczny proces lepszym ekranem Fiori. |
| Planowanie upgrade'u | Pokazuje wpływ zmian i wcześniejsze wersje aplikacji. | Co trzeba sprawdzić przed zmianą release'u. |
| Budowa listy scope dla projektu | Pozwala zapisać wybrane aplikacje i eksportować je z pomocą CSV. | Jak zamknąć zakres wdrożenia w konkretnych pozycjach. |
| Projekt wieloobszarowy | Ułatwia porównanie wielu aplikacji i scenariuszy. | Które procesy warto wdrożyć od razu, a które zostawić na kolejną falę. |
To jest właśnie moment, w którym katalog zaczyna pracować na wynik projektu, a nie tylko na jego dokumentację. Żeby jednak nie przecenić narzędzia, trzeba też znać jego ograniczenia i typowe błędy użytkowników.
Najczęstsze błędy, które widzę przy pracy z katalogiem
Najbardziej kosztowny błąd jest zaskakująco prosty: szukanie aplikacji wyłącznie po nazwie. W praktyce jedna nazwa biznesowa może prowadzić do kilku ekranów, wersji lub typów aplikacji. Dlatego lepiej zacząć od procesu, roli i App ID, a dopiero potem od samego tytułu.
- Ignorowanie wersji produktu - aplikacja może istnieć, ale nie w Twoim release albo nie w tej odmianie systemu.
- Pomijanie konfiguracji - bez prerequisites łatwo zaniżyć czas i koszt wdrożenia.
- Mylenie dostępności z gotowością - to, że aplikacja jest opisana w katalogu, nie znaczy jeszcze, że działa w Twoim landscape.
- Traktowanie rekomendacji jako decyzji końcowej - analiza podpowiada kierunek, ale nie zastępuje weryfikacji procesu i uprawnień.
- Pomijanie klasycznych aplikacji - w przejściu na Fiori nadal mogą być potrzebne SAP GUI lub Web Dynpro podpięte do launchpada.
Warto też pamiętać o jednym ograniczeniu, które często umyka na początku projektu: katalog nie rozwiązuje problemu projektowego sam z siebie. On pokazuje możliwości, ale nadal trzeba podjąć decyzję, które scenariusze są ważne dla firmy, które warto uprościć, a które zostawić bez zmian. Z perspektywy systemów biznesowych to spora różnica.
Właśnie dlatego najlepsze efekty daje praca na małym, dobrze opisanym wycinku procesu zamiast na szerokiej, chaotycznej liście aplikacji. Gdy to zadziała dla jednego obszaru, łatwiej przenieść metodę na kolejne.
Co sprawdzam przed wdrożeniem, żeby katalog przełożył się na realną wartość
Gdybym miał zamknąć ten temat w jednej praktycznej zasadzie, powiedziałbym tak: najpierw proces, potem aplikacja, na końcu dopiero konfiguracja. Taka kolejność oszczędza czas, bo ogranicza zbędne dyskusje o ekranach, które nie pasują do rzeczywistej pracy użytkowników.
Przed decyzją o wdrożeniu konkretnej aplikacji sprawdzam jeszcze cztery rzeczy: czy proces biznesowy jest jasno opisany, czy wersja produktu zgadza się z landscape'em, czy wymagane uprawnienia i aktywacje są realne do przygotowania oraz czy istnieje sensowna alternatywa wśród innych typów aplikacji. Dopiero wtedy mam podstawę, by powiedzieć, że wybór jest nie tylko technicznie poprawny, ale też biznesowo uzasadniony.
Jeśli w firmie pracuje zespół mieszany, to właśnie tutaj biblioteka daje największy zwrot. Biznes widzi, co aplikacja ma usprawnić, IT widzi, co trzeba uruchomić, a projekt nie rozjeżdża się między wymaganiami a implementacją. Dla mnie to najuczciwszy sposób korzystania z SAP Fiori Apps Reference Library: nie jako katalogu ekranów, lecz jako narzędzia porządkującego decyzje wokół całego procesu.
W praktyce zaczynam od jednego procesu i jednej roli, a dopiero potem rozwijam zakres na kolejne obszary. To daje lepszą kontrolę nad wdrożeniem i szybciej pokazuje, czy wybrana aplikacja rzeczywiście przynosi wartość.
