Kolejny, już piąty, z serii wpisów gościnnych dr hab. inż. Andrzeja Zalewskiego na temat wdrożenia ERP. Wpisy te pierwotnie opublikowane były na grupie FB, dzięki uprzejmości autora prezentujemy je również na łamach Rudej Strony Zarządzania.

Kastomizacje. Case nr 3. WMS i specyfika magazynu

Kastomizacje to modyfikacje lub uzupełnienia logiki systemu – np. przez dodanie pewnych danych, modyfikację sposobu prowadzenia obliczeń czy przedstawiania danych na ekranie komputera czy w raportach. Kastomizacjami osiągamy to, czego nie da się uzyskać przez nadanie odpowiednich ustawień. Nie każdy system pozwala na wykonywanie kastomizacji. Czasem możliwości kastomizacji ograniczane są do możliwości tworzenia własnych raportów.

Kupując system ERP a potem go wdrażając stajemy przed dylematem: na ile organizacja powinna dopasować się do systemu, a na ile system powinien zostać dopasowany do specyfiki organizacji. Słowem: ile standardu, a ile kastomizacji? A może w ogóle system skrojony na miarę pod nasze potrzeby?

ILE KASTOMIZACJI A ILE STANDARDU?

Generalna zasada brzmi: jak najmniej kastomizacji, a jak najwięcej standardu. Za aktualizację standardowej funkcjonalności odpowiada producent (jemu płacimy za to w opłatach licencyjnych), za aktualizację kastomizacji – zwykle firma użytkująca system.

Kastomizacje – to dodatkowy koszt przy wdrożeniu, ale też przy utrzymaniu i rozwoju. Kastomizacje powinny dotyczyć procesów, działań kluczowych, dających przewagę konkurencyjną, takich od których zależy dostarczanie wartości przez system. Jeśli liczba kastomizacji robi się bardzo duża – np. trzeba kastomizowć system dla 70% procesów – to jest to sygnał alarmowy wskazujący, że nie najlepiej został wybrany system ERP.

No i czasem może się okazać, że bez kastomizacji ani rusz.

WMS, WĄSKIE DRZWI I KOMPLETACJA WIELOFAZOWA

Pewna firma zamówiła kiedyś system ERP, którym wesprzeć miała obsługę magazynowania (WMS – system obsługi magazynu /wysokiego składowania/) i sprzedaży. Posiadała dwa magazyny w jednym budynku – jeden (1) wysokiego składowania (towary na paletach na kilku poziomach) oraz stary (2) nie tak wysoki jak ten już tu opisany. Między tymi magazynami były niskie drzwi. Na tyle niskie, że typowy wózek widłowy nie był w stanie przez nie przejechać.

Aby skompletować zamówienia należało pobrać wyroby zarówno z magazynu (1), jak i (2). Normalnie dzieje się to tak, że wózkiem widłowym zwozi się palety na miejsce odkładcze, tam wyjmuje się potrzebne do zamówienia wyroby, kompletowanie może odbyć się przez objechanie kilku miejsce odkładczych lub z jednego, następnie przewiezienia towaru na miejsce, gdzie zostanie zapakowany i przygotowany do transportu.

Zapewne dla kogoś, kto pracuje w takim magazynie, to oczywista oczywistość. Tu jednak okazało się, że:

  • nabyty (okazyjnie) ERP… nie wspiera dwufazowej kompletacji… czyli trzeba by zdejmować paletę, wybierać towar i odkładać paletę a z wybranym towarem jechać dalej;
  • miejsca odkładcze dla magazynu niskiego są w magazynie wysokim – system wogóle nie przewiduje takiej opcji – próbowano zaadresować problem generując zlecenia przesunięcia międzymagazynowego (tzw. MM), ale jak wtedy skierować taką paletę z powrotem na miejsce w niskim magazynie;
  • no i wreszcie – nie wiadomo, jak przewieźć paletę między tymi magazynami, bo wrota są za niskie dla wózka widłowego – trzeba by je transportować wózkiem ręcznym.

Rozwiązaniem było dopisanie odpowiedniej kastomizacji… Tu jednak dochodzimy do omawianego już tematu – „Pieniądz robi projekt” i zniecierpliwienia zamawiającego, kluczącego wykonawcy itd.

Nie skończyło się to dobrze.

TAKEAWAYS

  1. Diabeł tkwi w szczegółach. Dobrze wiedzieć, który szczegół jest szczegółem krytycznym…. często wiadomo to dopiero, gdy już mleko się rozleje;
  2. Dobrze, gdy wybrany system ERP jest dobrze dopasowany do potrzeb firmy i nie wymaga nadmiernej kastomizacji;
  3. Kastomizacja potrafi uratować projekt, jeśli zostanie przeprowadzona… tu gdyby nie spór i upór stron wszystko skończyłoby się dobrze;
  4. Czasem kastomizacją spłacamy „dług techniczny” zaciągnięty podczas sprzedaży nadmiernie rozbuchanymi obietnicami, za spełnienie których klient musi potem dodatkowo zapłacić.

O autorze

Andrzej Zalewski, dr hab.

Informatyk pracujący na Politechnice Warszawskiej, gdzie uczy algorytmiki oraz zarządzania projektami informatycznymi w firmach. Udziela się również jako ekspert i biegły w dziedzinie inżynierii oprogramowania. Kieruje Studiami Podyplomowymi Zarządzanie Zasobami IT oraz Zarządzanie projektami.