ERP po latach

Kilka lat użytkowania systemu ERP pozwala spojrzeć z dystansu na słuszność decyzji podjętych przed i w trakcie wdrożenia.

Kilka lat użytkowania systemu ERP pozwala spojrzeć z dystansu na słuszność decyzji podjętych przed i w trakcie wdrożenia.

Paweł Podziewski, odpowiedzialny za system SAP R/3 w British American Tabacco SA w Warszawie

Paweł Podziewski, odpowiedzialny za system SAP R/3 w British American Tabacco SA w Warszawie

Ci, którzy pamiętają sposób działania firmy przed wdrożeniem systemu ERP, nie mają zazwyczaj wątpliwości, że przedsięwzięcie to miało sens. Systemy ERP narzucają z reguły lepszą organizację pracy i pozwalają uzyskać oszczędności wynikające m.in. z krótszego czasu realizacji zamówień, precyzyjnego planowania, kontroli kosztów i należności, a także mniejszego zaangażowania kapitału. Bezpośrednio po zakończeniu wdrożenia widoczne są przede wszystkim jego "porządkujące" efekty. Z biegiem czasu użytkownicy zauważają mankamenty zarówno rozwiązania, jak i przyjętego sposobu implementacji. Po pewnym okresie funkcjonowania system ERP ulega demitologizacji i użytkownicy zaczynają dostrzegać jego ograniczoną - wbrew zapewnieniom dostawcy - funkcjonalność. Czas weryfikuje założenia dokonywane na starcie projektu. To, co kiedyś wydawało się ważne, dziś może nie mieć wielkiego znaczenia, i odwrotnie, a wprowadzanie zmian okazuje się żmudne i kosztowne. Im dłuższy okres mija od zakończenia projektu, tym więcej tego typu spostrzeżeń. Czy z doświadczeń pionierów ERP płyną jakieś wnioski dla przyszłych wdrożeń?

Gdy ogon macha psem

Decyzją, która ma fundamentalne znaczenie dla powodzenia wdrożenia jako całości, jest wybór systemu. "Decydując się na określony system informatyczny, wybieramy jednocześnie zaproponowany przez jego twórców sposób na biznes. Dostawcy zawsze twierdzą, że ich system może obsłużyć dowolnie zorganizowa- ne przedsiębiorstwo, zapominają tylko dodać, że w niektórych przypadkach modyfikacje wymagają ogromnego nakładu sił i środków. Rozpoczynanie projektu od wyboru systemu i późniejsze próby przyporządkowania go specyfice firmy to najgorsza rzecz, jaką można zrobić" - przekonuje Zbigniew Śliwa, kierownik działu informatyki w SGL Carbon sp. z o.o. w Nowym Sączu.

Nie oznacza to, że nie można zaakceptować metod zarządzania "zaszytych" w systemie informatycznym, trzeba mieć tylko świadomość, że ich akceptacja wymaga zmian metod działania firmy decydującej się na wdrożenie, a jednocześnie ich mechaniczne odwzorowanie nie spowoduje jeszcze wzrostu wartości firmy. "Niektóre pomysły biznesowe zawarte w systemach zintegrowanych jako "gotowe procesy" są naprawdę genialne. Ich wykorzystanie ma jednak sens tylko wówczas, gdy podążymy śladem rozumowania ich twórców od początku do końca. System wdrożony wyrywkowo straci swoją unikalność i wynikającą z niej przewagę konkurencyjną" - dodaje Zbigniew Śliwa.

Dawkowanie zmian

Obserwując z perspektywy swoje potyczki z systemem, większość szefów projektów przychyla się do poglądu, że wprowadzanie do systemu wielu - zwłaszcza gruntownych - modyfikacji powoduje więcej szkody niż pożytku. Problemy wynikające z modyfikacji systemu objawiają się w pełni podczas przechodzenia do jego nowej wersji. "Zmiana standardu i uzupełnianie go nowymi funkcjami zawsze niosą ryzyko. Niejednokrotnie nowa wersja pociąga zmianę architektury, a wówczas stare modyfikacje mogą w nieprzewidziany sposób zdestabilizować nowy system" - twierdzi Paweł Podziewski, odpowiedzialny za system SAP R/3 w British American Tobacco SA w Warszawie.

Kwestia zmian ma też oczywiście aspekt finansowy. "Wykonanie rozszerzeń i modyfikacji jest szczególnie kosztowne dla firmy, która nie ma własnego zespołu programistów, ponieważ usługi te trzeba kupić od firmy zewnętrznej. Do kosztów poniesionych w trakcie wdrożenia dochodzą koszty utrzymania poprawek po wdrożeniu - im więcej poprawek, tym więcej czasu trzeba poświęcić na ich przeniesienie do nowego systemu po każdej jego aktualizacji. Z moich doświadczeń wynika, że często prościej i taniej jest dostosować organizację do systemu niż dokonywać w nim zmian" - przekonuje Małgorzata Jankiewicz, kierownik działu informatyki w Lubella SA w Lublinie. Okazuje się więc, że każda wprowadzona zmiana znacznie zwiększa całkowity koszt posiadania systemu (Total Cost of Ownership), co w długim okresie może zachwiać ekonomicznymi podstawami całego przedsięwzięcia i zniwelować uzyskane dzięki niemu korzyści.

Jak zwykle najlepszym rozwiązaniem okazują się umiar i zdrowy rozsądek. "Modyfikacji standardu nie da się uniknąć, trzeba jednak pilnować, aby nie były one zbyt zasadnicze. Niestandardowe funkcje lepiej wynosić poza system niż modyfikować wersję standardową. Warto pamiętać, że nowe wersje zawierają niejednokrotnie rozszerzenia istniejących funkcji oraz funkcje zupełnie nowe, co pozwala zrezygnować z części dotychczasowych modyfikacji i rozszerzeń. Dzięki zastosowa- niu takiego podejścia, mimo upgrade'u MFG/PRO z wersji 7.4 do 8.6, udało się nam utrzymać system w należytym porzą- dku" - radzi Artur Traczyk, dyrektor działu informatyki w Cussons Polska sp. z o.o. w Warszawie.