Kolejnym często na tym etapie popełnianym błędem jest poszukiwanie dostawcy systemu klasy MRP II ("omnibusa"), który przejmie na siebie rolę dostawcy sprzętu, wykona sieć, dostarczy system klasy MRP II, dostarczy szkoleń i konsultacji w zakresie eksploatacji systemu oraz zabezpieczy konsulting biznesowy. Nazywa się to ładnie - wykona inwestycje pod klucz. Chęć podpisania kontraktu skłania często dostawcę systemu do podjęcia się zadań, do wykonania których jego firma jest zupełnie nie przygotowana. Dla realizacji takiego kontraktu w efekcie zostaną zatrudnione (podnajęte) inne firmy, co nie tylko podraża koszt realizacji projektu, ale co najgorsze koordynacja wymyka się spod kontroli firmy realizującej projekt. Firma "omnibus" to najczęściej firma o małym doświadczeniu w realizacji tego typu projektów i dlatego tak spolegliwa na etapie podpisywania kontraktu, natomiast mało sprawna przy jego realizacji.

Etap II - organizacja projektu i prototypowanie

Etap ten rozpoczyna się w momencie podpisania kontraktu z dostawcą systemu klasy MRP II, a kończy stworzeniem w firmie przez zespół roboczy prototypu przyszłego systemu. Wydanie przez naczelnego dyrektora firmy zarządzenia o organizacji projektu rozpoczyna realizację drugiego etapu.

Częstym grzechem popełnianym przez firmy realizujące projekty jest brak takiego zarządzenia. Jest ono zastępowane przez mniej lub bardziej akceptowane przez kierownictwo koncepcje współdziałania, poparte ogólnymi zarządzeniami dyrektorów. Jest to grzech, który w efekcie:

• rodzi wątpliwości co do rangi projektu

• powoduje rozmydlenie odpowiedzialności

• często uniemożliwia rozwiązywanie konfliktów, których nie brakuje w tego typu projektach.

Częstym błędem popełnianym przez firmy realizujące omawiane projekty jest formułowanie celów w sposób niekonkretny najczęściej w kategoriach informatycznych. Na przykład: komputeryzacja zaopatrzenia, wdrożenie podsystemu Planowania Produkcji, zmniejszenie zatrudnienia, itd. Tak sformułowane cele są mało zrozumiałe i mało zachęcające dla ich wykonawców, trudno ocenić ich realizację, a co najgorsze powodują dążność do dostosowywania wdrażanego systemu do istniejących metod, praktyk i przyzwyczajeń w zakresie zarządzania firmą.

W prowadzonych w Polsce projektach komitet sterujący często zastępuje się posiedzeniami obecnych w danym momencie członków zarządu, wymuszonymi przez szefa projektu na okoliczność konkretnej sytuacji konfliktowej, trudności w realizacji projektu, itd. Z reguły przedmiotem takiego posiedzenia jest poszukiwanie winnego i dyskusje, co zrobić. Trudno w takiej sytuacji o wypracowanie konstruktywnej decyzji. Jeżeli nawet zostanie ona podjęta w gronie przypadkowym, członkowie zarządu nieobecni na posiedzeniu często nie czują się nią zobligowani.

Bardzo ważne jest, żeby powierzenie funkcji szefa projektu danej osobie było przez nią i otoczenie odebrane jako awans, a nie, jak się to niestety często zdarza, "zneutralizowanie na dłuższy okres" kandydata na wysokie stanowisko kierownicze w firmie.

Naganne jest częste traktowanie (przez zarządy firm) problemów związanych z takimi projektami jako przejawu niezaradności szefa projektu, a co najgorsze upublicznianie w firmie takich ocen. Brak zdecydowanego poparcia zarządu dla osoby pełniącej funkcję szefa projektu, dyskredytowanie go i pozostawianie dalej w tej samej roli jest jedną z ważniejszych przyczyn nieudanych projektów.

Nierzadko taki projekt staje się okazją do pozbycia się z działów osób niewygodnych lub obarczenia osób i tak już przeciążonych dodatkowo uczestnictwem w pracach zespołu roboczego. Jest to, jak pokazuje doświadczenie, kolejna najważniejsza przyczyna nieudanych projektów.

Niewiara we własne siły i ślepa wiara w geniusz konsultantów zewnętrznych - najlepiej z firm o światowej renomie - powoduje zlecanie firmom konsultingowym rozwiązywania zagadnień koncepcyjnych, zamiast korzystania z ich konsultacji czy szkoleń przy rozwiązywaniu problemu w ramach kierownictwa firmy. W efekcie firma uzyskuje mało "strawne" opracowania, często nie pasujące do realiów firmy, i to za bardzo duże pieniądze.

Niestety, niezrozumienie roli i konieczności prototypu przez firmy realizujące tego typu projekty zachęca ich do pójścia "na skróty". W efekcie:

• członkowie zespołu wdrożeniowego umiejscowieni na swoich dawnych stanowiskach (udają, że) godzą pracę nad projektem z pracą wynikającą z ich obowiązków służbowych

• szkolenie zespołów problemowych, a często i użytkowników końcowych, powierza się konsultantom dostawcy systemu

• jeżeli w wyniku tak prowadzonego projektu powstaje jakaś baza do ćwiczeń, to ma ona charakter cząstkowy i niespójny - trudno uznać ją za prototypową

• koordynacja tak prowadzonego projektu jest praktycznie niemożliwa.

Wspólna praca osób o różnym doświadczeniu zawodowym nad prototypem przyszłego systemu zarządzania firmą nie może być realizowana sensownie w ramach wolnego czasu od bieżących spraw. Dlatego kierownictwo firmy powinno pogodzić się z koniecznością oddelegowania osób do pracy w zespole roboczym przynajmniej do zakończenia prototypowania, w pełnym wymiarze godzin. Niestety, jest to najtrudniej akceptowany przez zarząd firmy postulat.