To jest 184. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o budowie i wdrożeniach SAP. Przypominam, że w poprzednim odcinku rozmawiałem o tym, jak budować markę osobistą w IT. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/184. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, pomagasz w realizacji tej misji. Dlatego już dziś wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Ja natomiast bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania!

Odpalamy!

 

Cześć!

Mój dzisiejszy gość to konsultant SAP z 16-letnim doświadczeniem, absolwent studiów informatycznych na Uniwersytecie Łódzkim, specjalizacja Sztuczna inteligencja i inżynieria programowania. Doświadczenie zbierał w różnych projektach, od pełnych wdrożeń, poprzez szkolenie i wsparcie dla użytkowników, po projekty optymalizujące i rozwijające pracę fabryk. Moim i Waszym gościem jest Adam Szeżeński.

 

Cześć, Adam! Bardzo miło mi gościć Cię w podcaście.

 

Cześć! Dzień dobry wszystkim.

 

Dzisiejsza rozmowa z Adamem będzie wprowadzeniem do ekosystemu SAP, porozmawiamy o tym, czym właściwie jest SAP, gdzie się sprawdza, gdzie jest wykorzystywany, jaką ma budowę, a także o tym, jak wygląda praca wdrożeniowca, konsultanta SAP, skorzystamy z bogatego doświadczenia Adama.

Ale zanim do tego przejdziemy, to chciałbym zapytać Cię, Adam, jak każdego mojego gościa, o to, czy słuchasz podcastów. Jeżeli tak, to może masz jakieś fajne audycje, o których warto tutaj wspomnieć?

 

Tak, ja bardzo dużo słucham podcastów, i to od 10 lat. To jest w sumie jedyna taka forma audycji, na którą mam czas, więc przeglądając sobie w pamięci podcasty, których obecnie słucham (bo tych, które już się skończyły, niestety nie pamiętam nazw), to Brzmienie świata z lotu drozda, Cyber, cyber, Dział zagraniczny, Dzień dobry podatki, Finanse bardzo osobiste, Finansowe sensacje tygodnia, Historia, jakiej nie znacie, Inwestomat, Kompot Nauka XXI wieku, Po ludzku o pieniądzach, Podcast radioaktywny, Podniebne historie, Podróż bez paszportu, Układ otwarty, Raport o stanie świata, Za rubieżą i Radio naukowe. Chciałem wymienić wszystkie, które bardzo sobie cenię.

Jak widzisz, nie ma tutaj podcastów branżowych poza dwoma takimi malutkimi, ale to celowo, żeby znaleźć odskocznię od codziennej pracy.

 

Super, dzięki za te rekomendacje. Sporo podcastów, ale to też pokazuje, że jest mnogość różnych tematów, wątków, które można znaleźć w podcastach, i każdy może znaleźć dla siebie coś atrakcyjnego. Myślę, że na podstawie Twoich rekomendacji słuchacze będą w stanie sobie wybrać coś, co ich zainteresuje – dzięki za to.

Przejdźmy do takiej bardzo fundamentalnej rzeczy, ale myślę, że warto też to usłyszeć od Ciebie, czyli czym właściwie jest SAP. To nam pozwoli później opowiadać o tym, jaką ma budowę, gdzie jest wykorzystywany itd.

 

Tak pokrótce SAP to jest producent. Tak się nazywa firma, która wiele lat temu wypuściła produkt i nazwała go tak samo. Jest to produkt komputerowy klasy ERP, czyli system do zarządzania przedsiębiorstwami, a zwłaszcza jego procesami. Ponieważ firma SAP skupuje z rynku wiele technologii, to można już teraz spotkać inne produkty, które mają to słowo SAP w nazwie, np. SAP One. Jest to jakby młodszy brat tego dużego, docelowego SAP-a, ale jeżeli potocznie mówimy słowo 'SAP’, to chodzi nam o ten duży system do zarządzania przedsiębiorstwami i jego procesami.

 

Właśnie, w takim powszechnym mniemaniu SAP jest zazwyczaj kojarzony z czymś dużym, z czymś, co ma mnóstwo modułów, co jest obszernym oprogramowaniem, więc myślę, że warto byłoby powiedzieć, z jakich modułów, z jakich obszarów SAP się składa, żeby później zrozumieć, gdzie możemy go zastosować.

 

Ten najpopularniejszy produkt nazywał się ERP R/3, wersja trzecia. Teraz jest wprowadzony na rynek S/4HANA, ale o historii nazwy trochę później, i ten produkt składa się z modułów, ale to są moduły dostarczane wraz z SAP-em w momencie zakupu, więc to nie jest tak, że te moduły trzeba dokupować. One są bardzo silnie ze sobą powiązane. Podział na moduły w systemie SAP jest bardziej po to, żeby zorganizować pracę, zarówno przedsiębiorstwa, jak i konsultantów. Z grubsza jest to jeden wielki system do wielu zadań.

Jeżeli sobie wyobrazimy takie przedsiębiorstwo, to przeważnie ono coś sprzedaje, kupuje, produkuje. Zatem moduł sprzedaży pozwala zarejestrować zlecenie klienta, jeśli jest to firma handlowa, to ta integracja powoduje, że system od razu wie, czy są dostępne materiały, które chcemy sprzedać, a jeśli nie, to kiedy one będą, kiedy da się je wyprodukować, i od razu dział zaopatrzenia wie, że musi to kupić. Na podstawie tzw. kartotek podstawowych, kartotek dostawców wiemy od kogo to kupić i na kiedy to będzie. 

