"Wdrożenie" polegające na dodaniu komputerów do istniejących rozwiązań organizacyjnych nie ma nic wspólnego z wdrożeniem traktowanym jako inwestycja ekonomiczna.

"Reengineering opóźnia wdrożenie systemów MRP II" - coraz częściej głoszą praktycy, parający się ich wdrożeniami. Natomiast oferowane przez firmy software'owe (wraz z systemami) metodologie wdrażania, wspomagane komputerowymi narzędziami, wręcz zakładają konieczność Rekonstrukcji Procesów Biznesowych - BPR (Business Process Reengineering). Co więcej, ewolucja aplikacji systemów klasy MRP II zakłada przekształcanie funkcjonalnego schematu organizacji przedsiębiorstwa w układ przystosowany do obsługi procesów realizowanych w firmie.

Narzędzia i elementy BPR oferowanego systemu są ważnymi argumentami, za pomocą których sprzedawcy wraz z dostawcą MRP II przekonują zarządy firm - potencjalnych klientów - do zawarcia kontraktu. Natomiast w trakcie realizacji, za obopólną zgodą, etapy projektu mające na celu rekonstrukcję komputeryzowanych procesów w firmie są bagatelizowane lub wręcz pomijane. Do rzadkości należy wykorzystywanie w praktyce skomputeryzowanych narzędzi wspomagających ich rekonstrukcję.

Takie podejście do projektu owocuje w najlepszym przypadku "wdrożeniem" polegającym na okaleczeniu (czyli zaadaptowaniu) standardowego systemu do wymogów realizowanych w firmie procesów. Ich przebieg ukształtowany historycznie często niewiele ma wspólnego z zasadami racjonalności. Ten "cichy kompromis" to jednak najczęściej fundament lepiej ocenianych, bo mniej kłopotliwych dla szefostw obu kontrahentów, projektów.

Pozory mylą

Skierowany do zarządów korporacji zbiór zasad Zarządzanie Zasobami Produkcyjnymi - MRP II (Manufacturing Resource Planning), które zdaniem jego twórców są zdolne odblokować potencjał produkcyjny firm, jak się okazało, łatwiej jest przełożyć na funkcję systemów komputerowych niż wdrożyć do praktyki zarządzania komputeryzowanych firm.

Wdrażanie zasad MRP II oraz nowoczesnych technik zarządzania traktowane w założeniu jako szansa na przyspieszenie krążenia kapitału, pracującego w firmie, ustępuje w praktyce kosztownej inwestycji w system komputerowy MRP II, który jest wdrażany podobnie jak wcześniej lokalnie eksploatowane systemy do mechanizacji i przetwarzania danych (takie jak np. GM, FK, TPP, PP itd.). Jeżeli dla szefostwa firmy projekt wdrażania systemu MRP II nie będzie środkiem do radykalnej restrukturyzacji - usprawnienia procesów realizowanych w firmie, to kierownicy komórek funkcjonalnych oraz przyszli użytkownicy końcowi nowego systemu będą zamierzali odtworzyć w nim stare procedury, ekrany, raporty. A stąd już tylko krok do szkodliwego porozumienia między zespołami problemowymi (wyłonionymi z działów funkcjonalnych firmy) a konsultantami (dostawcy systemu lub jego partnerów), jak najsprytniej dostosować system do stanu istniejącego, to znaczy jak skonfigurować zakupiony system, przenieść istniejące w firmie dane do nowego systemu, opanować podstawowe funkcje oraz dostosować ekrany, raporty i reguły przetwarzania do przyzwyczajeń przyszłych użytkowników wdrażanego systemu. Projekt taki z przedsięwzięcia o charakterze biznesowym staje się przedsięwzięciem czysto informatycznym.

Biada wtedy ambitnemu szefowi projektu lub szefowi-koordynatorowi odpowiedzialnemu za wdrożenie ze strony dostawcy systemu, którzy swoim dyrekcjom zawracają głowy takimi problemami, jak np.

* koniecznością zapoznania pracowników z nowoczesnymi metodami prowadzenia biznesu (MRP - II, JiT, DRP, TQM, controlling itp.)

* koniecznością przeprojektowania komputeryzowanych procesów biznesowych

* weryfikacją - urealnieniem, istniejących danych i ich dostosowaniem do nowych technik zarządzania i sposobu przetwarzania w nowym systemie

* propozycjami zmian organizacyjnych i w zakresie obiegu informacji w firmie.

Natrafiają oni na zdecydowaną opozycję zorganizowaną pod hasłem "to wydłuży wdrożenie", podpartym ostrzeżeniem "i nie wiadomo co z tego wyjdzie", złożoną z:

* członków zespołów problemowych wyłonionych z komórek funkcjonalnych firmy najczęściej źle umotywowanych do przezwyciężania trudności, które niesie nowe

* kierowników średniego szczebla, którzy - nie widząc zdecydowanego dążenia zarządu do zreformowania firmy - bronią swojego status quo

* konsultantów dostawców systemów, chcących się zmieścić w swoich budżetach i uzyskać widoczny efekt wdrożeniowy małym kosztem.

Trudno się więc dziwić, że już na etapie planowania projektu ograniczeniu ulegają działania w dziedzinie BPR na rzecz jak najszybszego przechodzenia do szkoleń w zakresie działania zakupionego systemu oraz uruchamiania jego aplikacji. Jako cele takiego projektu wyodrębnia się wdrożenie systemu w: zaopatrzeniu, księgowości, gospodarce materiałowej itd.

Konsultanci od odpowiednich aplikacji-podsystemów, pracujący wraz z zespołami problemowymi starają się zrealizować je jak najszybciej. Koordynacja takiego projektu ma charakter wynikowy. Najaktywniej pracujący zespół swoimi ustaleniami narzuca rozwiązania mniej zaawansowanym we wdrożeniu zespołom.

Obie strony kontraktu najczęściej godzą się na taki proceder, mimo świadomości że przebieg projektu ma niewiele wspólnego z metodologią, o której tyle mówiono na etapie przedkontraktowym.