Sukces sprawnego wdrożenia pakietu ERP, wymaga pełnego zaangażowania obu stron to jest: Kupującego i Wdrażającego. Od kupującego wymagana jest świadomość tego co nabywa, oraz przygotowania swojej organizacji do zmiany. Wdrażający również powinien zainteresować się, czy Kupujący odrobił swoją pracę domową, w przeciwnym razie istnieje duże prawdopodobieństwo, że nie zrealizuje zadania zgodnie z harmonogramem i budżetem. Śmiem twierdzić, że większość niezrealizowanych o czasie projektów IT, jest wynikiem braku przygotowania organizacji do tak dużej zmiany, jeżeli chcesz robić biznes na wdrożeniach sprawdź gotowość Twojego klienta do zmiany oraz jego potrzeby w zakresie IT. To długofalowo jest dobre dla obu stron. No chyba, że celem Twojej działalności jest rozpowszechnienie informatyzacji traktowane jako hobby i działalność niezorientowaną na zysk.
W momencie, gdy Kupujący jest gotowy do zmiany, wybrał już najlepiej dopasowany do własnych potrzeb system IT pozostało podpisać umowę wdrożeniową z świadomie wyselekcjonowanym dostawcą usług konsultingowych.

Metodologie wdrożenia… moim zdaniem co innego dostarczy większych korzyści.
Sama metodologia wdrożenia (sposób działania w projekcie) moim zdaniem ma drugorzędne znacznie, tzn dopracowanie poniższych tematów ma o wiele większe przełożenie na terminowe i zgodne z budżetem zakończenie prac. Z tego też powodu na tym koncentruję swoje działania.

Zespoły wdrożeniowe.
Idealny członek zespołu wdrożeniowego po stronie Kupującego to młoda osoba, która jest w firmie od co najmniej dwóch lat. Pod określeniem młoda, rozumiem pracownika, który doskonale wie czym jest „core biznes” swojego przedsiębiorstwa, ma potencjał wzrostu, bystrość umysłu oraz czuje co to software komputerowy. Taka umiejętność wyobrażenia sobie, czym jest program, co to są linie kodu, jest niezbędna przy analizie kosztu do korzyści, która jest wykonywana w momencie podejmowania decyzji o objęciu wdrożeniem danej czynności w procesie. Szybkie podejmowanie trafnych decyzji jest kluczowe dla wszystkich faz projektu.

Fundusz motywacyjny
Zwolnienie z normalnie wykonywanych obowiązków wszystkich członków zespołów wdrożeniowych może być zagrożeniem dla płynnego funkcjonowanie przedsiębiorstwa. Z tego też powodu, gorąco polecam opracowanie pokaźnego funduszu motywacyjnego. Celem tego funduszu jest motywowanie pracowników, docenienie przejściowego okresu, w którym pracują na więcej niż 100%. Zgrubne reguły podziału funduszu, muszą być jasne i podane do publicznej wiadomości na samym początku wdrożenia. W temacie motywacji, należy pamiętać, aby stale podkreślać jak ważny jest to projekt dla zarządu o Prezesie nie zapominając.

Standard pakietu
Należy wykorzystywać standardowe funkcjonalności i procesy pakietu ERP, tam gdzie skutecznie realizują założony cel, nawet jeżeli dawniej robiono to inaczej. Temat jest pokrewny z właściwym przygotowaniem do wdrożenia, o którym pisałem na początku. Przy modyfikacji standardu danego rozwiązania, należy pamiętać o następujących konsekwencjach:

Główną zaletą pakietów pudełkowych jest fakt, że zawierają one w sobie gotowe procesy biznesowe. Naszym zadaniem jest określenie, których chcemy używać oraz skonfigurowanie struktury przedsiębiorstwa w systemie. W momencie, gdy dokonujemy modyfikacji standardowego procesu, to oprócz utraty gwarancji na tę część systemu, potencjalnych kłopotów przy ugrejdzie a nawet po wczytaniu not korygujących należy pamiętać że: w pakietach ERP, konkretne linie kodu uruchamiają się w zależności od akcji użytkownika podczas jego pracy. Naciśnięcie lub nie danego przycisku, uaktywnia funkcją zapisaną przez linie kodu. Z tego prostego powodu, zakodowanie rozwiązania w programie, który „żyje własnym życiem” nawet gdy algorytm jest prosty nie jest banalne. Cała trudność polega na połączeniu nowego programu ze standardem. Jakość naszej pracy jest możliwa do zweryfikowania dopiero po uruchomienieu nowej funkcjonalności. Wówczas dopiero widoczne są tematy, które z uwagi na ogromne ilości standardowego kodu pakietu ERP, nie były do przewidzenia na etapie opracowywania specyfikacji. W efekcie potrzebujemy dużego budżetu na testowanie rozwiązania, w wielu przypadkach jest to taka niekończąca się historia, po wyeliminowaniu danego błędu pojawiają się nowe.
Powyższe przykłady nie zagwarantują oczywiście 100% skuteczności (kolejne opisze w oddzielnych postach), moim zdaniem skupienie się na nich, dostarczy największego rezultatu. Dopilnowanie tych tematów leży w interesie wszystkich stron w s p ó l n e g o projektu.