2. W większości przedsiębiorstw projekt kompleksowej komputeryzacji firmy opartej na standardowym systemie klasy MRP II ma w efekcie doprowadzić do zastąpienia eksploatowanych w firmie lokalnych systemów sieciowych (typu GM, FK, Kadry i płace itp.) oraz programów/systemów eksploatowanych na komputerach PC. Trudno spodziewać się, że wypracowana na bazie takiego doświadczenia koncepcja zarządzania firmą na etapie przedkontraktowym nie ulegnie znacznej modyfikacji na kolejnych etapach realizacji projektu. Dlatego też niezaprzeczalnym osiągnięciem wspomnianego przez Mariana Kurasia brytyjskiego konsultanta (pełniącego funkcję dyrektora ds. informatyki w firmie BREWPOLE) było stworzenie międzyaplikacyjnego zespołu, złożonego z członków kierownictwa, oddelegowanych do realizacji projektu i zewnętrznych konsultantów, który to zespół w trakcie spotkań z członkami zarządu firmy dyskutował poszczególne elementy koncepcji zarządzania firmą w dwóch aspektach:

• w kontekście możliwości zakupionego standardowego systemu i rozsądnego zakresu jego adaptacji

• w kontekście koniecznych korekt zamierzeń zarządu firmy, co do docelowej (po zakończeniu projektu) koncepcji zarządzania firmą.

Takie właśnie (często zalecane również w literaturze przedmiotu) podejście do tworzenia koncepcji zarządzania firmą wdrażającą system klasy MRP II uważam za szczególne godne polecenia przedsiębiorstwom działającym na terenie Polski.

3. Standardowe systemy klasy MRP II, oferowane obecnie na podobnych warunkach cenowych, nie różnią się w sposób zasadniczy, jeżeli chodzi o zakres funkcji i możliwości wspomagania procesów zarządzania. Wystarczy porównać chociażby oceny, publikowane w Raporcie Specjalnym Computerworlda. Jak zwykle, problemy tkwią w szczegółach. Toteż w metodologiach wdrażania wszystkich ważniejszych systemów tej klasy zakłada się, że:

• Wersja standardowa systemu ulegnie modyfikacji na etapie wdrażania.

• Proces modyfikacji systemu przez użytkownika powinien być możliwy zarówno na etapie wdrażania, jak i w trakcie eksploatacji. Dlatego oferowane wersje mają specjalne języki, funkcje i aplikacje wspomagające adaptację systemu do potrzeb przedsiębiorstwa.

• System osiąga pełną zdolność dopiero po zrealizowaniu czwartego etapu realizacji projektu, w którym następuje dostrajanie systemu, doskonalenie bazy danych oraz integracja. Pomijanie tego etapu, który może trwać nawet i kilka lat po uruchomieniu systemu; to jedna z ważniejszych przyczyn niezadowalających efektów ekonomicznych realizowanych projektów.

• Wersje tego samego systemu standardowego wdrożone i eksploatowane aktywnie w dwóch różnych przedsiębiorstwach mogą różnić się w sposób zasadniczy nie tylko jeżeli chodzi o postać ekranów, wydruków, ale również i co do zakresu dodatkowych funkcji realizowanych przez system.

• Szef projektu - postać kluczowa, ale nie jedyna decydująca o jego losie

Zgadzam się z Marianem Kurasiem, że trudno bezkrytycznie akceptować koncepcję realizacji każdego szefa projektu. Nie mogę jednak zgodzić się z suponowaniem osobom, pełniącym takie funkcje, bezmyślności, jak to czyni autor: "Po co budujesz dom? Po to, żeby nadzór budowlany go odebrał. Po co kopiesz węgiel? Po to, żeby załadować węglarkę". Nie usprawiedliwia do tego autora nawet wypowiedź szefa projektu, z której jasno wynika ekonomiczny cel projektu. Za moim stanowiskiem przemawiają następujące argumenty:

1. Do rzadkości należy powierzanie roli szefa projektu osobom, które nie traktowałyby jako truizm stwierdzenia, że pieniądze wydatkowane na projekt, powinny się zwrócić i przynieść korzyść firmie realizującej projekt. Ja takiego nie spotkałem. Funkcji tej podejmują się najczęściej ludzie mający rzeczywiste sukcesy menedżerskie w różnych dziedzinach. Prowadzenie nowatorskich przedsięwzięć obarczonych dużym ryzykiem, a do takich należy wdrażanie systemów klasy MRP II, traktują oni jako kolejne wyzwanie zawodowe. I choćby z tego tytułu należy się im szacunek, zarówno wtedy, gdy odnoszą sukcesy, jak i gdy ponoszą porażki, również od tych, którzy nie akceptują ich sposobu działania.