W poprzedniej części wpisu przyjrzeliśmy się bliżej tematyce kontroli dostępności ATP w SAP. Próbowaliśmy zrozumieć jak działa ta funkcja i przekonaliśmy się jak nieprzemyślana ingerencja ze strony użytkownika może negatywnie wpłynąć na jej efekty. Wiemy już mniej więcej jak kontrola ATP wygląda od strony konfiguracyjnej a teraz sprawdźmy jak to wygląda od strony użytkownika końcowego. Nie wszyscy w organizacji są świadomi tego, że system kilka razy dziennie sprawdza dostępność części (w zależności od wymagań), bez potrzeby ręcznej ingerencji w zlecenia produkcyjne. System wykonuje automatycznie funkcje kontroli dostępności, dla wybranej grupy zleceń za pośrednictwem zadania zaplanowanego w tle. Bardzo istotną tutaj kwestią jest prawidłowa selekcja dokumentów, dla których ta kontrola powinna być przeprowadzona. Mogłoby się wydawać, że to jest prosty temat i nie wymaga, żadnego omawiania – jednak i tutaj potrafi on przysporzyć problemów. W sytuacji z życia wziętej, w której zakład musiał stawić czoła wyzwaniu związanemu z opóźnionymi dostawami komponentów do zleceń, pojawiła się potrzeba zagłębienia tematu po to by uzyskać odpowiedzi na następujące pytania: dlaczego, pomimo przyjętych dostaw komponentów, zlecenia produkcyjne wciąż posiadają brakujące części? Dlaczego system sam rezerwuje i potwierdza części do zleceń nie uwzględniając pilniejszych terminów? Co jest przyczyną opóźnień?

Kontrola dostępności dla pojedynczego zlecenia produkcyjnego

Zacznijmy wszystko od początku. Wyobraźmy sobie sytuację, w której planista produkcji ze spokojem na twarzy przegląda (w transakcji monitorującej) wszystkie zlecenia produkcyjne, które mogą zostać wdrożone na produkcję. Sugeruje się statusami i jeśli zlecenie nie posiada statusu systemowego FMAT (brakująca część) to jest zielone światło aby je zwalniać na produkcję. W momencie zwalniania dokumentu zlecenia, pojawia mu się znienawidzony już komunikat:

Powstaje więc pytanie: dlaczego zlecenie produkcyjne, bez braku, wykazuje niedobór dopiero w momencie jego wdrażania? Przyczyną może być sytuacja, w której na magazynie została przeprowadzona korekta stanu (przez zaksięgowanie dokumentu materiałowego zużywającego materiał) albo co gorsza ilość materiału jest wystarczająca ale zostały „podebrane” rezerwacje do zupełnie innych zleceń produkcyjnych. Nagminność takich zapytań i sytuacji przyczyniła się do wszczęcia przeze mnie „śledztwa”, którego wynik wyglądał mnie więcej tak:

1. System dokonuje kontroli dostępności materiałów ATP w momencie zdefiniowanym w konfiguracji o czym była mowa w poprzedniej części artykułu (pierwsza kontrola w momencie przekształcenia zlecenia planowego w produkcyjne, druga kontrola w momencie zwolnienia zlecenia).
2. Przekształcone zlecenia produkcyjne ze statusami pozwalającymi na wdrożenie, czekają na odpowiedni moment (może zostały przekształcone zbyt szybko?).
3. Lista zleceń produkcyjnych wyświetlana w z-transakcji służy do planowania planu pracy dla stanowisk produkcyjnych – trzeba odpowiednio rozplanować pracowników.
4. W momencie zwalniania zleceń okazuje się, że znaczną część planu trzeba zmieniać w trybie natychmiastowym z powodu braku dostępności komponentów (kontrola ATP nie działa?), a nawet jeśli ilość zleceń jest wystarczająca aby uruchomić produkcję to i tak zlecenia nie są realizowane w kolejności zgodnej z terminami zdefiniowanymi przez klientów („podkradnie” rezerwacji do innych zleceń?).