I podobnie, jeżeli to jest firma produkcyjna, to potrafi wesprzeć planistów w procesie produkcji. Czyli zaraz po tym, jak się pojawi zapotrzebowanie na sprzedaż, system potrafi określić, na kiedy będzie można to wyprodukować, a planiści mogą sprawdzić, czy mają kim i czym to wyprodukować. Jak odbędzie się już cały proces nabycia, to magazyn to przyjmuje, potrafi przepakować, spakować, wysłać i wystawić fakturę. I to jest w pakiecie. Czyli jeden system do wszystkiego.

I teraz, żeby zorganizować trochę pracę, to tak jak w działach firmy, jest dział zaopatrzenia, dział sprzedaży, podobny podział jest w SAP-ie. Czyli np. moduł księgowości nazywa się FI, moduł sprzedaży SD (od sales and distribution), gospodarka materiałowa ogólnie się nazywa MM (od material management), ale tak naprawdę jest to też dobry przykład modułu, który też dzieli się na mniejsze podmoduły, które służą do zarządzania danymi produktów, zapasami oraz procesem zaopatrzenia.

Jest jeszcze bardzo ciekawy moduł controllingu i rachunkowości wewnętrznej, tzw. CEO. I mój ulubiony moduł: produkcja. Czyli planowanie, wykonanie produkcji, czyli PP. To są moduły, które są najczęściej wykorzystywane. Ale są też jeszcze moduły takie jak moduł wspomagający zarządzanie jakością (QM), moduł do projektów (PS), moduł HR-owy, moduł gospodarki typowo magazynowej (WE).

To jest taki klasyczny podział. Niektórzy, szukając obecnie informacji, mogą być trochę zmyleni, bo SAP od czasu do czasu trochę przemeblowuje to nazewnictwo i to też czasami myli np. head hunterów, bo czasami te moduły są łączone w bardziej ogólne nazwy, np. moduł logistyczny. Czasami trzeba się dopytać, co dana osoba miała na myśli. Ten podział, który przed chwilą przedstawiłem, jest taki najbardziej klasyczny i najczęściej spotykany.

 

Czyli mamy całkiem sporo modułów i domyślam się, że w danym przedsiębiorstwie możemy wykorzystać wszystkie, ale też niekoniecznie, prawda? Możemy się skupić na kilku, które są nam w jakiś sposób potrzebne. Domyślam się, że tutaj właśnie na scenę wkracza konsultant, który jest potrzebny, żeby spiąć te różne moduły, skonfigurować, odpowiednio ustawić. I Twoje drogi zawodowe nieco przypadkowo skierowały Cię właśnie w stronę SAP-a i bycia konsultantem. Chciałbym Cię zapytać, jak wygląda praca konsultanta SAP. Czym on się zajmuje?

 

1/3 to jest praca z systemem, ale wbrew pozorom pozostałe 2/3 to praca z innymi ludźmi, bo oprócz systemu mamy jeszcze innych konsultantów, innych programistów (programista w SAP-ie się nazywa abapter, dlatego że SAP sam w sobie jest napisany w języku ABAP i po prostu tak się mówi na programistów). Jak zauważyłeś, tych modułów jest bardzo dużo, więc w efekcie w takim projekcie czy firmie musimy rozmawiać z wieloma kolegami i koleżankami, musimy się z nimi dogadać, a przede wszystkim jest nasz kochany klient końcowy – obojętnie, czy jesteśmy działem wewnętrznym SAP-a, czy idziemy na wdrożenie do kogoś, są tam ludzie i zwykli użytkownicy, którzy mniej lub bardziej wiedzą, co to jest SAP.

Trzeba też wiedzieć, że system SAP to produkt półkowy. On ma swoją logikę, trochę ją narzuca firmie i konsultanci wiedzą z doświadczenia, co może się nadawać dla danej firmy, ale prawda jest taka, że każde przedsiębiorstwo ma swoje procesy, swoją specyfikę, swoje problemy i głównym zadaniem konsultanta jest poznanie i zrozumienie tych problemów. I trzeba te procesy zamodelować.

To brzmi prosto, ale działanie w systemie to ta łatwiejsza część, tzn. to jest skończona liczna kombinacji. Różnorodność tych firm i procesów powoduje, że mamy do czynienia z różnymi ludźmi. Pamiętam, że moje pierwsze szkolenie zaczęło się od tego, że musiałem komuś tłumaczyć, jak obsługiwać komputer. Nie SAP-a. Komputer. Ale są też użytkownicy bardzo zaawansowani w tym, co robią, i dlatego trzeba wyczuć, z jaką grupą się ma do czynienia, i co innego można zaproponować doświadczonemu użytkownikowi, który wiele lat pracował w SAP-ie, a co innego osobie, która dopiero zaczyna pracę z tym systemem albo w ogóle z jakimkolwiek systemem komputerowym.

I są jeszcze nasi koledzy i koleżanki. Bo jeżeli się idzie na projekt, to się odpowiada tylko za pewien wyrywek, czyli nasz konkretny moduł. I trzeba te procesy uzgodnić z innymi konsultantami, czyli innymi modułami, żeby wszystko działało spójnie.

 

Ciekawe, bo raczej spodziewałem się, że konsultant całościowo obejmuje wdrożenie. A z tego, co mówisz, wynika, że dany konsultant zajmuje się pojedynczym modułem i jego rolą jest też, żeby dogadać się z innymi konsultantami, którzy zajmują się innymi modułami.

 

Tak, czasami na projekcie występuje tzw. architekt albo analityk biznesowy, który właśnie na podstawie swojego doświadczenia widzi całość tego procesu, ale on też czasami nie ma na tyle szczegółowej wiedzy, żeby zejść do każdego modułu i na poziomie detali wszystko dograć. Więc czasami się zdarza, że taka osoba jest i jest to taki architekt.

 

