Kiedy przyglądam się wdrożeniom systemów ERP, mam wrażenie, że często mijają się ze swoją ideą, ponieważ wdrażane są wszystkie moduły z wyjątkiem modułu planowania potrzeb materiałowych i planowania produkcji, które historycznie stanowią trzon tego rodzaju systemów.

Idea systemów ERP polega na tym, by poprzez wdrożenie wszystkich modułów w nowy sposób zacząć zarządzać przedsiębiorstwem. Jeśli system nie jest spójny, nie obejmuje wszystkich obszarów zarządzania przedsiębiorstwem łącznie z produkcją, są duże szanse na to, że okaże się całkowitym niewypałem. Problem z systemami ERP jest taki, że jakość rozwiązania jest zależna od jakości najgorszego komponentu. Jeśli nie udało się wdrożenie modułu produkcyjnego - wdrożenie się nie udało. Jeśli nie udało się wdrożenie modułu dystrybucyjnego - wdrożenie się nie udało. Jeśli nie udało się wdrożenie modułu planowania - wdrożenie się nie udało. Szanse związane z wdrożeniem systemu ERP są bardzo duże, ale ryzyko związane z takim projektem jest również bardzo wysokie. To rodzaj projektów, które trwają długo, wymagają bardzo dokładnego planowania i ogromnego zaangażowania wszystkich zainteresowanych.

W jakim stopniu sukces wdrożenia jest zależny od wyboru konkretnego rozwiązania, konkretnej technologii?

