Są one wspólne dla zasad kierowania projektami i wiele znanych metodyk wdrażania pakietów ERP je uwzględnia. Dzisiejsze praktyczne ich realizacje są natomiast wielokrotnie od tych podstaw oderwane. Cel projektu musi być uwzględniony w celach gospodarczych użytkownika. Przykładowo, jeżeli celem gospodarczym jest sprawność i szybkość obsługi klienta, powinno to wpływać na kierunek przebudowy procesów gospodarczych. Jednym z celów wdrożenia będzie wtedy zapewne uproszczenie i skrócenie procesu obsługi zleceń sprzedaży. Jeżeli jednym z celów gospodarczych jest przyspieszenie rotacji zapasów, to głównym celem wdrożenia będzie wprowadzenie jednej z metod sterowania zapasem (SIC, MPS itp.). Efektywne metodyki zapewnią zawsze zgodność działań wdrożeniowych z celem wdrożenia i celami gospodarczymi. Przykłady rzeczywistych wdrożeń potwierdzają, jak ważne jest wskazanie, np. przez właściciela projektu, że dany proces biznesowy należy uprościć - albo rozbudować - w celu realizacji celów gospodarczych.

Efektywność biznesowa wymaga jasno zdefiniowanego zakresu wdrożenia. Jego zrealizowanie oznacza obsłużenie za pomocą aplikacji wymaganych funkcji gospodarczych, co z kolei daje podstawę do oczekiwania zwrotu z inwestycji. Praktycznie występujące dziś metodyki abstrahujące od zakresu wdrożenia (firma XYZ wdroży oprogramowanie ABC w przedsiębiorstwie UWZ) zostaną odrzucone jako ekonomicznie szkodliwe. Rozpowszechnią się metodyki odwołujące się do zdefiniowanego we wstępnej fazie zakresu biznesu, którego obsłużenie jest istotne dla klienta. Już dziś definiowanie na początku zakresu wdrożenia tworzy układ odniesienia, umożliwiający panowanie nad projektem i jego zakończenie. Dobrze realizowane metodyki wyeliminują zmiany celu i zakresu podczas realizacji projektów.

Większą rolę niż dziś będą miały zapewne dokumenty wynikowe (deliverables). Do właściwego zorganizowania współpracy stron realizujących projekt i osiągnięcia wymaganych postępów wyniki będą definiowane jasno, precyzyjnie i w minimalnej, koniecznej liczbie. Dzisiejsze metodyki często unikają takich definicji. Współpraca stron, zorientowana na efekty biznesowe, będzie wymagała w metodyce ujęcia krytycznych czynników sukcesu, zmian, których organizację przedsiębiorstwo wdrażające system będzie musiało u siebie przeprowadzić, aby zapewnić pomyślne zakończenie projektu. Dzisiejsze realizacje metodyk często ignorują istnienie tego zagadnienia.

Metodyki wdrażania zapewnią też przypisanie projektom niezbędnych zasobów ludzkich - użytkowników kluczowych i konsultantów oraz zasobów materialnych. Zdefiniowanie zasobów i konieczność zrealizowania celów będą implikowały zakres obowiązków członków zespołu. Można mieć nadzieję, że zanikną praktycznie metodyki nie wymagające jednoznacznego i czytelnego przypisania obowiązków członkom zespołów. Już dziś metodyczne przydzielenie i egzekwowanie zakresów obowiązków jest jedną z cech udanych wdrożeń.

Innym, ściśle powiązanym z biznesem elementem jest budżet. Dzisiejsze metodyki często ignorują tę technikę planowania finansowego. Zamiast tego wpisywane są do umów ceny stałe (za wdrożenie). Metodyki, które już w najbliższej przyszłości zdominują rynek, będą zakładały sterowanie nakładami przez budżet, wynikający z harmonogramu będącego uszczegółowieniem ścieżki wyników i przypisanych zasobów.