Ja też podzielam i zauważam to, co mówiłeś, jeśli chodzi o ogłoszenia o pracę dedykowane systemowi SAP-owemu, bo nieraz nie do końca wiem, kogo tak naprawdę ta firma poszukuje. I myślę sobie, żeby tutaj naprowadzić trochę rekruterów, ale to też nam się przyda, gdy będziemy mówić o ścieżkach kariery. Chciałbym Cię poprosić, żebyś powiedział, jakie występują role w ekosystemie SAP. Trochę już powiedziałeś na ten temat, ale myślę, że dobrze byłoby to zebrać w jedną całość.

 

Przede wszystkim jest użytkownik końcowy. Może to nie jest praca typowo SAP-owa, ale to jest pracownik firmy wykorzystujący SAP-a. I w sumie to najważniejszy element, bo wszyscy następni, których zaraz wymienię, pracują po to, żeby ten użytkownik końcowy dobrze i efektywnie to wykonywał. To jest pierwsza rola. Druga to tzw. key userzy albo zaawansowani użytkownicy. To są osoby, które np. dłużej pracują w firmie i mają doświadczenie od strony procesów i wiedzą, dlaczego coś się wykonuje – bo to też bardzo ważny element przy wdrożeniach i poznaniu klienta: mieć użytkownika końcowego, który odpowiada od strony biznesu za ten wycinek pracy, którą my musimy wykonać.

Następną osobą jest konsultant modułowy. Są różne stopnie zaawansowania konsultantów – junior, zwykły konsultant i bardziej zaawansowani. To są te konkretne osoby, które odpowiadają za cały proces wdrożenia danego modułu. Oprócz tego, że występuje podział na doświadczenie konsultantów, zwłaszcza przy rekrutowaniu się do jakiejś firmy, jest kolejna różnica, bo możemy się zatrudnić u klienta końcowego w wewnętrznym dziale wsparcia lub też być konsultantami zatrudnionymi do wdrożenia jakiegoś wycinka, implementacji SAP-a w nowej fabryce czy kompletnie nowej funkcjonalności. I to są dwie różne rzeczy.

Jest jeszcze nasz nieodzowny basis. To jest taki moduł SAP-a, który odpowiada za to, żeby to wszystko działało, czyli serwery, uprawnienia; są to konsultanci bardzo techniczni. I w zależności od stażu konsultanci dostają też role specjalne: analityka lub architekta. Chodzi o to, aby wszystkie procesy i wymagania ze sobą pospinać, bo jak widzimy budowę modułową, to te moduły muszą na samym końcu ze sobą współgrać. I taka doświadczona osoba wie, czy dane rozwiązanie się sprawdzi, i może od razu zobaczyć czy np. dane wymaganie jest sensowne, czy nie. 

Bo analityk i architekt to trochę dwie różne osoby. Analityk to osoba, która nakierowuje klienta, jakie funkcjonalności w SAP-ie można wdrożyć i w jaki sposób to zrobić, a architekt to osoba, która nadzoruje całość technicznego rozwiązania, żeby to miało sens i żeby dobrze współgrało.

 

Przede wszystkim jest użytkownik końcowy. Może to nie jest praca typowo SAP-owa, ale to jest pracownik firmy wykorzystujący SAP-a. I w sumie to najważniejszy element, bo wszyscy następni, których zaraz wymienię, pracują po to, żeby ten użytkownik końcowy dobrze i efektywnie to wykonywał. To jest pierwsza rola.

 

Wspomniałeś przynajmniej o kilku rolach, które są analityczne i są związane z tym, żeby to wdrożenie mogło przebiec skutecznie, czyli, powiedzmy, od zebrania jakichś wymagań od strony klienta, później zrozumienie jego specyfiki i dobranie rozwiązania do jego problemu. Więc chciałbym Cię zapytać, czym te projekty SAP-owe się różnią. Dlaczego nie da się zainstalować po prostu oprogramowania i uruchomić go takim, jakim ono jest i już na nim działać? Na czym polega ich specyfika?

 

Teraz występuje bardzo dużo rodzajów projektów, bo taki proces, w którym firma kupuje SAP-a i go instaluje, nazywam po prostu wdrożeniem od zera, kolokwialnie mówiąc, bo są jeszcze inne rodzaje nie tyle wdrożeń, ile projektów, na które możemy być zatrudnieni. Jest to rollout, wsparcie lub coś, co ja nazywam projektami ulepszeniowymi.

Wdrożenie od zera to proces, kiedy firma kupuje SAP-a i potrzebuje go do siebie dostosować – to jest kluczowe słowo, bo kupując SAP-a, kupuje się jakiś zestaw od strony biznesu, też jak dane procesy powinny wyglądać. Często takie firmy rozrastają się i chcą te procesy ustabilizować. SAP trochę narzuca formę działania przedsiębiorstw i takie wdrożenie polega przeważnie na tym, że do tej pory działał jakiś system, często pisany przez własnych informatyków albo na zamówienie i z tego istniejącego systemu trzeba się przesiąść i zamodelować te procesy od nowa w SAP. 

I tu są dwa rodzaje wyzwań. Po pierwsze jest naturalny odruch klienta, aby mieć tak, jak było. On z jednej strony oczywiście mówi, że chciałby się rozwijać, ulepszać, ale z drugiej strony mamy użytkowników, którzy znają swoje procesy i myślą, że dotychczasowy sposób działania jest optymalny.

 

Czyli jest opór.

 

Tak, czasami jest opór materii. I trzeba wypośrodkować. Nie można wdrożyć, dać użytkownikowi za dużo na raz, bo on się pogubi, bo ma swoją własną pracę do wykonania, plus musi się nauczyć i przestawić ze starego procesu.