W projektach ERP część informatyczna nie powinna koncentrować na sobie całej uwagi zespołu projektowego, ponieważ jest ona najmniej ważna. Oprócz niej jest mnóstwo pracy do wykonania. Musi zostać wprowadzona kultura zmiany. Musimy mieć zaangażowanie kierowników na różnych szczeblach, z różnych departamentów i oczywiście zaangażowanie kluczowych dostawców technologii. W tych projektach chodzi o coś więcej niż zakup oprogramowania, up-grade sprzętu komputerowego, wdrożenie oprogramowania i voil`a - mamy rozwiązanie. Przez większość czasu jesteśmy zorientowani na technologię, a nie na ludzi, co jest poważnym błędem. Część technologiczna to zaledwie 10% projektu. 90% to organizacja i ludzie, procesy, procedury, komunikacja, zarządzanie, zarządzanie zmianą. Najsłabszym elementem zarządzania projektami jest brak komunikacji lub niewłaściwa komunikacja, której efektem są niejasne wymagania użytkowników, niejasny zakres projektu, niejasna lub wręcz nie znana uczestnikom projektu wizja celów do osiągnięcia.

Jaka jest przydatność szkoleń w zakresie zarządzania projektami w praktyce?

Większość z nas została menedżerami projektu przez przypadek. Uczymy się tej pracy, wykonując ją. Jeśli zapyta pani dziecko "kim chcesz być w przyszłości?", prawdopodobnie odpowie "astronomem, strażakiem, lekarzem, aktorem", ale nie sądzę, by jakiekolwiek dziecko myślało o tym, by zostać menedżerem projektu. Zasadniczo uczymy na tych kursach zdrowego rozsądku, tylko że w sformalizowany sposób. Project Management Body of Knowledge, kompendium wiedzy w zakresie zarządzania projektami opublikowane przez Project Management Institute, to nic innego, jak zbiór najlepszych metod rozwiązywania pewnych problemów (best practices). Metod, które zebrali i udokumentowali praktycy, menedżerowie prowadzący rzeczywiste projekty. To nie jest efekt pracy profesorów uniwersytetów. Zdobycie tego rodzaju wiedzy jest niezwykle drogie, jeśli zdobywamy ją w trakcie pracy, bo musimy popełnić naprawdę wiele błędów, by czegoś się nauczyć. Z punktu widzenia praktyków ten kurs to pewne uporządkowanie wiedzy, nadanie jej formalnych ram, wprowadzenie wspólnej terminologii i udostępnienie zasobów wiedzy wcześniej niedostępnej. To nauka esperanto zarządzania projektami. Jeśli ktoś dopiero zaczyna zarządzanie projektami, jest szansa, że ten kurs będzie ekwiwalentem uczenia się na własnych błędach, przyspieszy proces uczenia się zarządzania projektami w trakcie pracy.

Jaka jest różnica między zarządzaniem projektami a zarządzaniem projektami informatycznymi?

Na pewnym podstawowym poziomie mówimy o tym samym. Podstawowe narzędzia i techniki są te same i znane od dawna. Ale są pewne narzędzia i techniki specyficzne dla zarządzania projektami informatycznymi, na przykład w zakresie zarządzania ryzykiem czy szacowania harmonogramów. Największe wyzwanie w prowadzeniu projektów informatycznych wynika z faktu, że nie mamy historycznej, udokumentowanej bazy wiedzy na temat przeprowadzonych projektów. W przypadku projektów budowlanych sprawa wygląda inaczej, mamy szczegółową dokumentację dotyczącą każdego etapu budowy, w każdym momencie możemy sięgnąć do dawniejszych doświadczeń. Drugi problem - projekty informatyczne rzadko są dobrze zdefiniowane. Nie zaczyna się budowy domu, nie mając szczegółowego projektu architektonicznego. Ale praktyka dowodzi, że budowę oprogramowania można zacząć w zasadzie bez planu. I trzeci problem - technologia, która szybko się zmienia.

W jaki sposób powinna być budowana baza wiedzy gromadząca doświadczenia z wcześniejszych projektów?

Z pewnością powinien być to wysiłek całej organizacji, a nie jednego menedżera projektu, i zadanie to powinno być traktowane bardzo poważnie. Ponadto wiedza ta musi być wykorzystywana. Zazwyczaj nikt - motywując to brakiem czasu - nie korzysta z doświadczeń kolegów zawartych w dokumentacji projektu (lessons learned). Jeśli nie jesteśmy w stanie transferować wiedzy, nie tworzymy wartości organizacji, w której pracujemy.

Ale czy istnieją specjalne narzędzia umożliwiające budowę takiej bazy wiedzy?

To nie jest problem narzędzi. Zawsze są i zawsze były odpowiednie narzędzia, na rynku dostępnych jest wiele narzędzi umożliwiających uchwycenie tej informacji, ale nie o to chodzi. Chodzi o zaangażowanie, chęć gromadzenia nabywanej wiedzy i dzielenia się nią. Większość ludzi podziela przekonanie, że nie mamy czasu na budowanie prototypów, ale zawsze mamy czas na naprawienie czegoś, co powstanie. Myślimy "zbudujmy to, dostarczmy klientowi, a potem będziemy poprawiać", co jest powiązane z myśleniem "dlaczego mam teraz inwestować w coś, co wykorzystam lub nie wykorzystam później albo wykorzysta to ktoś inny". Istnieje też inny problem. Stworzenie dokumentacji poprojektowej wymaga uczciwości przyznania się do popełnionych błędów. To jest trudne i możliwe tylko w organizacji, w której istnieje przyzwolenie na popełnianie błędów.

I jeszcze jedno. Już teraz w większości organizacji 50% pracy jest wykonywane w ramach projektów i odsetek ten będzie się stale zwiększał. Musimy wreszcie zacząć się uczyć zarządzania nimi.

George R. Sifri ma piętnastoletnie doświadczenie w zakresie zarządzania projektami informatycznymi, jednocześnie prowadzi wykłady w tym zakresie na całym świecie. Obecnie jest kierownikiem działu rozwoju oprogramowania w Consolidated Contractors Company, największej bliskowschodniej firmie budowlanej, zatrudniającej ponad 35 tys. pracowników. Uzyskał doktorat w zakresie sieciowych systemów informatycznych, umożliwiających zarządzanie projektami. Jest certyfikowanym audytorem systemów informatycznych. Uzyskał Master's Certificate in Information Technology Project Management, przyznawany przez George Washington University, oraz certyfikat Project Management Professional, przyznawany przez Project Management Institute.