Pracując z systemem SAP miałem okazję, a niekiedy przyjemność poruszać się po tak zwanych „Z-transakcjach” – programach “szytych na miarę” dla potrzeb przedsiębiorstwa. W sumie proces nauki systemu opierał się w większości na tego typu transakcjach. Trzeba było kilku lat pracy aby zrozumieć, że korzystanie z nich, bez ogólnego rozumienia systemu może przynieść więcej strat niż korzyści.
Nie chcę oceniać możliwości takich rozwiązań, przytoczę tylko kilka przykładów a ocenę pozostawię w gestii czytelników.
Specjalne transakcje, które pełnią funkcję nakładki na standardowe programy SAP często mogą spełniać rolę monitorów i mogą okazać się bardzo dużym udogodnieniem, np. w dziedzinie transportów i dostaw przychodzących. Standardowo aby wyświetlić transport lub dostawy przychodzące, HU, zamówienia lub dane gospodarki magazynowej z transakcji MM02 (paletyzacja, strategie magazynowania) należy skorzystać z kilku odmiennych programów, np. VT03N, VL33N, ME2M itd.
Własna transakcja pozwala osiągnąć wgląd do tych wszystkich danych w jednym oknie, gdzie kliknięcie w jakąkolwiek kolumnę w interesującym nas wierszu pozwoli przejść do oryginalnej transakcji podglądowej. Wystarczy wprowadzić interesujący nas numer transportu i otwiera się przed nami szereg możliwości ułatwiających planowanie rozmieszczenia materiałów. Własną transakcję można również skonfigurować w taki sposób aby po kliknięciu jednego przycisku utworzyć zlecenia przeniesienia do umieszczenia materiałów na magazynie na podstawie dostawy przychodzącej, nie wiedząc nawet o tym, że już się jest w transakcji LT03. W tym momencie pojawia się problem.
Transakcja, która stanowi dla użytkownika znaczne ułatwienie okazuje się wielkim murem dzielącym go od zrozumienia działania metodyki SAP (mowa tutaj o początkujących). Użytkownik nie wie, że musi zostać stworzone zamówienie, na podstawie rezerwacji, które to z kolei musi zostać przygotowane w innym zakładzie poprzez dostawę wychodzącą, transport, z naszej strony dostawę przychodzącą itd. Czy taka wiedza jest potrzebna? Tutaj spotkałem się z różnymi opiniami, jeśli pracownika się dobrze poinstruuję to będzie wykonywał swoją pracę i nie musi być świadomy procesów wewnątrz systemu, jednak w momencie kiedy pojawia się problem, prawie zawsze jego przyczyną jest właśnie ten brak wiedzy.
System z jakim miałem przyjemność pracować był skonfigurowany w taki sposób aby po utworzeniu dokumentu materiałowego w MM, SAP podpowiadał kolejną transakcję do utworzenia zlecenia przeniesienia (LT06 – tworzenie zlecenia przeniesienia na podstawie dokumentu materiałowego, następnie LT04 – tworzenie zlec. przen. dla zapotrzebowania przeniesienia). Te ułatwienie zaoszczędza kilka ruchów, ale bez rozumienia dlaczego dzieje się tak a nie inaczej, pojawiają się błędy, na których trzeba poświęcić dwa razy tyle czasu.
Pracownik, który wprowadził pozycje błędnie, tworzy dokument materiałowy w transakcji MB1A, po czym przechodzi do kolejnej transakcji i wybierając nieprawidłowy typ magazynu do poboru, nie może iść dalej (pojawia się problem zobrazowany na rysunku nr 3), więc wychodzi całkowicie z transakcji. Chcąc poprawić swój błąd powtarza czynność od nowa, tworząc kolejny dokument materiałowy czego efektem są różnice w stanach (widoczne w transakcji LS24) oraz niedokończone ruchy.
Pracownik nie rozumiejąc tego procesu, nie wie, że dokument został już utworzony i powinien jego numer wykorzystać do utworzenia zlecenia przeniesienia w transakcji LT06. W innym przypadku utworzył zapotrzebowanie przeniesienia, do którego nigdy nic nie zostanie dostarczone bo nigdy nie zostanie utworzone zlecenie przeniesienia.
Początkowym środkiem zaradczym na takie błędy była osoba, która takie błędy korygowała. Niekiedy potrzeba zakończenia noty przeksięgowania wymagała dodania do stanu materiału tylko po to by po zakończeniu niedokończonego ruchu materiał z powrotem wyksięgować co powodowało „dziwne ruchy” widoczne np. w transakcji MB51.
W tym przypadku widać, że optymalizacyjne udogodnienie, dla pracowników nie posiadających odpowiedniej wiedzy ani nie pracujących nigdy wcześniej według standardów, przynosiło odwrotne skutki od zamierzonych. Skrócono czas wykonywania codziennych operacji w SAP, ale z powodu braku dostatecznej wiedzy użytkowników pojawiła się potrzeba korygowania i wyjaśniania codziennych nieświadomie popełnianych błędów.
Nie znając źródła błędów ani przyczyn otwartych not i zapotrzebowań widocznych w transakcji LL01 często pojawiało się mylne spostrzeżenie że w SAP znów pojawiają się błędy i należy system z nich wyczyścić. Akcja czyszczenia błędów raz na jakiś czas nie pozwalała na dojście do „świeżej” przyczyny, dopiero kilka dni poświęconych na analizę pozwoliło zrozumieć podstawy funkcjonowania SAP i okresowe akcję czyszczenia zostały zastąpione codziennym monitoringiem ruchów w transakcjach, które zostaną opisane w kolejnym artykule.
Powyższe skłania do refleksji nad sensem ułatwień i pisania własnych z-transakcji, w przedsiębiorstwie wspieranym przez system SAP, czasami kosztem pomijania standardowych procedur przez użytkowników. Ponieważ nie posiadam zaawansowanej wiedzy poprzestanę na tym krótkim przykładzie i tak jak obiecałem, ocenę na temat sensu pisania własnych transakcji pozostawię innym. Czy warto pisać własne z-transakcje do poprawnie działających standardowych procesów oferowanych przez firmę SAP? Może lepiej utworzyć własną sieć kodyfikacji z-transakcji i kopii ruchów w celach ułatwiających kontroling (inny ruch materiałowy dla każdej osobnej przyczyny ruchu)? Na pewno (i to mogę potwierdzić własnym doświadczeniem) własne transakcję utrudniają dostęp do pomocy oferowanej przez innych użytkowników SAP, ponieważ trudno jest sprecyzować problem czy pytanie opierając się na własnej, niestandardowej kodyfikacji ruchów i transakcji opracowanych dla indywidualnych potrzeb firmy.
A ja przewrotnie zapytam, mając nadzieję, że nikogo nie wyprowadzę z równowagi, czy SAP, tworząc transakcje standardowe, na pewno uwzględnił zapotrzebowanie biznesu? Przyznam, że jestem zwolennikiem standardu, jednak nie zawsze odpowiada on, w moim przekonaniu, standardowym, związanym z logistyką, oczekiwaniom. Przyznam, że korzystam z transakcji niestandardowych, które często są mi niezbędne zarówno w raportowaniu, jak i szybkiej, łatwej oraz skutecznej, realizacji bieżących operacji logistycznych. Przyznam również, że znam mnóstwo transakcji niestandardowych, które są kulą u nogi. Spowalniają i utrudniają właściwe funkcjonowanie łańcucha dostaw. Pojawia się więc pytanie, czy transakcje niestandardowe powinny być tworzone na każde zawołanie każdego usera, czy może, jak słusznie w artykule wspomniałeś, firma powinna prowadzić sieć kodyfikacji transakcji niestandardowych i mądrze nimi zarządzać?
Moim zdaniem SAP uwzględniła zapotrzebowania biznesu. Świadczy o tym bezprecedensowy sukces systemów firmy SAP – to jest de facto standard zintegrowanych systemów wspierających zarządzanie. Nie sądzę, aby ponad 350k klientów mogło się mylić: https://www.sap.com/corporate/en/company.html
Na pewno jednak nie wszystkie oczekiwania są spełnione w standardzie. To przeważnie wynika z nielogicznego ułożenia procesów w firmie lub bałaganu w danych. Przykładowo są firmy, które zamiast stosować dostawę wychodzącą jako dokument planujący wysyłkę i będący żądaniem kompletacji z magazynu, traktują dostawy jako rezerwacje zapasu, a kompletację budują w okół grup dostaw.
Na koniec naturalnie zawsze znajdą się obszary, gdzie standard SAP nie spełnia realnych, specyficznych wymagań. Wtedy faktycznie potrzebne są niestandardowe rozwiązania, czyli Z-transkacje. Tylko zanim wejdzie się w Z-ty najpierw należy sprawdzić standard, a ewentualne rozszerzenia zgrać ze standardem, aby się dobrze wpasowywały w SAP Best Practices. Mówiąc krótko, Z-ty trzeba robić z głową i na pewno nie na każde zawołanie, każdego użytkownika.
Zgadzam się. W biznesie powinniśmy przykładać większą uwagę do aktualizowania wewnętrznych procesów i dostosowywania ich do zmieniających się potrzeb rynku. Życzeniowe tworzenie bajpasów do niczego dobrego nie prowadzi. Podoba mi się to, co powiedział SAP CEO Bill McDermott: “SAP will remain a culture in the pursuit of excellence. We understand you, and you alone determine whether we win or lose.” Misja zmierzająca we właściwym kierunku.
Nie mam nic przeciwko niestandardowym transakcjom, pod warunkiem, że firma, która je tworzy będzie dążyć do podnoszenia stopnia świadomości użytkowników. User korzystający z Zet-transakcji, nie ma pojęcia co się dzieje w systemie. Z braku świadomości biorą się nieprzemyślane ruchy w systemie, które z kolei powodują potrzebę tworzenia niestandardowych transakcji kontrolujących te ruchy i tak kółko się kręci. Co do zmian ułatwiających pracę – również nie mam nic przeciwko, pod warunkiem, że użytkownik zostanie uświadomiony jak jest w standardzie i dlaczego standard został zmodyfikowany. Osobiście dopóki samodzielnie nie poćwiczyłem z SAP Best practices, bezmyślnie klepałem w systemie zostawiając po sobie bałagan. Drugą połowę dnia spędzałem na korygowanie błędów w Z-transakcji (specjalnie do tego stworzonej) nieświadomy tego, że to ja byłem ich przyczyną 🙂 Także moje zdanie jest takie: świadomość, świadomość i jeszcze raz świadomość, następnie można myśleć o Z-transakcjach.