Chodzi o to, że marketingowo i na papierze ten system jest naprawdę duży. Znam go na tyle, że wiem, że potrafi pokryć naprawdę wiele obszarów. Tylko pytanie, czy mamy wystarczająco zasobów ludzkich, żeby to zrobić od razu. Dlatego przy takich wdrożeniach trzeba to wypośrodkować; co da nam największy zysk, a pozostałe moduły, funkcjonalności można z czasem rozwijać. Bo one są już kupione, mamy do nich prawo, tylko trzeba je wdrożyć.

Takie typy projektów występują już coraz rzadziej. One na początku w Polsce występowały bardzo często, bo była premia za opóźnienie i wiele firm to instalowało. Teraz częściej takie projekty prawie od zera nazywają się rollouty, czyli też takie wdrożenie od zera, ale w ramach firmy. Najczęściej są to sytuacje, kiedy jedna firma kupuje drugą firmę albo buduje nową fabrykę i ta nowa fabryka czy sklep, czy cokolwiek musi dołączyć do istniejącego ekosystemu, trzeba ją zintegrować z procesami. 

Tutaj wyzwaniem jest zaadaptowanie istniejących procesów w firmie. Też podobnie, bo jeżeli jest to np. kupiona firma na rynku, to ona też może mieć własny system, ale jedna rzecz jest łatwiejsza: firma matka narzuca procesy, które muszą być, i tu jest mniej dyskusji z klientem pod tym względem i taki krótszy koncert życzeń, jak ja to mówię. A w takich roll outach bardzo dobrze sprawdza się zespół wewnętrzny lub osoby, które długo współpracują z daną firmą matką, i wtedy mówi się, że wdrażają tzw. template, czyli przenosi się taki wzorzec z innych fabryk. 

Dodatkowo najczęściej ze względów lokalizacyjnych dobierani są lokalni konsultanci, w sensie krajowi. Z dwóch powodów: językowych, bo o ile osoby biurowe znają język angielski i nie jest to problem komunikacyjny, o tyle osoby na innych, niebiurowych funkcjach nie muszą znać języka angielskiego i wtedy taki konsultant jest też zatrudniany, żeby móc wyszkolić takie osoby. I jest jeszcze to, że specyfika podatkowa w niektórych krajach jest na tyle zawiła, że nasi zachodni koledzy np. nie zawsze rozumieją specyfikę polską. I tutaj bardzo dobrze się odnajdują lokalni konsultanci FI. 

Są jeszcze teraz takie projekty, które nazywam 'wsparcie’, tylko że to jest wbrew pozorom dosyć szeroki obszar, bo to jest zarówno rozwiązywanie bieżących problemów, jak i rozwój istniejących procesów w ramach firmy. Brzmi trywialnie, ale czasami wiąże się to z większymi zmianami, rozbudowami, np. roll outami. Czyli zespół wsparcia może też służyć jako taki zespół wdrożeniowy w przypadku, kiedy się pojawia nowa fabryka w przedsiębiorstwie. 

A oprócz rozwiązywania takich bieżących problemów i zgłoszeń, tzw. ticketów, sama firma potrafi się rozrastać. I jeżeli coś kiedyś, na samym początku było dobre, bo produkowaliśmy daną rzecz w ilości 100 sztuk dziennie, to dajmy na to proces jakościowy: 1% odrzutów – trzeba było ręcznie w systemie tylko jedną sztukę, ale kiedy firma się rozrasta i nagle z tych 100 sztuk dziennie robi się nam 10 tys. albo 100 tys., to ręczne obsługiwanie 1% ilościowo już ma znaczenie. 

Dlatego w wielu firmach teraz kładzie się nacisk na udoskonalenie tego, co mamy. Bo do tej pory te ręczne procesy wystarczyły, zwłaszcza że firmy borykają się też z tym, że siła ludzka zaczyna być coraz mniej dostępna, kiedyś nie było to takim tematem, i coraz więcej wysiłku od strony firm jest kładzione na to, żeby automatyzować te procesy w SAP-ie. Czasami są to mini automatyzacje, czasami wdrożenie nowego modułu. Bo jak wymieniałem te moduły najczęściej wykorzystywane, to zaznaczyłem, że są też popularne moduły wykorzystywane rzadziej, ale nie rzadko. 

I właśnie one wtedy dołączają do rodziny, bo nagle okazuje się, że w modelu jakościowym mamy już taką skalę, że musimy śledzić tę jakość, albo jakieś wdrożenie jakichś procedur tego od nas wymaga. Więc tutaj takie projekty à la wsparcie to nie są tylko same tickety, zwłaszcza że jest jeszcze ten czwarty rodzaj projektów, który może być wykonywany zarówno przez działy wewnętrzne, jak i przez zewnętrznych konsultantów zatrudnianych pod projekt: ulepszenia. A więc integracje lub nowe moduły.

 

Tych rodzajów projektów jest przynajmniej kilka i domyślam się, że różne role mogą też w nich uczestniczyć, więc żeby jeszcze troszkę skomplikować systuację, to chciałbym Cię zapytać o temat, który jest teraz gorący w świece SAP, czyli S/4HANA. Czym ten produkt jest, w jaki sposób powstał, do kogo jest adresowany?

 

Żeby zrozumieć, skąd wzięła się nazwa: dawno temu firma SAP wypuściła produkt, który się nazywał SAP Routing Financial, skrót R/F. To było dosyć dawno , kiedy mnie jeszcze nie było nawet w planach. Następnie był udoskonalony produkt, który został nazwany SAP R/2. I ten zintegrowany system SAP, o którym mówimy, ma nazwę SAP R/3, czyli to jest jakby trzecia wersja tego systemu, teraz wymiennie nazywa się też SAP ECC. Kolejna jego wersja ma w sobie czwórkę, a oprócz tego SAP sobie wymyślił, że zmieni podejście do bazy danych. HANA nie oznacza wersji systemu, tylko wersję bazy danych, na której ten program pracuje. 