Postanowiłem sprawdzić kilka zleceń, które zdaniem systemu są gotowe na wdrożenie. Kontrolę dostępności dla pojedynczego zlecenia produkcyjnego można wykonać w transakcji CO02, za pomocą funkcji wywoływanej przyciskiem jak na zdjęciu nr. 2. W przypadku wykazania dostępności wszystkich składników system poinformuje nas odpowiednim komunikatem. Jednak kiedy zostanie stwierdzony niedobór pojawi się okno pop-up, w którym po wciśnięciu przycisku „przegląd brak. mat.” (2) pojawi się lista brakujących materiałów.

System wyświetla informacje jaka ilość wykazana jest w zapotrzebowaniu (1) i jaka ilość została potwierdzona przez kontrolę ATP (2) – patrz rysunek 3.

Sprawdziłem więc kilka zleceń i wynik był taki, że dla zleceń z pełną dostępnością składników (według mnie i planistów) ponowna kontrola dostępności ATP wykazała braki. Wszystko wskazywało na to, że podczas automatycznego sprawdzania dostępności (przez zadanie w tle) system uwzględnia tylko zlecenia ze statusami FMAT. Jeśli zlecenie produkcyjne nie wykazuje braków to nie jest ono już brane pod uwagę podczas zbiorczej kontroli dostępności. Postanowiłem więc sprawdzić jak taka kontrola przeprowadzana jest masowo przez system za pośrednictwem zadania zaplanowanego w tle.

Zbiorcza kontrola dostępności ATP w SAP – przetwarzanie zbiorcze zleceń produkcyjnych

A więc w celu masowej kontroli dostępności należy skorzystać z transakcji COHV (przetwarzanie grupowe zleceń produkcyjnych) lub COMAC (kontrola zbiorczej dostępności)  dla zleceń produkcyjnych. Dla zleceń planowych będzie to transakcja MDVP (kontrola zbiorczej dostępności). Zarówno transakcja COHV jak i COMAC jest tym samym programem (PPIO_ENTRY) z tą różnicą, że za ich pośrednictwem można uruchomić inne funkcje w obrębie zleceń produkcyjnych. Uruchomić ten program możemy również za pośrednictwem transakcji SA38 (uruchamianie programu zostało przestawione we wpisie o SQVI). Po wczytaniu wybranej grupy zleceń w transakcji COHV, z poziomu menu, mamy możliwość wywołania funkcji widocznych na zdjęciu nr 4 (kwadrat oznaczony cyfrą 3). Przyciskiem 1 rozwijamy menu, następnie wciskamy przycisk „ustawienia” i to spowoduje uruchomienie dodatkowego okna, w którym można zdefiniować parametry wywoływanej funkcji. Następnie klikamy „wykonanie” (2) lub po prostu „F8” i system uruchomi funkcję dla zaznaczonej grupy zleceń.

Transakcja COMAC natomiast pozwala nam tylko na wykonanie funkcji do której została dedykowana – czyli wykonania kontroli dostępności (co widać na rysunku 5).

Zarówno jedna jak i druga transakcja daje możliwość ustawienia parametrów wykonywanej funkcji już na wstępie po uruchomieniu (rys. 6). Dodatkowo jeśli uprzednio dla transakcji zapiszemy układ wariantu wyświetlania (układ kolumn i kryteria sortowania) to możemy go wybrać przed uruchomieniem (1). W zakładce „przetwarzanie zbiorcze” (2) możemy natomiast ustawić funkcję (3) oraz jej parametry (4). Jeśli w zakładce „wybór” zdefiniowaliśmy już kryteria na podstawie których system ma wyświetlić zlecenia oraz ustaliliśmy parametry funkcji i chcielibyśmy korzystać z tej transakcji częściej to aż się prosi by zapisać taki wariant za pomocą przycisku . W przyszłości nie będziemy musieli już przechodzić przez te kroki ponownie, bo po wciśnięciu „odczyt wariantu” będziemy mieli gotowe zlecenia do uruchomienia zdefiniowanej wcześnie funkcji.

