Jan 16
SAP — budowa i wdrożenie
W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Adamem Szeżeńskim o budowie i wdrożeniach SAP.
Posłuchaj naszej rozmowy w wersji audio 🎧 👇
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.
👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-184-sap-budowa-i-wdrozenie/
