Eksploracja i adaptacja zamiast planu i kontroli

Metodyki spod znaku agile wyszły poza programowanie systemów IT i weszły w obszar zarządzania projektami. W przypadku wdrożeń systemów ERP ich zastosowanie może mieć głęboki sens.

Zderzenie z rzeczywistością

Wszystkie te zasady wydają się zgodne ze zdrowym rozsądkiem, ale w rzeczywistości pojawia się podstawowy problem: kontrakt. Wszystkie wdrożenia systemów ERP angażują firmę zewnętrzną - producenta systemu lub jego firmę partnerską specjalizującą się we wdrożeniach wybranego systemu. Przed rozpoczęciem projektu z ową firmą podpisywany jest kontrakt wdrożeniowy, precyzujący koszt, zakres i harmonogram wdrożenia. Jeszcze kilka lat temu zdarzały się kontrakty, których koszt opierał się na kalkulacji godzin wypracowanych w rzeczywistości przez konsultantów, czyli "zrobimy, co w naszej mocy, żeby zrealizować założony zakres i zobaczymy, ile czasu i pracy nam to zajmie". Podejście to jest stosunkowo zgodne z filozofią agile, ale może prowadzić do niekontrolowanego wzrostu kosztów, jeśli partner wdrożeniowy działa wolno i nieporadnie.

Teraz znakomita większość umów to kontrakty fixed price, czyli takie, w których cena wdrożenia jest ściśle określona w zależności od zakresu. W powszechnym odczuciu kontrakty te są bezpieczniejsze dla klienta i chronią go przed niekontrolowanym wzrostem kosztów. W tego rodzaju kontraktach dostawca broni się jednak rękami i nogami przed jakimikolwiek zmianami i rozszerzeniami zdefiniowanego wcześniej zakresu, gdyż pożerają one jego zaplanowany zysk.

Wydaje się, że jakimś rozwiązaniem jest szerokie upowszechnienie projektów pilotażowych, które pozwalają zorientować się przy niewielkiej skali i ryzyku finansowym, jak szybko klient i firma wdrożeniowa wypracowują rozwiązania i wdrażają je w życie, a tym samym urealnić plany będące podstawą kontraktu na wielką skalę. Ryzyko: klient angażuje się we współpracę z firmą wdrożeniową, która wykorzystując rosnące przywiązanie skłania go do podpisania niekorzystnego finansowo kontraktu. Szansa: klient poznaje słabe i silne strony firmy wdrożeniowej, może wykorzystać te słabe w negocjacjach na swoją korzyść, zaś silne dają mu poczucie, że wie, za co płaci.

Inne rozwiązanie to podpisanie rozpisanej na iteracje umowy wielowariantowej z kategorii "jeśli wdrożymy X i Y, zapłacimy 100 - jeśli X, Y i Z, zapłacimy 150, przy czym przewidujemy rozliczenia po każdej iteracji uwzględniające zmianę wariantu wynikającą z rozszerzenia zakresu i tym samym zmianę ceny całkowitej". Oczywiście, pozostają pewne koszty stałe iteracji 0, wymagającej stworzenia architektury i interfejsów oraz poniesienia kosztów sprzętu będącego w stanie wytrzymać obciążenie wynikające ze wszystkich możliwych iteracji.

Cały czas problemem pozostaje również elastyczność zakresu w ramach jednej iteracji. Tu może być konieczny powrót do jakiejś formy rozliczeń za przepracowany czas, co wymaga z kolei jakiegoś sensownego poziomu zaufania między klientem a firmą wdrożeniową. Łatwo jest mówić o ograniczeniu do minimum dokumentacji w ramach jednej firmy i zastąpieniu jej dyskusją prowadzącą do lepszego zrozumienia i wypracowania lepszych rozwiązań. Cudownie.

Wszyscy jednak wiedzą, jakie ilości dokumentacji produkują kontrakty na przykład outsourcingowe, w których każdemu życzeniu klienta i każdej reakcji dostawcy towarzyszy stosowny protokół. Podobnie dzieje się w kontraktach wdrożeniowych. Wydaje się jednak, że jeśli po obu stronach działają zdecydowani liderzy, którzy wiedzą, jaki cel chcą wspólnie osiągnąć i wierzą, że jego osiągnięcie leży w interesie obu stron, porozumienie jest możliwe.

50 sekund w windzie

Jedną z praktyk adaptacyjnego zarządzania projektami jest tzw. test windowy, czyli próba objaśnienia projektu przełożonemu w ciągu krótkiej, wspólnej podróży windą. Praktykę tę wykorzystuje się na etapie tworzenia wizji projektu i jest ona ucieleśnieniem jednej z podstawowych wartości zarządzania adaptacyjnego - maksymalnej lapidarności przekazu. Test windowy, wymyślony przez niejakiego Geoffreya Moore'a, ma ustalony format. Na konkretnym przykładzie mógłby on wyglądać tak: "Chodzi o wdrożenie systemu informatycznego przeznaczonego dla działów sprzedaży i logistyki naszej firmy, która musi uwolnić zamrożone zapasy gotówki i zwiększyć konkurencyjność, usprawniając obsługę klientów, co pozwoli zwiększyć przychody. (Wybrany system informatyczny) jest systemem klasy ERP, który pozwoli zmniejszyć czas realizacji zamówienia, obniżyć liczbę reklamacji i zmniejszyć znacząco stany magazynowe. W odróżnieniu od (najlepszy system alternatywny), (wybrany system) jest tańszy, znany nam technologicznie i wdrażany przez firmę z większym doświadczeniem". W teście windowym najbardziej istotny jest klient, czyli użytkownik końcowy, jego potrzeby i kluczowe możliwości systemu odpowiadające owym potrzebom. Może zmiana perspektywy pod tym kątem pozwoliłaby uchronić się przed wdrożeniami "modułu finansowo-księgowego, gospodarki magazynowej i środków trwałych", które nie wiadomo, na jakie potrzeby mają odpowiadać i osiągnięcie jakich celów umożliwić.

Artykuł napisano na podstawie książki Jima Highsmitha "APM: Agile Project Management", wydawnictwo Mikom, Warszawa, grudzień 2005