Wracając do wyników wspomnianego „śledztwa”, tym razem sam wybrałem zlecenia produkcyjne i uruchomiłem funkcję sprawdzania dostępności. Program wykonywał się przez około 2 godziny i efekt był taki, że bardzo dużo zleceń produkcyjnych z pozytywną wcześniej kontrolą (które jeszcze nie zostały wdrożone na produkcję), tym razem otrzymało wynik negatywny. Wszystko wskazywało na to, że przypuszczenia są słuszne i zadanie zaplanowane w tle, które wykonuje program PPIO_ENTRY, nie bierze pod uwagę zleceń z wynikiem pozytywnym. Próbowałem się dowiedzieć od zespołu servicedesk, jaki wariant selekcji został zdefiniowany dla programu wykonującego kontrolę ATP w SAP – bez rezultatu. Nazwa zadania wykonującego ten krok, również została owiana tajemnicą. Trafiłem na mur, więc postanowiłem pójść w inną stronę. Postanowiłem sam znaleźć zadanie background job i je sprawdzić. Czym są i jak definiuje się zadania wykonywane w tle?

Zadania wykonywane w tle – planowanie i uruchomienie programu w tle

Zadanie wykonywane w tle (background job) to procesy zaplanowane przez użytkownika, które są wykonywane przez system w tle. Oznacza to, że nie są one uruchamiane na pierwszym planie i nie wymagają od użytkownika żadnych dodatkowych czynności. Działają równolegle z innymi, codziennymi procesami wykonywanymi przez ludzi. To jest powodem tego, że użytkownicy często nawet nie są świadomi, iż za ich procesami wykonują się jeszcze jakieś inne. Gdyby w SAP nie było możliwości planowania zadań w tle, to całą tą robotę musielibyśmy wykonywać sami – dobrze, że producent SAP zafundował nam taką oszczędność czasu 😉

Definiowanie zadania uruchamiamy w transakcji SM36 (do której niestety nie miałem uprawnień). Zmianę i wyświetlanie zadania umożliwia nam transakcja SM37 (do której szczęśliwie miałem uprawnienia). Postanowiłem więc sprawdzić zadania wykonane w tle dla programu ABAP – PPIO_ENTRY. W tym celu w transakcji SM37 jako nazwę zadania i użytkownika wprowadziłem symbol „gwiazdki”, ponieważ nie wiem ani kto zdefiniował takie zadanie ani jak je nazwał. Następnie wystarczyło zdefiniować zakres dat i kliknąć w „rozszerzony wybór zadania” jak na zdjęciu nr 7.

Po wybraniu rozszerzonego wyboru otwiera się naprawdę spory wachlarz możliwości. Możemy wyszukać zadania po statusie, możemy również wybrać kroki zdefiniowane dla zadania lub nazwę wykonywanego programu ABAP (w moim przypadku był to PPIO_ENTRY). Dodatkowo w zakładce „aktywny” możemy wyszukać zadanie, które było w trakcie wykonywania w odpowiednim zakresie czasu – to nam jeszcze bardziej zawęża zakres poszukiwań.

Sprawdzając wcześniej kilka zleceń produkcyjnych pod kątem zmian statusów w zakresie kontroli dostępności, zauważyłem, że zmiany statusu dostępności dokonują się najczęściej w okolicach godziny 04:00 rano oraz 11:00 w południe (przez użytkownika zdefiniowanego dla zadań w tle, w tym przypadku PP-BATCH). Miałem więc orientacyjne godziny, w których zadanie było aktywne. Wprowadzając odpowiednie dane, transakcja SM37 wyświetliła mi listę zadań. Oczywiście szukałem zadań, które zawierały numer zakładu w nazwie (bo zauważyłem, że ktoś przyjął taką metodologię nazywania zadań) i o to się pojawiły dwa zadania (rysunek 9):

