Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
spotykam coraz częściej klientów morzem Z, Y Tranzakcji. Ludziska dziargają na potęge Co wpadło mi w oko to zabójcza ilość błędów, szczególie przy HU, Batch, WM kombinacji. Co dalej jakikolwiek support z zewnątrz ad hoc jest ograniczony, lub odpowiednio wydłużony.
Witam z powrotem
Istotnie Z-programy to plaga praktycznie wszystkich wdrożeń SAP. Moim zdaniem wynikają one w głównej mierze z niekompetencji konsultantów, którzy nie znają standardu SAP i łatwiej im powiedzieć klientowi, że "się nie da" i pisać własne Z-wynalazki. Przy tym model opłaty za wsparcie oparty o dniówkę czasu pracy konsultanta skłania do długotrwałego pisania Z-programów w miejsce szybkiego wdrożenia standardu. Z drugiej strony rzadko, który klient docenia wiedzę i chce za nią odpowiednio zapłacić. Jakoś wygodniej i psychicznie bardziej komfortowo jest płacić za czas pracy, a nie za jej efekt.
Podam przykład firmy produkcyjnej, gdzie znana firma wdrożeniowa przez miesiące walczyła z problemem rozliczenia produkcji łącznej wg faktycznie wyprodukowanych ilości. Próbowali pisać jakieś horrendalne rozszerzenia, które miały dynamicznie zmieniać przepis rozliczeniowy w zleceniu produkcyjnym. Pomysł słaby i praktycznie nierealizowalny. Co ciekawe wymaganą funkcjonalność SAP miał w standardzie - wystarczyło przeczytać dokumentację i włączyć tę funkcję. W sumie więcej czasu zajęło mi wykasowanie tych rozszerzeń niż uruchomienie standardu. Jakoś tak dziwnie się porobiło, że obecnie czytanie ze zrozumieniem przychodzi ze znacznie większym trudem niż pisanie w ABAP'ie
Nie twierdzę, że zawsze Z-programy są niewłaściwe. Uważam, że tak jak ze wszystkimi narzędziami trzeba wiedzieć kiedy i jakie stosować.
Popieram... pracuje w SAP z Z-transakcjami. Niektóre naprawdę są dobre, ale to tylko te, które pełnią funkcję monitorów lub skrótów do innych transakcji - z jednego miejsca można przejść do różnych innych standardowych. Ale ilość tych Zetek i kopii ruchów jest tak duża, że ludzie praktycznie nie używają transakcji standardowych. Wystarczy tylko jeden błąd w WM i nikt nie wie jak sobie poradzić, bo mało kto umie skorzystać ze standardowej transakcji nie będącej Zetem. Własne transakcję nauczyły ludzi klepaniny bez zrozumienia tego co robią (w końcu to tylko liczby), a to z kolei prowadzi do braku świadomości popełnianych błędów, na których korygowanie trzeba poświęcać dużo czasu.
Co wpadło mi w oko to zabójcza ilość błędów, szczególie przy HU, Batch, WM kombinacji. Co dalej jakikolwiek support z zewnątrz ad hoc jest ograniczony, lub odpowiednio wydłużony. 