I to, co najciekawsze dla mnie jako konsultanta, to zmieniona architektura przechowywania danych. Czyli jeżeli mamy pewne rekordy w bazie danych, użytkowników albo po prostu naszych obywateli, to jeżeli ktoś się ostatnio rozliczał albo coś, to jest czasami takie pytanie, które sobie oni zaznaczają w bazie danych: czy mamy znajomego polityka? Chodzi o to, że żeby przechowywać tę informację, czy mamy jakiegoś polityka w rodzinie albo coś tego typu, to musimy mieć 38 mln komórek z odpowiedzią ‘tak’ lub ‘nie’. 

Układ w HANIE polega na tym, że to pytanie jest zadawane inaczej: którzy obywatele znają jakiegoś polityka. I okazuje się, że ilość danych, które trzeba w ten sposób przechowywać, jest znacznie mniejsza. I przez to mieści się w pamięci, bo do przechowywania tych informacji nie potrzeba klasycznych baz talerzowych, ale ta informacja da się przechowywać w pamięci, zwłaszcza że one tanieją. I cały ten koncept nazwano HANA. 

Baza danych HANA. To jest ten drugi człon nazwy. A ten pierwszy wynika z tego, że kilka lat temu ktoś próbował przeliczyć, że sam ten core’owy, czyli główny moduł SAP-a gdyby ktoś próbował napisać od początku, to potrzeba byłoby ok. 30 tys. osobo-dni. Trochę sporo.

W dodatku, jak już wspomniałem, ten system był pisany, kiedy mnie jeszcze nawet nie było w planach, a na przestrzeni lat zmieniał się sposób pisania, ewoluowała cała architektura oprogramowania i tak samo SAP i w pewnym momencie SAP zebrał te wszystkie najlepsze rzeczy i doświadczenia, a ponieważ w międzyczasie produkował też kilka innych produktów lub rozwijał je jednocześnie, to podobierał ciekawe rozwiązania, postawił też na nowy, odświeżony wygląd, tzw. fiori, i to wszystko nazwał SUITE. 

I teraz, jeżeli zbierzemy to wszystko, to S/4HANA to jest Suite 4 HANA, czyli ta czwórka jest grą słów, że jest to nowe wydanie pod HANĘ. Stąd się wzięła ta nazwa. Nie chcę też marketingowo tu chwalić SAP-a, ale wg statystyk przeszło 90% największych firm na świecie jest przez niego obsługiwana. SAP się chwali, że większość produktów, które na co dzień kupujemy, przechodzi przez ten system. Ale chodzi o to, że oni się chwalą, że mają ok. 400 tys. klientów i każdy niech ma średnio po 100 użytkowników, wtedy mamy do czynienia z kilkoma milionami osób używających SAP-a.

I jeżeli każdy by zostawał przy produkcie półkowym, to łatwo można by przeprowadzać ten upgrade, ale praktycznie każda firma ma swoje lokalne dostosowania i rozwiązania, tzw. rozwiązania zetowe. Bo taka jest przyjęta nomenklatura, że jeżeli chcemy napisać własny program w SAP-ie albo własny proces, to się go nazywa na Z. Czyli to są rozwiązania, których nie dostarczył SAP, tylko konsultant przy pomocy programisty stworzył coś nowego.

I w efekcie okazuje się, że te rozwiązania są w każdej firmie i są od strony producenta nieudokumentowane, ale po aktualizacji one też muszą działać. Dlatego to wszystko tworzy cały ekosystem, bardzo skomplikowany.

 

Żeby zrozumieć, skąd wzięła się nazwa: dawno temu firma SAP wypuściła produkt, który się nazywał SAP Routing Financial, skrót R/F. To było dosyć dawno , kiedy mnie jeszcze nie było nawet w planach. Następnie był udoskonalony produkt, który został nazwany SAP R/2. I ten zintegrowany system SAP, o którym mówimy, ma nazwę SAP R/3, czyli to jest jakby trzecia wersja tego systemu, teraz wymiennie nazywa się też SAP ECC. Kolejna jego wersja ma w sobie czwórkę, a oprócz tego SAP sobie wymyślił, że zmieni podejście do bazy danych. HANA nie oznacza wersji systemu, tylko wersję bazy danych, na której ten program pracuje.

 

Czy mamy tutaj jakąś perspektywę czasową, w której wszystkie te moduły opisane pod klienta muszą zostać zmigrowane, czy są w ogóle jakiekolwiek ograniczenia czasowe albo inne?

 

Tak, SAP zaproponował jakiś termin, w którym stare wersje systemu są wspierane, ale już go kilkukrotnie przesuwał. Bo okazuje się, że przez to nagromadzenie rozwiązań klienckich każdy klient ma jakieś dodatkowe interfejsy. Okazuje się, że nie tak łatwo to zmigrować. Trzeba przede wszystkim naświetlić to, że firma jak się rozwija, to ona nie tylko wdraża nowe moduły, ale właśnie przeważnie klient ma te zetowe rozwiązania i to każda firma robi pod swoje procesy dla siebie i nie zawsze zgodnie z tym, co SAP sobie założył, jak to ma wyglądać. 

Ja mówię, że SAP to jest trochę taka stara rzeka. Jeżeli my podczas wsparcia, wdrożeń i implementacji jakichś nowych rzeczy postępujemy zgodnie z ogólnymi wytycznymi, jak te procesy miałyby wyglądać, to podczas jakichkolwiek upgrade’ów, nawet zwykłych poprawek, to nie jest problematyczne, bo SAP zakłada, że postąpiliśmy zgodnie z jego wytycznymi. Ale czasami ze względów czasowych, pieniężnych oraz takich, że czasami niektóre SAP-owe rozwiązania wydają się zbyt duże lub zbyt drogie, to pisze się zupełnie własną logikę. I jeżeli ta logika podąża z nurtem tej rzeki, to mamy mniej kłopotów przy upgrade’ach, ale jeżeli ona idzie w poprzek, to niestety każdy upgrade powoduje że mamy problem z utrzymaniem tego głównego nurtu. I problemem są te rozwiązania klienckie i interfejsy.

 