Po zaznaczeniu wykonanego już zadania (ze statusem zakończone) system umożliwia wyświetlenie jego logu, dzięki temu możemy podejrzeć wszystkie kroki wykonywane podczas jego przetwarzania. Tym sposobem uzyskałem nazwę wariantu zapisanego dla programu PPIO_ENTRY w celu wykonania codziennej kontroli dostępności.

Tak więc skoro wariant już był znany pozostało tylko uruchomić program za pośrednictwem transakcji SA38. Spójrz na rysunek 11 -wystarczy wprowadzić nazwę programu (1), następnie wcisnąć przycisk „z wariantem” (2) i wkleić nazwę wariantu (3).

Po zatwierdzeniu wyboru system przechodzi do transakcji COHV, w której możemy podejrzeć jakie kryteria selekcji zleceń zostały wybrane w tym wariancie. Postępując w ten sposób wyświetlił mi się pierwszy ekran selekcji, który niestety za wiele mi nie mówił. Miałem nadzieję podejrzeć z jakimi statusami zlecenia są uwzględniane, jednakże dla tego wariantu wyboru został przez kogoś zdefiniowany schemat wyboru statusów, który widać na rysunku 12.

Co się kryje pod tym schematem i do czego on służy?

Schemat wyboru – status

Otóż schemat wyboru jest kombinacją statusów systemowych i statusów użytkownika użytych w celu wyboru zakresu danych. Funkcjonalność ta znacznie ułatwia selekcję zleceń. Czasami może pojawić się potrzeba uwzględnienia kilku statusów przy jednoczesnym wykluczeniu kilku innych. Znacznie łatwiej jest skonfigurować w takim przypadku schemat wyboru statusu. W tym celu należy skorzystać z transakcji BS42 (zmiana schematu wyboru), lub z poziomu przewodnika konfiguracji ze ścieżki jak na zdjęciu:

Ja niestety nie posiadałem uprawnień do edytowania ani nawet wyświetlania schematów wyboru, ale poprosiłem dział SAP o zmianę schematu, aby uwzględniał również zlecenia produkcyjne z pozytywnym wynikiem kontroli ATP. Servicedesk spełnił tą prośbę i od tamtej pory program uruchomiony jako background job uwzględniał również zlecenia nie wdrożone, ale z pozytywną kontrolą. Wydawało się, że problemy związane z dostępnością części zostały rozwiązane, ale to wciąż nie było to. Wciąż pojawiały się sytuacje, w których pomimo sporej ilości komponentów na zapasie, zlecenia wciąż nie mogły zostać wdrażane z powodu statusów FMAT. Mało tego! Pojawiło się również przypuszczenie, że program wykonujący kontrolę dostępności ATP nie został zaplanowany na soboty. Powodowało to kolejne opóźnienia i straty w postaci nieefektywnego wykorzystania potencjału zasobów pracowniczych podczas sobotnich nadgodzin. Dlaczego? Otóż zgodnie z tym co napisałem poprzednio, program wykonujący kontrolę dostępności uruchamiał się o godzinie 4 rano i 11 w południe, ale od poniedziałku do piątku. Jeśli więc przyjęcie komponentów na magazyn odbywało się z piątku na sobotę to teoretycznie już w sobotni poranek (na nadgodzinach) można było uruchamiać produkcję dla zleceń, do których dojechały niezbędne składniki. Problem w tym, że dla planisty produkcji te zlecenia posiadały status FMAT (brakujący materiał). Efekt był taki, że w celu uniknięciu postojów na nadgodzinach wdrażano zlecenia na dalsze daty, byleby coś robić. Pożytek z nadgodzin byłby największy tylko wtedy, jeśli w ich trakcie zrealizowane zostałyby zlecenia opóźnione, dla których została przyjęta dostawa komponentów.

