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