Kolejna ważna zmiana nastąpi w planowaniu czasu. Dziś praktycznie głównym narzędziem wspólnym dla różnych metodyk jest bardzo szczegółowy wykres Gantta. Ma on obrazować zarówno ścieżki wyników, stany do osiągnięcia, jak i czynności do wykonania. Jest tworzony jako podstawowy dokument kierowania projektem i często zastępuje wspomniane tu elementy. Można spodziewać się, że przewagę uzyskają metodyki przedstawiające łatwą drogę dojścia w czasie do zakładanych wyników. Już dziś do przedstawiania drogi dojścia używa się ścieżek wyników (diagramów kamieni milowych), gdzie widać wzajemne powiązania kolejnych stanów, celów cząstkowych, które należy osiągnąć w organizacji, opracowaniu aplikacji, przygotowaniu technicznym i przeszkoleniu. Szczegółowe narzędzia, takie jak wykres Gantta, tabele czynności będą nadal używane, ale na niższym poziomie zarządzania projektem i nie będą niewolniczo respektowane.

Można mieć również nadzieję, że poważne zmiany nastąpią w zakresie wykorzystania analizy ryzyka, jako techniki wczesnego wykrywania zagrożeń dla projektu i przeciwdziałania im. Rozpowszechnione metodyki rzadko stosują analizę ryzyka. Metodyki przyszłości będą wykorzystywały tę technikę szerzej. Nowoczesne metodyki, poprzez analizę ryzyka, pozwolą wcześniej wykrywać przyczyny na przykład niestabilności zespołów i zapobiegać im.

Innym niebezpiecznym czynnikiem, który może być w dużej mierze opanowany przez analizę ryzyka, są błędy aplikacji. Przewidzenie, że każda aplikacja ma błędy, pozwoli skutecznie ograniczać ich skutki poprzez np. wczesne uzyskanie supportu producenta, przygotowanie zespołu informatyków, zebranie doświadczeń innych firm wykorzystujących daną aplikację czy zastosowanie technik obejściowych.

Właściciel projektu

Koncentrowanie się na ostatecznym wyniku postawi wysokie wymagania nie tylko pracującemu zespołowi, dostawcom oprogramowania i innych elementów technicznych. Kluczowymi postaciami będą właściciele projektu, odpowiedzialni bezpośrednio przed najwyższymi organami firmy lub członkowie tych organów. Większy ich udział wyniknie z głębszego niż dzisiaj rozumienia wpływu wdrożonych systemów ERP na jakość i efektywność pracy przedsiębiorstwa. Występujące i akceptowane dzisiaj praktyki postępowania typu: "Róbcie tak, żeby było dobrze" oraz powierzenie projektu (dużego budżetu) np. informatykom powinny zaniknąć. Istnieją już dzisiaj przykłady wdrożeń, gdzie bezpośredni wpływ i patronat zarządu radykalnie usprawniają podejmowanie decyzji, komunikację, osiąganie założonych celów częściowych. Jednocześnie zstępujące projektowanie wdrażanego modelu biznesowego wymaga decyzji zarządu już w początkowych fazach, kiedy określane są kluczowe funkcje, w tym funkcje gospodarcze, pozostające w zakresie projektu i poza nim. Brak udziału właściciela projektu w tym projektowaniu powoduje poważne błędy, trudne do naprawienia w późniejszych fazach realizacji wdrożenia.

Wizja i lider projektu

Projekt przyszłości postawi wyższe wymagania jego kierownictwu. Dzisiejsze metodyki, częstokroć widzące w kierowniku projektu sprawnego administratora, odpowiedzialnego za zasoby i formalności, ustąpią miejsca metodykom wymagającym lidera - wizjonera, który na bazie dużej wiedzy i doświadczenia ukierunkuje wdrożenie i zainspiruje zespół do wypracowania i zrealizowania odpowiedniego modelu funkcji i procesów biznesowych. W takim zdefiniowaniu roli menedżera projektu widać chęć znalezienia remedium na rozbieżność występującą między obsługiwanym biznesem a najbardziej elastyczną nawet aplikacją. Wzrastające skomplikowanie projektów (multi-site, struktury holdingowe itp.) już dziś powoduje, że przy definiowaniu wykorzystania aplikacji do obsługi biznesu stosuje się podejście zstępujące, od ogółu do szczegółu. Oznacza to w praktyce, że poszczególni uczestnicy prac projektowych widzą wdrożenie na odpowiednich dla nich poziomach szczegółowości, skorelowanych z zakresem ich obowiązków. Dzisiejsze metodyki, nie nakładające takich obowiązków na lidera, najprawdopodobniej okażą się słabsze i zostaną wycofane, gdyż nie oddzielają szczegółów od problemów ogólnych. Powodują bowiem niestabilność projektów i przerzucanie się między szczegółami a fundamentalnymi dla biznesu zagadnieniami.

