W drugiej części wpisu zadaliśmy sobie serię pytań odnośnie problemów z kontrolą ATP w SAP i dostępnością komponentów do zleceń produkcyjnych. Próbowaliśmy znaleźć odpowiedź na pytania z życia wzięte: 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ń? Próbując znaleźć źródło problemów udało się dotrzeć do małej luki w wariancie selekcji dla programu PPIO_ENTRY wykonywanego dwa razy dziennie jako background job. Poza tym wprowadzono drobną zmianę do kalendarza zakładowego i skorygowano okresy wykonania dla zadania uruchamianego w tle. Ale czy to wystarczyło, aby rozwiązać problem z dostępnością części? Po dwóch tygodniach zgłębiania tematu okazało się, że poprzednio wykryte tropy tylko w 20-30% przyczyniały się do zaburzeń w dostępności komponentów do zleceń. Gdzie się znajdował główny powód? Przeczytajcie sami.

Pomimo wprowadzenia w życie zaproponowanych przeze mnie poprawek sytuacja poprawiła się nieznacznie. Każde zaburzenie w dostępności komponentów prowadziło do wniosku, że potwierdzenia ATP są po prostu zmieniane i „podkradane”. Zwracając uwagę innym na ten problem, spotykałem się z argumentem, że zmieniając potwierdzenia w transakcji CO06 wykorzystujemy ją do tego do czego została stworzona. Jednym słowem: „żyj dalej… i daj żyć innym”. Uważam jednak, że do transakcji CO06 uprawnienia powinny mieć tylko niektóre, ściśle określone osoby, które będą odpowiedzialne za przetwarzanie zleceń zaległych. Kiedy w ogóle taka transakcja powinna być użyta? Powróciłem do tego tematu i poszperałem na portalu SAP help. Otóż SAP zaleca użycie tejże transakcji tylko w sytuacji gdy popyt lub podaż w procesie realizacji zlecenia sprzedaży uległy zmianie. Wtedy uruchamiamy transakcję aby sprawdzić wcześniej obliczone potwierdzenia i tylko w wyjątkowej i nagłej sytuacji, mądrze przepiąć ilości do innych zleceń. Powinniśmy tego dokonać gdy:

W portalu SAP help, nadmieniono, że brak reakcji na zmienioną sytuację dostępności może spowodować, iż potwierdzone ilości przekroczą dostępne ilości. To może skutkować problemami podczas sprawdzania dostępności spowodowanymi zbyt dużą liczbą potwierdzonych materiałów w stosunku do dostępnych (dlatego warto zwrócić uwagę na regułę kontroli wybraną w pierwszym ekranie transakcji). To z kolei może powodować problemy w procesie tworzenia dostaw. Transakcji tej trzeba używać z głową, nie tylko w celu spełnienia swoich własnych celów ale ku chwale organizacji w której się pracuje, w przeciwnym przypadku funkcjonalność kontroli ATP zamiast być pomocą staje się utrapieniem. Zwłaszcza, kiedy sytuacja ma się tak jak w przykładzie, który prezentuje poniżej.

Resetowanie danych dostępności ATP w SAP

Proszę sobie wyobrazić sytuację jak na rysunku 1. W zakładzie dostępnych jest 74 szt. komponentów ale z powodu częściowych potwierdzeń ATP w SAP, nie jest możliwe uruchomienie żadnego zlecenia, ponieważ jego ilość całkowita przekracza ilość potwierdzoną ATP. Oznacza to, że na magazynie posiadamy 74 sztuki komponentu, które śmiało moglibyśmy wykorzystać do produkcji. Jednak tak się nie dzieje. Materiał się „kurzy” a klienci czekają. Miejsca regałowe są zajęte, do tego mamy opóźnienia z których ktoś będzie się tłumaczył. Powstaje nerwowa sytuacja oraz pytanie: dlaczego nie produkujemy? Przecież komponenty widnieją na stanie magazynowym?! Okazuje się, że żadne ze zleceń produkcyjnych nie może zostać wdrożone, ponieważ SAP wciąż pokazuje iż zlecenia posiadają brakujące części.