Uwzględnienie kalendarza w zadaniu zaplanowanym w tle dla kontroli ATP w SAP

Sprawdziłem więc ponownie w transakcji SM37 jak wyglądają zadania background job dla programu PPIO_ENTRY. Tym razem było łatwiej bo już znałem ich nazwę. Okazało się, że faktycznie wyświetlając wykonane już zadania w przeszłości, brakowało wszystkich terminów sobotnich. Postanowiłem edytować zadanie i sprawdzić jak dokładnie zdefiniowano wartości dla okresów, w których powinno być wykonywane zadanie. Otóż po przejściu do transakcji SM37 i odnalezieniu konkretnego wpisu, musimy go zaznaczyć i z poziomu menu wybrać opcję szczegóły zadania (rys. 14). Następnie w kolejnym oknie klikamy w przycisk „warunek początkowy” w celu wyświetlenia warunków jakie muszą być spełnione aby rozpocząć zadanie.

W następnym oknie klikając w „wartości okresów” możemy sprawdzić jak została zdefiniowana okresowość dla zadania. W moim przypadku okazało się, że zadanie ma być wykonywane codziennie. Były zaplanowane dwa zadania: jedno na godzinę 04:00 i drugie osobne zadanie na 11:00. Autor zadania ma możliwość wyboru ograniczeń, np. kiedy chce aby było wykonywane codziennie z wykluczeniem dni świątecznych. Aby odnaleźć te ograniczenia klikamy w przycisk „ograniczenia” i wyświetla się lista jak na zdjęciu 15.

Po przejrzeniu szczegółów zadania wiedziałem już, że zadanie dla kontroli dostępności ATP w SAP jest zaplanowane tylko w dni robocze. Wysłałem więc zgłoszenie do działu wsparcia SAP, aby zmienili wartości okresów w taki sposób by background job uruchamiany był również w soboty. W odpowiedzi dostałem informacje, że z zadaniem wszystko jest w porządku bo ograniczenie zdefiniowane w zadaniu wyklucza tylko niedziele i święta a ja się czepiam o sobotę, która świętem nie jest 😉 Odgonili natrętną muchę 😉 W sumie mają rację – sobota świętem nie jest. Poprosiłem więc o sprawdzenie w transakcji SCAL (do której dostępu nie miałem) aby sprawdzili jak zdefiniowano dni robocze dla ID kalendarza 01 (ID znajdziesz na rysunku 15 – zakres dnia natomiast na rysunku 16). Tak jak myślałem: dni robocze w zakładzie zdefiniowane od poniedziałku do piątku. Może i sobota świętem nie jest, ale nie jest też dniem roboczym. Jak zwał tak zwał – była potrzeba aby uruchamiać background job również w sobotę.

Problem został rozwiązany przez zdefiniowanie nowego zadania zakładowego poprzez skopiowanie już istniejącego i dodania dnia roboczego w sobotę. Następnie ID nowoutworzonego kalendarza zostało podmienione w zadaniu background job. Od tamtej pory nadgodziny sobotnie były wykorzystywane dużo bardziej optymalnie, przyczyniając się do redukcji opóźnień w procesie produkcyjnym. Sukces!! To jednak nie koniec problemów z zagadnieniem SAP ATP. Temat jest tak długi, że nie chcę Was zanudzać drodzy czytelnicy tak obszernymi wpisami. Dlatego postanowiłem rozszerzyć artykuł o jeszcze jedną część, którą będziecie mogli przeczytać za tydzień – obiecuje, że to już będzie ostatnia! Do przeczytania za tydzień!

Please leave this field empty

Chcesz być informowany o nowych wpisach?

Ja nie spamuje! Przeczytaj zasady polityki prywatności tego bloga.

Sprawdź swoją skrzynkę odbiorczą (albo katalog na spam) i potwierdź swoją subskrypcję.