Właśnie, to opowiedz może, jak firmy sobie radzą z tą migracją, jakiego typu projekty z S/4HANA w ogóle istnieją i jakie znasz podejścia do tego problemu.

 

Przede wszystkim są to nowe wdrożenia, bo jeżeli ktoś kupuje SAP-a, to takie nowe wdrożenie na S/4HANA nie różni się niczym od starego wdrożenia przy R/3. Dla użytkowników, dla firm jest to obojętne, nie muszą migrować, tylko uczą się wszystkiego od nowa. Niestety stare firmy mają trochę gorzej, bo ten bagaż historii, wersji SAP-a, o których wspomniałem, nie dotyczy tylko SAP-a jako firmy i produktu, ale też firm, w których ten SAP się rozwijał, czyli klientów końcowych. Przecież te firmy się rozrastały, kupowały siebie nawzajem, każda firma ma swoje klienckie rozwiązania, każda firma inaczej je programuje, inaczej je integruje, w dodatku mamy do czynienia z kilkoma milionami osób, które go używają, mają swoje przyzwyczajenia, bo tych przyzwyczajeń użytkownika też nie można lekceważyć i kiedy mamy nagle do czynienia z produktem półkowym, który musimy zaktualizować, mamy czasami bardzo dużo pracy. 

I firma musi przeanalizować to, co do tej pory u siebie zrobiła, i zadecydować, czy idzie w tzw. brown field czy green field. To są popularne nazwy, brown oznacza to, że próbujemy zmigrować to, co mamy. Można to porównać do przejścia na nową wersję systemu operacyjnego. Nie czyścimy dysku, nie czyścimy naszego pulpitu, tylko przesiadamy się na nową wersję. A green field próbujemy zamodelować w firmie wszystko od początku.

I jeżeli wybierzemy to przeinstalowywanie samego systemu i chcemy te wszystkie nasze dotychczasowe procesy zostawić, to robimy upgrade i staramy się zachować wszystko tak, jak działało do tej pory. I tutaj brzmi to prosto, ale w zależności od tego, jak bardzo SAP jest przerobiony, tyle mamy problemów. 

Żeby było jasne: powodem jest nie tylko firma i jej przeróbki. Jest wiele elementów systemu SAP, które też zostały zmienione, bo SAP jako firma też się uczyła i niektóre nowsze pomysły zastępują stare, więc w efekcie mamy tutaj dwa światy: zamierzenia SAP-a jako firmy, która chciałaby narzucić swój produkt, oraz zamierzenia tych kilkuset tysięcy klientów, z których każdy podążył własną drogą. 

I z jednej strony trzeba przeanalizować problemy techniczne i techniczne dostosowanie interfejsów, i to jest trochę podobne do projektów ulepszeniowych, po prostu konsultanci muszą usiąść, zobaczyć, co będzie działać, co nie. Ale czasami okazuje się, że stara funkcjonalność, lubiana przez użytkowników, niestety z powodu pomysłu SAP-a na nowy proces przestaje funkcjonować. I czasami to są trywialne procesy, które trzeba od nowa przystosować, bo przyzwyczajenie jest drugą naturą człowieka. 

I do brown field można podejść na dwa sposoby, w sumie nawet trzeba, bo jest część funkcjonalności, które SAP wymaga, żeby pojawiły się wcześniej, jeszcze w starej wersji, żeby móc w ogóle zacząć migrację do S/4HANY. Więc proces takiego przejścia naturalnie się wydłuża. Jest to pewna zaleta, bo wtedy nie mamy wszystkiego naraz w tym upgradzie głównym, nie mniej jednak można powiedzieć, że mamy pełno mniejszych bądź większych projektów usprawnieniowych. Jeżeli jeszcze są jakieś ograniczone zasoby, zarówno od strony konsultantów (bo też ich nie ma za dużo), jak i użytkownicy też muszą przecież wykonywać swoją pracę, a w dodatku czasami nie można tak po prostu przepiąć systemu z jednej wersji na drugą, bo te systemy sterują bieżącą produkcją itd., to po prostu naturalnie się to wydłuża.

I jest jeszcze drugi sposób, ten green field, w praktyce to jest reimplementacja. I tutaj trzeba przekonać klienta, że stare, działające przeróbki nie są dobre. I to jest tak naprawdę wdrożenie od nowa, tylko mamy pewien bagaż doświadczeń i przyzwyczajeń u bieżących użytkowników. Bo przy takim kompletnym wdrożeniu od nowa my na podstawie wiedzy, doświadczenia konsultantów mówimy, jak powinno być. A w takim wdrożeniu, w którym firma decyduje się przemodelować cały ten proces, okazuje się, że nie wszyscy chcieliby się przesiąść, bo niektórym robi się dobrze, gdy się robi po staremu. I to przekonywanie użytkowników jest najbardziej czasochłonne. Tu nie system jest problemem, tylko praca z biznesem i ustalenie tego, jak to powinno być. Każda firma jest inna i podejścia są indywidualne czasami, też problemy są różnorodne.

 