Idąc dalej sprawdźmy sytuację widoczną w transakcji CO24 – system informacyjny brakujących materiałów. Patrząc na ten sam rysunek, zauważyć można bardzo dziwną sytuację. Po lewej stronie (kolumna zaznaczona na czerwono) widzimy ilość zapotrzebowania dla każdego zlecenia produkcyjnego. Po prawej natomiast widzimy ilość potwierdzoną do zlecenia. Jeśli przyjrzymy się uważnie to zauważymy, iż każde ze zleceń ma tylko częściowo potwierdzoną dostępność komponentu. Oznacza to, że mimo iż posiadamy komponent na magazynie to nie możemy nic wyprodukować, ponieważ uniemożliwiają nam to cząstkowe rezerwacje, które totalnie nie mają sensu (a już nie wspomnę o kolumnie z terminami!!).

Proszę zwrócić również uwagę na to, że dla zlecenia, które powinno zostać zrealizowane już w kwietniu ilość potwierdzona komponentu wynosi 2, dla wszystkich kolejnych zleceń nawet tych na końcówkę czerwca ilość ATP jest dużo większa. Wiele razy usłyszałem zarzut, że to system „wariuje” lub po prostu „jest głupi”. Otóż nie! Winę za taką sytuację ponoszą użytkownicy podkradający potwierdzone już ilości do „swoich” zleceń (za pośrednictwem transakcji CO06).

Druga sprawa to źle zdefiniowane parametry funkcji kontroli ATP w SAP. Zdefiniowane zadanie w tle, które uruchamia program PPIO_ENTRY, powinno mieć zaznaczone opcję ponownego ustalania danych dostępności, a w tym przypadku nie ma.

Co to powoduje? Otóż zlecenia z odległą datą i potwierdzonymi ilościami, będą tak długo blokowały materiał, jak łączna ilość ATP nie będzie większa niż potwierdzona ilość ATP. W ten sposób żadne inne zlecenie z wcześniejszą datą nie jest w stanie „zarezerwować” części tak długo, jak nie będziemy mieli w puli więcej materiału do rozdysponowania. Chyba, że zostaną zresetowane dane dostępności ATP. Funkcja ponownego ustalania danych dostępności usuwa wyniki poprzedniej kontroli ATP i umożliwia ponowne uruchomienie kontroli z sytuacją początkową. Jeśli w firmie dochodzi do incydentów „podkradania” czy „przepinania” materiału między zleceniami to wskaźnik resetujący dostępność wydaje się być niezbędnym rozwiązaniem.

Kolejną istotną sprawą jest zapewnienie aby po zresetowaniu wyników kontroli ATP uruchomić ponowną kontrolę nie tylko dla zleceń z brakami, ale również dla tych bez statusu FMAT. Tylko wtedy system rozdysponuje dostępne ilości komponentów uwzględniając priorytety, terminy itd.

Po uruchomieniu funkcji kontroli ATP z resetem, sytuacja wyglądała już zupełnie inaczej (co widać na rysunku nr 3). Ta drobna korekta pozwoliła skrócić czas opóźnień o cały miesiąc!! Wydawało mi się to niewiarygodne! W życiu nawet nie przeszłoby mi przez myśl, że ręczne ingerencje i podkradanie komponentów do zleceń może wywierać aż tak negatywne skutki. A jeśli do tego dodać brak resetu wyniku ostatniej kontroli ATP to już zakrawa na istną patologię.

Niedowierzając w to co zobaczyłem, chciałem się przekonać, że to nie był tylko jednorazowy przypadek a skutek resetu był tak zwanym fartem, postanowiłem zasymulować podobną sytuację na serwerze testowym. O to wynik:

