ERP po latach
- 17.06.2002
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.
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.