Przede wszystkim są to nowe wdrożenia, bo jeżeli ktoś kupuje SAP-a, to takie nowe wdrożenie na S/4HANA nie różni się niczym od starego wdrożenia przy R/3. Dla użytkowników, dla firm jest to obojętne, nie muszą migrować, tylko uczą się wszystkiego od nowa. Niestety stare firmy mają trochę gorzej, bo ten bagaż historii, wersji SAP-a, o których wspomniałem, nie dotyczy tylko SAP-a jako firmy i produktu, ale też firm, w których ten SAP się rozwijał, czyli klientów końcowych. Przecież te firmy się rozrastały, kupowały siebie nawzajem, każda firma ma swoje klienckie rozwiązania, każda firma inaczej je programuje, inaczej je integruje, w dodatku mamy do czynienia z kilkoma milionami osób, które go używają, mają swoje przyzwyczajenia, bo tych przyzwyczajeń użytkownika też nie można lekceważyć i kiedy mamy nagle do czynienia z produktem półkowym, który musimy zaktualizować, mamy czasami bardzo dużo pracy.

 

 

Dobrze, myślę, że mniej więcej mamy już pojęcie, czy jest SAP, z jakich części się składa, jakie wyzwania wdrożeniowe występują. Myślę, że warto byłoby teraz spojrzeć na perspektywę osób, które zajmują się SAP-em, na konsultantów.

Chciałbym zacząć od takiego pytania: jak w ogóle zostać konsultantem? Czy ta praca jest ciekawa, opłacalna? 

 

Teraz jest więcej możliwości niż kiedyś, bo przede wszystkim można już zacząć studiować SAP-a, wiem, że się pojawił na polskich uczelniach. Ja jak studiowałem, to takiego przedmiotu w ogóle na żadnej uczelni nie było. Więc pierwszym młodym narybkiem jest student. 

Ale niekoniecznie informatyki, bo może to być student kierunków związanych z przetwarzaniem danych lub modelowaniem biznesów, zarządzanie, tego typu kierunki, ekonometrii, czyli ktoś, kto przede wszystkim ma zdolności do analitycznego myślenia, bo to jest bardzo potrzebne w tym zawodzie. Nie jest to wymagane, ale bardzo ułatwia, bo mimo wszystko trzeba przeanalizować wszystkie wymagania, więc jeżeli ktoś jest typowym analitycznym umysłem, to może tutaj zaczynać. I pierwszy taki etap, to np. zatrudnić się jako praktykant lub młodszy narybek i stać się kandydatem na juniora. Chodzi o to, że nie każdy się odnajdzie w tym systemie, bo tak jak mówiłem, to nie jest do końca praca tylko z systemem, ale jednocześnie z ludźmi.

Taka osoba, jeżeli chce rozpocząć pracę w SAP-ie, to pamiętam, że w moim przypadku taki największy przyrost wiedzy był wtedy, kiedy musiałem szkolić użytkowników, pisać instrukcje i prowadzić wsparcie. Bo żeby komuś coś wytłumaczyć, to najpierw trzeba to zrozumieć. I często ci użytkownicy, zwłaszcza ci zaawansowani lub dociekliwi, bardzo potrafią przyspieszyć Twoją naukę, bo zadają na tyle dociekliwe pytania, że powodują one, że trzeba samemu poszukać. 

Teraz jest niesamowity dostęp do wiedzy, czy to na YouTube, czy na forach. Ja miałem trochę gorzej, bo tych szkoleń w ogóle nie było, trzeba było samemu posiedzieć czasami wieczorami, nocami w systemie, żeby w końcu zrozumieć, jak SAP działa. Ja często żartuję, że dokumentację SAP-a się to rozumie wtedy, kiedy już się zna ten proces, wtedy ma to sens. I kiedyś rozmawiałem o tym z kolegami, oni podzielali moją opinię. Więc tak można wejść w ten świat SAP-a.

Oprócz tego, jeżeli chce się poznać dane procesy, to teraz jest mnóstwo dostępnych szkoleń. Na YouTube jest naprawdę bardzo dużo rzeczy i czasami szkoda przeznaczać pieniądze na szkolenia SAP-owe, bo one dużo kosztują, a to, co jest ogólnodostępne, moim zdaniem jest czasami nawet o wiele bardziej wartościowe. Jest bardziej skondensowane. Jednocześnie, jeżeli się jest studentem uczelni, na której uczą SAP-a, to trochę ta część dostępu do szkoleń jest zapewniona przez sam program studiów, czyli ten poziom wejścia też jest tutaj niższy. 

Ja pamiętam, że jak przyszedłem pierwszy raz po studiach i zobaczyłem ekran SAP-a, to nie wiedziałem, co to jest, z czym to się je, wszystko było zupełnie inaczej zorganizowane niż np. w Windowsie, trzeba się z tym obyć. I jeżeli się jest w takiej firmie consultingowej jako junior, to pozostaje tylko uczestniczyć w projektach i zdobywać wiedzę w praktyce. Inaczej się nie da. Swoje trzeba odstać i przerobić, jak ja to mówię. 

Nie jest też to taki krótki proces, bo te wszystkie tutoriale pokazują jak coś wykonać, ale żeby zdobyć doświadczenie, to trzeba odbyć kilka cykli projektowych. W ogłoszeniach wymagane jest przynajmniej 2-, 3-letnie doświadczenie w projektach. Ale prawda jest taka, że jeżeli uczestniczy się w nich jako tzw. wsparcie, jako junior, to się bardzo dużo uczy. I jakbym miał obserwować krzywą przyrostu wiedzy, to ten okres juniorski jest chyba największy, jeśli chodzi o SAP-a. Bo potem się zdobywa takie doświadczenie bardziej pracy z ludźmi, nie z systemem.

Jest jeszcze często spotykany model wejścia do świata consultingu SAP poprzez użytkownika kluczowego, który chciałby się rozwijać w ramach swojej firmy i przechodzi do działu utrzymania SAP. I taka osoba ma nawet trochę większą przewagę nad studentem informatyki, bo wie, jak wyglądają procesy w firmach. 