Testy wskaźnika resetu ATP w zbiorczej kontroli dostępności.

Zainicjowałem sytuacje, w której na składzie posiadałem tylko 2 szt. komponentu. W systemie miałem utworzonych kilka zleceń produkcyjnych zarówno z wczesnymi datami jak i tymi odleglejszymi. Zresetowałem wynik kontroli ATP bez ponownego sprawdzania, po to by łączna ilość wynosiła tyle ile posiadałem sztuk na zapasie, ale żeby te sztuki nie były potwierdzone do żadnego zlecenia. Proszę zerknąć na zrzut ekranu z transakcji CO06.

Jeśli podczas kontroli ATP w transakcji COMAC nie zaznaczyłem znacznika resetu to system automatycznie, zgodnie z oczekiwaniami, potwierdził dostępność dla najwcześniejszego zlecenia produkcyjnego co widać na obrazku niżej.

Następnie, próbując zasymulować próbę podebrania 2 sztuk do zlecenia najstarszego, zmieniłem potwierdzenie w transakcji CO06, przypisując tym samym te sztuki do zlecenia z terminem 02 wrzesień (czyli o ponad miesiąc do przodu). Proszę spojrzeć na rysunek niżej:

Następnie wykonałem ponowną kontrolę ATP w transakcji COMAC bez resetu (czyli w sposób w jaki działa wspomniany przeze mnie background job) i wynik dostępności widoczny w transakcji CO06 w ogóle się nie zmienił:

Następnie w przeciwieństwie do zdefiniowanego background job’a uruchomiłem masową kontrolę ATP ale ze wskaźnikiem resetu. Oczywiście wynik był zgodny z oczekiwaniami – system „przepiął” te 2 sztuki do zlecenia najwcześniejszego (rysunek nr 8). Brawo SAP! Nadchodzi koniec problemów 😉

Wniosek nasunął się sam: bez resetu, zlecenie będzie tak długo blokowało część (żadne inne zlecenie z wcześniejszą datą nie jest w stanie zarezerwować tej części) jeśli łączna ilość ATP nie będzie większa niż potwierdzona ilość ATP (czyli jeśli nie będziemy mieli więcej części w puli do rozdysponowania).

Oczywiście, czując się jakbym ratował świat, zgłosiłem się do kogoś z SAP-teamu w celu edycji wariantu dla programu PPIO_ENTRY i zaznaczenia znacznika resetu. Mój entuzjazm szybko został zgaszony, bo ktoś bardzo wysoko postawiony zakazał tej zmiany. No cóż, być może jestem za mały, żeby pewne rzeczy zrozumieć 😉 Tak czy siak pozostała we mnie satysfakcja, której nikt nie jest w stanie zgasić – satysfakcja ze znalezienia kolejnego dowodu na to, że jednak to nie system jest zły tylko sposób w jaki go wykorzystujemy 😉 Rozumiem, że pracując w korporacji, każdy użytkownik myśli tylko o tym, aby móc zrealizować przypisane do siebie zadania, czasami łamiąc dobre praktyki SAP. Nie chcę wnikać w to, czy ten sam użytkownik rozumie, że powoduje opóźnienie zlecenia niekiedy o miesiąc. Męczy mnie tylko jedno pytanie: Czy jest ktoś kto chciałby zamówić pralkę na najbliższy piątek i otrzymać ją dopiero dwa tygodnie później? Oczywiście, że nie – jako klient nikt nie chciałby być tak potraktowany. Osobiście natomiast nie miałbym nic przeciwko jeśli w momencie składania zamówienia zostałbym poinformowany, że zamówiony towar otrzymam w późniejszym terminie (bo tak wykazywała by kontrola ATP). Wtedy ode mnie zależy decyzja czy poczekam, czy kupię gdzie indziej. Bez względu na to co zdecyduje, będę miał dobrą opinię o sprzedawcy i na pewno do niego powrócę.

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ę.