Praca zespołowa, użytkownicy i konsultanci

O zespołach wdrożeniowych mówią wszystkie metodyki. Praca zespołowa będzie podobnie jak dziś wykorzystywana na co dzień. Można się jednak spodziewać, że zmieni się rozumienie pracy zespołowej, co wpłynie znacząco na organizację zespołów. Niektóre dziś stosowane metodyki bardzo rozdrabniają zespoły, wyodrębniając wyspecjalizowane grupy zadaniowe, słabo komunikujące się ze sobą. W innych, już dziś stosowanych metodykach mamy do czynienia z małymi, sprawnymi zespołami, złożonymi z kompetentnych pracowników (użytkowników kluczowych). Praktyka wykazuje, że takie grupy, pozostające w ścisłym kontakcie z właścicielem projektu, ułatwiają osiąganie wyznaczonych wyników. Zwróci się szczególną uwagę na samodzielne rozwiązywanie zadań przez użytkowników kluczowych i szybkie osiąganie przez nich wymaganej kompetencji. Takiego też kierunku zmian metodyk można się spodziewać.

Integracja konsultantów w ramach zespołów wdrożeniowych powinna stać się zjawiskiem powszechnym. Częste dzisiaj przeciwstawienie konsultanta zespołowi, czasami wręcz prowokowane przez stosowaną metodykę (lub jej niezrozumienie), powinno zaniknąć. W praktykach dzisiejszych udanych lub bardzo zaawansowanych wdrożeń praca zespołowa użytkowników kluczowych wraz z konsultantami, pełniącymi rolę moderatorów, staje się zasadniczym czynnikiem powodzenia. Jednocześnie oznacza to, że zespół wdrożeniowy odpowiada za projekt, a jego pomyślne zakończenie jest sukcesem zespołu. Takie wzmocnienie motywacji i odpowiedzialności zespołu stanie się trwałym elementem metodyk. Będzie dotyczyło również tzw. ścieżki technicznej. Producenci oprogramowania usprawnią support i kontakt z klientem. Dzięki temu rozwiązywanie problemów technicznych przez informatyków należących do zespołów wdrożeniowych (przy użyciu supportu producenta) stanie się codzienne we wdrożeniach polskich, tak jak jest to już typowe we wdrożeniach międzynarodowych. Zaniknie powszechna dziś praktyka oczekiwania na dostarczenie gotowych rozwiązań problemów technicznych przez konsultantów.

Prosta, czytelna dokumentacja

Można mieć nadzieję, że epoka wiszących na ścianach gigantycznych wykresów Gantta minie bezpowrotnie wraz z pracowicie wypełnianymi tabelkami, tłumaczącymi jedynie nakłady finansowe, a nie osiągane wyniki. Zredukowana zostanie rola dokumentacji. Można się spodziewać, że powszechne stanie się przygotowywanie dokumentu zawierającego ogólny obraz funkcji przedsiębiorstwa, pracującego z wykorzystaniem aplikacji (blueprint). Jako narzędzie do projektowania procesów i ich dokumentowania będą stosowane tzw. modelery.

Praktyczne zastosowanie modelerów w dzisiejszych realiach jest ograniczone, ale specjalizacja branżowa konsultantów i wzrastające kompetencje użytkowników umożliwią szersze ich zastosowanie. Wbrew rozpowszechnianym przez niektórych handlowców mitom, modelery nie będą czarodziejskimi instrumentami rozwiązującymi problemy organizacyjne i wdrożeniowe. Nie będą odpowiednimi narzędziami dla słabo przygotowanych użytkowników i konsultantów o informatycznym, a nie biznesowym profilu. Ich użycie do tworzenia i testowania modeli procesów gospodarczych będzie wymagało wysoko wykwalifikowanych zespołów. Oczywiście pozostanie dokumentacja procesu wdrażania. Będzie ona łatwa i czytelna. Przykładami mogą być arkusz odpowiedzialności i ścieżki wyników. Każdy uczestnik projektu, członek kierownictwa, właściciel itp. na bazie takiej dokumentacji łatwo i szybko oceni stan projektu. Zmniejszy to obciążenie czasem administracyjnym, stanowiące po prostu koszt nie zwiększający wartości dodanej.

Paweł Hajdan jest konsultantem Ernst & Young.