Pamiętam, że jako student informatyki najpierw musiałem zrozumieć, co to jest przyjęcie materiału, na czym polega proces zamówienia. Bo nie wszędzie tego dobrze uczą, zwłaszcza w kontekście procesów SAP-owych. A jeśli zaawansowany użytkownik uczestniczył w tych wdrożeniach, tylko że od strony biznesu, to dla niego jest to tylko kwestia, żeby się zapoznać z niektórymi technicznymi rozwiązaniami. I jest mu łatwo, bo on i tak je widział do tej pory, tylko trochę od drugiej strony. 

Więc to też jest taka ścieżka możliwa, więc jeżeli ktoś czuje, że ma to myślenie analityczne, a do tej pory pracował jako planista, jako księgowy, moim zdaniem też ma duże szanse powodzenia. Mnie w pracy bardzo ułatwia analityczne myślenie, bo tu jest wymagany pewien rodzaj abstrakcyjnego, czasami algorytmicznego myślenia. Bo te procesy i koncert życzeń, który dostajemy od klienta, musimy przełożyć na język algorytmów. Nie mówię tu o czystym programie. Też, ale nie zawsze. Chodzi o to, że są pewne kroki procesów i trzeba wyłapać np. wykluczające się wymagania. 

A drugą zdolnością, która jest bardzo ceniona, jest dowożenie tematów i zdolność adaptacji rozwiązań. Trzeba próbować proponować rozwiązania, a nie te problemy tworzyć.

 

Nie jest też to taki krótki proces, bo te wszystkie tutoriale pokazują jak coś wykonać, ale żeby zdobyć doświadczenie, to trzeba odbyć kilka cykli projektowych. W ogłoszeniach wymagane jest przynajmniej 2-, 3-letnie doświadczenie w projektach. Ale prawda jest taka, że jeżeli uczestniczy się w nich jako tzw. wsparcie, jako junior, to się bardzo dużo uczy. I jakbym miał obserwować krzywą przyrostu wiedzy, to ten okres juniorski jest chyba największy, jeśli chodzi o SAP-a. Bo potem się zdobywa takie doświadczenie bardziej pracy z ludźmi, nie z systemem.

 

Właśnie, dla tych osób, które myślą, że byłyby w stanie się odnaleźć w tym środowisku, w takim ekosystemie łączącym trochę wymogi techniczne, ale też znajomość biznesu, analitycznego podejścia do wymagań klienta, to jak wg Ciebie wygląda obecnie rynek pracy konsultantów, wdrożeniowców SAP? Czy jest z czego wybierać?

 

Jest i moim zdaniem, jeśli sobie przypomnimy liczbę klientów, o których powiedziałem, ok. 4 tys. przedsiębiorstw, nawet jeżeli one nie są jeszcze aktywne, to albo się rozwijają, albo wymagają wsparcia. To oznacza, że jest duża pula firm, w których jest szansa zatrudnić się na jakiś projekt. Można to robić poprzez dostanie się do ich wewnętrznego działu wsparcia (czyli tzw. klient końcowy) lub przez firmę consultingową. I w zależności od swojego doświadczenia możemy być albo konsultantem wdrożeniowym, albo jako wsparcie, gdy mamy mniejsze doświadczenie. Chociaż ja jako osoba z 16-letnim doświadczeniem też mam projekty, w których pełnię rolę wsparcia, bo są różne linie wsparcia i różne poziomy. Dlatego im się jest bardziej doświadczonym, tym się powiększa wachlarz ról, które możemy uzyskać, ale też trzeba sobie jasno powiedzieć, że nie na każde stanowisko jest sens zatrudniać seniora i nie na każde stanowisko można zatrudnić juniora. 

Jeśli chodzi o to, czy coś się opłaca, czy nie, to ja pracując z firmą Awareson widziałem, że ona udostępniła raport rynku pracy i dostępnych stawek, więc zachęcam do zapoznania się z tym raportem. Patrząc po liczbie ofert i zapytań ofertowych, które do mnie spływają, to bardzo żałuję, że nie potrafię się podzielić na kilku Adamów Szeżeńskich, bo jest wiele projektów, w których nie mam szansy uczestniczyć, bo niestety ma się jedną głowę tylko i nie można więcej tych projektów obsłużyć,a jest ich naprawdę bardzo dużo. Zwłaszcza że są teraz projekty utrzymaniowe, przygotowujące do migracji, czyli te, o których mówiłem, że trzeba coś wdrożyć przed samą migracją, i są te projekty migracyjne. SAP też nabywa wiele nowych programów około SAP-owych, BI do raportowania, zaawansowane systemy planistyczne. Więc jest naprawdę szeroka gama produktów i projektów, o które można się, mówiąc przysłowiowo, zahaczyć.

 

Świetnie. Dzisiaj bardzo ciekawie o SAP-ie, jego budowie i wdrożeniach opowiadał Adam Szeżeński.

Adam, bardzo Ci dziękuję za poświęcony czas, za tę rozmowę.

 

Ja również bardzo dziękuję.

 

Zanim się rozłączymy, to jeszcze zapytam Cię, gdzie Cię można znaleźć w internecie, gdzie możemy odesłać słuchaczy, gdyby mieli jakieś pytania co do SAP-a. 

 

Zapraszam na mój profil LinkedIn. Mam nadzieję, że mnie podlinkujesz, to jeżeli ktoś będzie chciał się ze mną skontaktować, to na pewno odpiszę.

 

Oczywiście, link będzie w notatce do odcinka. Jeszcze raz Ci, Adam, bardzo dziękuję za rozmowę. 

Do usłyszenia, cześć!

 

Dziękuję bardzo. Do usłyszenia.

 

I to było na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, w której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe.  

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o budowie i wdrożeniach SAP. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!