Powstrzymać koncert życzeń

Z Maciejem Grabowskim, dyrektorem ds. informatyki w Cormay Poland, rozmawia Iwona D. Bartczak.

Z Maciejem Grabowskim, dyrektorem ds. informatyki w Cormay Poland, rozmawia Iwona D. Bartczak.

Ma Pan doświadczenia z kilku projektów wdrażania zintegrowanego systemu MRP II. Teraz robi Pan porządki po nieudanym projekcie i przygotowuje nową strategię informatyzacji. Co jest najważniejszym czynnikiem krytycznym projektu informatycznego?

Najważniejsze w projekcie jest zarządzanie ludźmi: ich dobór, system motywacyjny, przyporządkowanie stanowisk, odpowiedzialności i zadań zarówno po stronie dostawcy oprogramowania i usług, jak i po stronie przedsiębiorstwa, przyszłego użytkownika. Jest kilka podstawowych zasad, których trzeba bezwzględnie przestrzegać. Po pierwsze, trzeba czytać życiorysy zawodowe konsultantów. Pełnowartościowymi - i pełnopłatnymi - konsultantami mogą być tylko te osoby, które uczestniczyły w udanym projekcie. Po drugie, trzeba szefa projektu usytuować tak wysoko w hierarchii przedsiębiorstwa, aby bez zwłoki uzyskiwał od kierownictwa potrzebne decyzje, a załoga wiedziała, że to poważne przedsięwzięcie. Po trzecie, szefem projektu informatycznego nie powinien być inżynier informatyk, choć powinien być dobrze obeznany z tą dziedziną. Specjalista od logistyki czy finansów będzie bardziej wrażliwy na sprawy biznesowe i bardziej komunikatywny dla innych menedżerów. Po czwarte, trzeba jasno podzielić odpowiedzialność za poszczególne zadania tak, aby nie było żadnego bezpańskiego pogranicza. Skuteczna odpowiedzialność to odpowiedzialność jednoosobowa. Po piąte wreszcie, nie należy kierować się wyłącznie wykształceniem dobierając ludzi do projektu. Wykształcenie nie zawsze idzie w parze z umiejętnością radzenia sobie, otwartością, umiejętnością i chęcią uczenia się. A już jak ognia należy unikać tych, którzy mniemają, że tylko oni mają rację. Bo zwykle jej nie mają, a przekonać się nie dadzą.

Domyślam się, że założył Pan, iż poprawnie wybrano system informatyczny i że w ogóle da się go wdrożyć w danym przedsiębiorstwie. Ale taki aktywny, ambitny, twórczy i umotywowany zespół wdrożeniowy może nie zadowolić się standardem jedynie powierzchownie odzwierciedlającym procesy w przedsiębiorstwie. Czy pokusa, aby kupiony system MRP II maksymalnie ulepszyć, by pasował jak ulał do firmy, może być groźna?

Zawsze w początkowym okresie projektu, czyli w fazie planowania, odbywa się tzw. koncert życzeń użytkowników. Nie wiedzą, jak wydobyć poszczególne funkcje czy informacje z systemu, postulują więc, aby go modyfikować. Po trzech miesiącach większość życzeń jest bezzasadna, bowiem podczas wdrożenia okazuje się, że można je naturalnie zrealizować za pomocą odpowiedniej parametryzacji systemu. Nie jestem kategorycznym przeciwnikiem modyfikacji, ale uważam, że trzeba je ograniczyć do minimum, ponieważ wywołują łańcuch nie kontrolowanych zdarzeń, nad którymi nikt nie może zapanować. Lepiej więcej czasu poświęcić na parametryzację niż mieszać w kodach. Akceptuję zmiany, których konsekwencje są do przewidzenia, np. w bazach klientów czy w bazach towarów, ale niechętnie widzę zmiany w procesach, np. dodawanie lub pomijanie elementów w łańcuchu dostaw. Przestrzegam szczególnie przed zbyt pochopnym wprowadzaniem skomplikowanych nowatorskich rozwiązań. Ich poprawności naprawdę nie można sprawdzić na danych testowych. Jak już ten samolot się wzniesie, to potem można dopiero myśleć o bardziej wyrafinowanych usprawnieniach.

W mojej praktyce sprawdza się zasada trzech szuflad. Gdy życzenia modyfikacji pojawiają się po raz pierwszy, trafiają do najniższej szuflady, do której bardzo rzadko zaglądam. Gdy ktoś sobie o nich przypomni, to po przejrzeniu przekładam je do wyższej szuflady. Jeśli po miesiącu jeszcze ktoś się o nie upomina, to trafiają do trzeciej najwyższej szuflady i zaczynam się zastanawiać, jak ewentualnie zrealizować życzenie. Potem mogą już tylko znaleźć się na biurku i wówczas stają się integralną częścią projektu.

Właściwie każdy projekt ma swoją specyfikę, jest niepowtarzalny. Co zatem sprawia, że doświadczenie z poprzednich projektów jest takie ważne dla powodzenia każdego następnego, przy którym się pracuje?

Właśnie świadomość tej niepowtarzalności. Mimo że z czasem nabywamy umiejętności szacowania zasobów, które są niezbędne do wdrożenia czy szacowania czasochłonności prac, to nie sposób zbudować harmonogramu, który zostanie zrealizowany ze stuprocentową dokładnością. Trzeba wiedzieć, że naturalne jest korygowanie harmonogramu. Jeśli ktoś uważa harmonogram za "świętą krowę", to naraża się na pośpiech, który nieuchronnie zaowocuje błędami. Natomiast granice odchyleń od harmonogramu też powinny być zaplanowane i w trafności szacowania tych odchyleń przejawia się mistrzostwo szefów projektów.

--------------------------------------------------------------------------------

Maciej Grabowski był dyrektorem ds. planowania strategicznego i kierownikiem projektu wdrożenia R/3 w Optimus SA, a następnie zajmował takie samo stanowisko oraz kierował działem informatyki w Elbrewery Ltd. w Elblągu.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200