Czasami w pracy jesteśmy świadkami rozmów, albo nawet sami je inicjujemy, jak to osoby w innym dziale źle wykonują swoje zadania i jak to wpływa na naszą pracę. Mamy z tego powodu więcej obowiązków, musimy coś poprawiać, tłumaczyć klientom opóźnienia, itp. Wszystko byłoby łatwiejsze gdyby „dział X” lub „zespół Y” wykonywał swoje obowiązki lepiej. Mielibyśmy większą sprzedaż, gdyby marketing lepiej promował nasze produkty. Marketing twierdzi, że trudno promować drogi produkt i trzeba obniżyć koszty produkcji. Produkcja narzeka, że dział zakupów nie potrafi znaleźć tańszych dostawców. Wszyscy narzekają na finanse za cięcie kosztów. Oczywiście treść rozmowy zależy od zespołu, w którym pracujemy, i dotyczy zawsze „innych” działów, z którymi najczęściej mamy do czynienia.

W nieco łagodniejszej formie takie rozmowy dotyczą sytuacji, gdy wprawdzie zespół X lub Y nam nie przeszkadza w pracy, ale naprawdę nie wiemy, „co oni tam robią całymi dniami, pewnie surfują po internecie?”. Nie bardzo rozumiemy zakres zadań tych osób i nie jest dla nas jasny ich wkład w sukces całej organizacji (w którym oczywiście nasz dział ma zawsze największy i niezaprzeczalny udział).

W projekcie – np. podczas wdrożenia systemu ERP – spotyka się grupa osób z różnych działów, z dwóch lub więcej organizacji (klient, firmy konsultingowe), które wcześniej nigdy ze sobą nie współpracowały. Oczekujemy jednak, że osoby te będą sprawnie i skutecznie pracować przez kilka lub kilkanaście miesięcy, w nowej dla siebie sytuacji. Wspólnie zdefiniują i przygotują do działania w przedsiębiorstwie złożony system. To, że czas i budżet jest napięty i nie ma buforu na błędy, jest też stałym elementem projektów.

W takiej sytuacji szybko pojawiają się wspomniane na początku wątpliwości i pytania o cel i sens działania innych osób. Podział może przebiegać na przykład na linii: zespoły projektowe <-> kierownik projektu.

Łatwa robota?

Zespół X: „Kto ułożył taki plan? Nie możemy rozpocząć naszego zadania, dopóki Y nie skończy swoich prac, a terminy nas już gonią”.

Kierownik projektu: „Dlaczego zespół Y nie informuje mnie o przyczynach opóźnień? Nigdy nie dostaję raportów statusu na czas, a przecież wysłałem wczoraj przypomnienie mailem”.

Zespół Y: „Dlaczego w projekcie jest tyle biurokracji? Gdybyśmy nie musieli pisać raportów statusu, to mielibyśmy czas na wykonywanie zadań”.

W artykule postaram się przybliżyć rolę project managera, aby podobne dialogi pojawiały się rzadziej w projektach wdrożeń systemów ERP. A trzeba podkreślić, że wdrożenie systemu ERP jest specyficznym projektem, w którym powołuje się dwóch równorzędnych kierowników projektów.

Kierowanie projektami zgodnie z definicją organizacji Project Management Institute (PMI) to: stosowanie wiedzy, umiejętności i narzędzi w ramach działań projektowych, aby osiągnąć cele projektu.

Po chwili namysłu pewnie wszyscy się z tą definicją zgadzają. Jest ona jednak na tyle ogólna, że większość po jej przeczytaniu nadal nie wie, na czym właściwie polega praca kierownika projektu. W każdym razie jako kierownik Biura Projektów BCC (aktualnie All for One Poland) często słyszę pytania klientów lub konsultantów, dlaczego nawet do niezbyt dużego projektu powinniśmy przypisać kierownika, i to zarówno po stronie firmy konsultingowej, jak i po stronie klienta.

Teoretycznie można by z przedstawionej wcześniej definicji wyprowadzić taki wniosek: „To bardzo prosta praca. Project manager opracowuje plan prac na początku, a później obserwuje, jak ten plan jest realizowany przez pozostałych uczestników projektu”.

Gdyby tak było w istocie, to powinniśmy zapytać, dlaczego raporty o powodzeniu projektów informatycznych na świecie każdego roku podają fatalne statystyki na temat przekraczania czasu lub budżetu?

Z punktu widzenia project managera dwie cechy projektów, które określają w dużym stopniu charakter pracy, to unikalny rezultat każdego projektu i konieczność integracji produktów prac. W następnych częściach artykułu przyjrzymy się tym elementom – najpierw ogólnie, a później na konkretnych przykładach, żeby zilustrować, dlaczego kierownik projektu jest niezbędny dla sukcesu przedsięwzięcia.

Jedyna stała rzecz w projekcie to… zmiany

Oczekiwany produkt każdego wdrożenia jest unikalny. Jest to główna różnica pomiędzy projektem (który wprowadza jakąś istotną i jednorazową zmianę w organizacji), a bieżącą działalnością operacyjną (która jest powtarzalna i co najwyżej staramy się ją stopniowo optymalizować). Oczywiście pewne elementy wdrożenia systemu ERP są powtarzalne, lecz zawsze inna jest kombinacja: zakresu funkcjonalnego, specyfiki branży, wymagań klienta, wiedzy i doświadczenia uczestników projektu. To powoduje, że czas realizacji projektu i konkretne wyzwania będą niepowtarzalne, inne niż w poprzednich wdrożeniach.

Unikalność rezultatu oznacza, że działamy w warunkach niepewności: jaka kombinacja czasu pracy, działań, umiejętności osób, dodatkowych narzędzi jest potrzebna, żeby osiągnąć rezultaty projektu najszybciej i najtaniej?

W wielomiesięcznym przedsięwzięciu nieuniknione są zmiany planu. Staramy się je zminimalizować (np. w miarę możliwości wstrzymujemy inne równoległe projekty biznesowe i IT), lecz nie możemy całkowicie „zamrozić” naszej organizacji i jej otoczenia.

Zmiany wewnątrz organizacji to na przykład: wdrożenie nowego rodzaju produktu (zmiana w definicji procesu produkcji w systemie ERP), nowa polityka rabatowa dla klientów (zmiany parametrów w ustalaniu cen), zmiany składu zespołu projektowego w związku z innym miejscem pracy lub awansem (konieczność wprowadzenia nowej osoby zespołu).

Zmiany w otoczeniu organizacji – na które również musimy reagować w projekcie – to na przykład: przepisy wprowadzające nowe wymogi raportowania (opracowanie specyfikacji raportu, zaplanowanie czasu na jego realizację i testy), pojawienie się nowej konkurencji na rynku (zmiana modelu biznesowego – powrót do założeń koncepcyjnych systemu), zmiany technologii (zmiana procesu produkcji – nowe receptury zdefiniowane w systemie).

Niepewność i ciągłe zmiany powodują, że precyzyjne planowanie projektów jest dużym wyzwaniem, a ich doprowadzenie do końca zgodnie z tymi planami jest jeszcze trudniejsze. Rolą kierownika projektu jest właśnie ciągłe reagowanie na zmiany i wpływanie na projekt, aby jego faktyczny przebieg pozostawał najbardziej zbliżony do planowanego terminu i budżetu prac.

Rezultat projektu to suma pracy wszystkich zespołów

Intuicyjnie jest to dość oczywiste: każdy duży projekt (np. budowa fabryki, wprowadzenie nowego produktu, wdrożenie systemu ERP) musimy podzielić na mniejsze części, aby śledzić postęp prac, przypisać odpowiedzialność za ich wykonanie. Poszczególne zadania i podprodukty przyporządkowujemy do różnych zespołów. Pod koniec fazy realizacji zbieramy wszystkie elementy rozwiązania i dopasowujemy je do siebie, aby uzyskać działający finalny rezultat projektu.

Problemy pojawiają się właśnie podczas scalania podproduktów w zintegrowany system. Te problemy maja zazwyczaj dwie główne przyczyny:

  • rozwiązania nie działają „na styku” prac dostarczonych przez różne zespoły,
  • odkrywamy zagadnienia „niczyje”, którymi nie zajmował się wcześniej żaden zespół, a które są niezbędne do ukończenia projektu.

Członkowie zespołów projektowych są też oczywiście zainteresowani sukcesem całego przedsięwzięcia, ale ich priorytet to wykazanie, że doprowadzili swoje cząstkowe zadania do końca (dostarczyli prawidłowe części składowe rozwiązania), a już niekoniecznie ich integracja w całość. Tu na scenę wchodzi kierownik projektu, który dba o osiągnięcie finalnego celu, wypracowanie zintegrowanego rozwiązania i jego poprawianie, aż wszystkie elementy rozwiązania będą działać spójnie, nawet jeśli lokalnie, w ramach pojedynczych zespołów wszystko było OK już wcześniej.

Jednym ze sposobów osiągnięcia tego celu jest wprowadzanie przez kierownika projektu jednolitych zasad pracy, dokumentacji wymagań, raportowania itp. Ułatwia to śledzenie postępów pracy, komunikację pomiędzy zespołami i integrację całości rozwiązania.Dobra metodyka projektowa dostarcza szablony i przykłady takich materiałów (np. dokumenty koncepcyjne, plany projektu, scenariusze testów). Rolą project managera jest jednak zawsze wybór odpowiedniego zestawu działań, reguł i dokumentów, aby zachować równowagę pomiędzy bezpieczeństwem i kontrolą nad projektem, ale nie przesadzić z biurokracją, która pochłonie czas uczestników projektu.

Poza gotowymi przykładami i „przepisami” postępowania z metodyki, kierownik projektu wykorzystuje swoją wiedzę i doświadczenie. Musi stale przewidywać, jaka organizacja prac w projekcie „będzie działać” na danym etapie – inaczej w długim okresie prac koncepcyjnych, a inaczej w ostatnich dniach przed startem produkcyjnym, kiedy planowanie musi odbywać się z dokładnością do godzin lub minut.

Zadaniem kierownika jest też mediacja pomiędzy zespołami, które nie mogą same dojść do porozumienia. Upewnia się, czy wszyscy jednakowo rozumieją plany, specyfikacje zadań i podział odpowiedzialności, aby unikać – wspomnianych wcześniej – tematów „niczyich” i problemów integracyjnych.

Historia pewnego projektu

Po tych ogólnych rozważaniach spróbujmy odnieść się do konkretnych sytuacji ilustrujących rolę KP jako kluczowego uczestnika wdrożenia. Prześledzimy to na przykładzie relacji różnych uczestników wdrożenia systemu ERP. Choć przedstawiona historia nie jest prawdziwa, stanowi zbiór przykładów, które regularnie obserwujemy w praktyce projektów ERP.

Dzień 3 projektu. Kierownik projektu po stronie klienta

Dzisiaj odbyło się pierwsze spotkanie przeglądu statusu projektu – takie spotkania mamy odbywać co wtorek. Ponieważ harmonogram jest napięty, to warto sprawdzać status prac regularnie, żeby uniknąć niespodzianek. Jeśli któryś zespół „utknie” i nie będzie mógł rozwiązać swojego problemu, to w najgorszym razie zmarnujemy tylko tydzień – nie dłużej. Pod koniec spotkania ustaliliśmy kilka ważnych działań, które trzeba wykonać, żeby prace posuwały się do przodu bez opóźnień.

Uczestnicy spotkania mieli kilka dobrych pomysłów, np. „Trzeba zebrać reguły ustalania cen ze wszystkich regionów i ustalić jednolite zasady, które da się opisać jako algorytm w systemie ERP”, „Musimy wskazać osobę, która będzie odpowiedzialna za opracowanie danych nowego produktu w systemie”.

Wszyscy chętnie dorzucali dobre rady od siebie, jednak dopiero kierownik projektu z firmy konsultingowej na koniec spotkania zrobił protokół i upewnił się, czy do każdego z tych zadań przypisaliśmy osobę odpowiedzialną za jego wykonanie i termin. Bez tego rozeszlibyśmy się po spotkaniu i skończyłoby się jak zwykle – na dobrych pomysłach i ambitnych założeniach, ale bez efektów.

Dzień 15 projektu. Kierownik zespołu sprzedaży

Zespół produkcji rzucił pomysł, żebyśmy skorzystali ze śledzenia partii wyrobów gotowych w systemie ERP (jedna ze standardowych funkcji, której nie miał nasz poprzedni system). Świetne rozwiązanie. Dzięki temu będzie wreszcie możliwe szybkie ustalenie i wycofanie tylko jednej partii z obrotu w punktach detalicznych, jeśli odkryjemy wadę jakościową!

Spodobał nam się ten pomysł, ale kierownik projektu z firmy wdrożeniowej zadał jeszcze kilka „trudnych pytań”, np. jak zamierzamy kodować numer partii? Właściwie wcześniej się nad tym nie zastanawialiśmy, ale po krótkiej dyskusji doszliśmy do wniosku, że powinna to być data produkcji, ponieważ nigdy nie zmieniamy partii w trakcie dnia pracy (więc data produkcji jest unikalnym oznaczeniem). KP drążył dalej: czy śledzenie partii wpływa na pracę innych zespołów, które przejmują produkt z produkcji – gospodarka materiałowa, sprzedaż i dystrybucja, kontroling itd.?

Kontroling potwierdził, że analizuje przychody ze sprzedaży tylko do poziomu produktu/klienta, więc dla nich nie ma tematu. Sprzedaży też spodobał się nasz pomysł, ale zaproponowali, żeby zamiast daty produkcji oznaczać w numerze partii datę przydatności do spożycia. Ta data też jest unikalna (zmienia się z każdym dniem produkcji partii), a przy okazji spełnia dodatkowo rolę informacyjną dla konsumentów dużo lepiej niż „data produkcji”. Zgodziliśmy się z tym.

Z zespołem gospodarki materiałowej było największe zamieszanie, bo okazało się, że magazynier musi przecież widzieć oznaczenie partii, aby pobrać z zapasów tę samą partię produktów, która jest przypisana do dokumentu dostawy. To by była większa zmiana organizacyjna, bo wymaga ustawiania towarów w magazynie zgodnie z partiami, w kolejności FIFO (wcześniej było to całkiem dowolne), ale wszyscy zgodzili się, że dzięki temu skończy się problem przeterminowanych zapasów. Kierownik działu zapasów ustali w przyszłym tygodniu, jak bardzo wpłynie to na czasochłonność pracy w magazynie.

KP poradził, żeby dział IT sprawdził ofertę skanerów kodów kreskowych i RFID, bo takie rozwiązanie na pewno przyspieszy pracę, chociaż pewnie będzie nieco droższe. Do końca miesiąca przedstawimy Komitetowi Sterującemu wniosek o zmiany w projekcie związane z wprowadzeniem kodowania partii.

Dobrze, że KP zadał te pytania, bo moglibyśmy parę istotnych kwestii przeoczyć i odkryć je dopiero po starcie produkcyjnym systemu, w dużo bardziej nerwowej atmosferze…

Dzień 32 projektu. Kierownik projektu z BCC

Konsultant zespołu sprzedaży i dystrybucji skarży się od dwóch tygodni, że lider zespołu ze strony klienta nie chce potwierdzić opisu formularza wydruku faktury. Nie możemy przez to zakończyć fazy koncepcji w terminie. Co takiego skomplikowanego może być na fakturze, żeby to wymagało tyle czasu?

Rozmawiałem dzisiaj z liderem zespołu, ale usłyszałem tylko narzekania, że trudno dogadać się z naszym konsultantem i dlatego klient nie wie, jak odzwierciedlić warunki rabatowe w systemie. Poszedłem więc do kierownika projektu po stronie klienta i dowiedziałem się, że problem leży w nowych wymogach raportowania marż, które są dopiero określane przez centralę korporacji, dlatego dział sprzedaży nie wie, jakie warunki będą stosowane w przyszłym roku. I obawiają się potwierdzić cokolwiek w tej chwili…

Mając tę wiedzę, oceniliśmy z konsultantem i KP po stronie klienta, jaki jest najpóźniejszy termin na dostarczenie informacji (aby nie wpłynęło to na konfigurację i testy systemu). Następnie lider zespołu sprzedaży poinformował centralę o tym terminie z zastrzeżeniem, że opóźnienie spowoduje większe koszty dla projektu (które poniesie centrala). Teraz wszyscy czekamy spokojnie na dalszy rozwój sytuacji, bez stresu i wzajemnego wytykania sobie niekompetencji.

Dzień 40 projektu. Kierownik zespołu sprzedaży

Pod koniec fazy koncepcji kierownik projektu rozesłał do wszystkich zespołów dokumenty opracowane przez inne zespoły – do weryfikacji i sprawdzenia, czy rozwiązania są spójne. Pierwsza sprawa, która od razu rzuciła mi się w oczy, to że zespół finansów oznaczył pole „NIP” w danych klienta jako obowiązkowe i unikalne. To przecież bez sensu!

Możemy dostarczać nasze produkty do klientów, którzy są oddziałami jednej spółki i mają ten sam NIP. Musimy mieć tych klientów w systemie.

Rozmawiałem z głównym księgowym, ale ten nie chciał mnie słuchać – upierał się, że dla niego ważne jest, aby klient, którego fakturuje, miał zawsze numer NIP, a po drugie nie może dopuścić do występowania duplikatów klientów w systemie, bo to utrudni kontrolę limitów kredytowych.

Zgłosiliśmy temat do kierowników projektu. Podczas następnego wtorkowego spotkania integracyjnego zebraliśmy się w grupie: księgowy, konsultanci FI i SD oraz kierownicy projektu i ja. Po kilku minutach wszystko się wyjaśniło. Na potrzeby logistyki zdefiniujemy grupę klientów „adres dostawy”, bez pola NIP – tylko jako opis lokalizacji.

Natomiast księgowość będzie interesować się tylko grupą klientów-spółek, których nazwaliśmy „odbiorcy faktur” – z obowiązkowym i unikalnym NIP. W zleceniu sprzedaży będziemy wskazywać zarówno odbiorcę faktury, jak i miejsce dostawy. Całe szczęście, że zrobiliśmy przegląd koncepcji i mamy regularne spotkania integracyjne. W przeciwnym razie banalne szczegóły mogłyby urosnąć do dużych problemów.

Dzień 65 projektu. Programista z BCC

Mamy w zakresie projektu 10 rozszerzeń funkcjonalnych do oprogramowania, mniej więcej 5 dni na opracowanie każdego z nich, czyli dwa miesiące kalendarzowe pracy. W ostatnich dniach pojawiło się 8 nowych pomysłów klienta (zmiany/rozszerzenia zakresu). Wpisałem je na listę na końcu, ponieważ nie miałem informacji o tym, jakie są priorytety. Oczywiście każdy, kto do mnie przychodzi, mówi, że jego temat jest najpilniejszy i ma być „na wczoraj”, ale listą z 18 punktami o najwyższym priorytecie nie da się zarządzać.

Na szczęście spotkałem się dzisiaj z kierownikiem projektu, który przekazał mi informacje o pilności prac, zgodnie z ustaleniami Komitetu Sterującego. Okazuje się, że tylko dwa z nowych rozszerzeń zakresu muszą być gotowe na go-live. Co do pozostałych 6 wystarczy, jeśli będą gotowe na pierwsze zamknięcie miesiąca w nowym systemie. Muszę więc trochę przyspieszyć, ale damy radę, teraz kiedy mam jasno zdefiniowane priorytety.

Dzień 81 projektu. Kierownik projektu po stronie klienta

Główny księgowy, który jest w projekcie liderem zespołu finansów, narzeka, że nie może się dogadać z konsultantem w sprawie podejścia do migracji środków trwałych. Myślałem zawsze, że to najbardziej banalna i „nudna” część przygotowania systemu, a tu zaskoczenie!

Udało mi się zorganizować spotkanie z głównym księgowym i konsultantem, żeby wyjaśnić, o co chodzi. Księgowy zaczął od tego, że nie ma czasu wypełniać „jakichś dziwnych plików”, bo on jest tutaj od koncepcji księgowania, a nie przepisywania danych. Uspokoiłem go, że ekstrakt danych z naszego starego systemu F-K zrobi dla niego informatyk, a od niego potrzebujemy tylko decyzji, jak „zmapować” stare pola danych do nowego systemu.

Po tym wyjaśnieniu poprawił mu się humor. Zaplanowaliśmy następne spotkanie, z udziałem księgowego, konsultanta i informatyka znającego system F-K. Chyba po 3 tygodniach statusu „przygotowanie pliku w toku” teraz faktycznie jesteśmy blisko rozwiązania.

Nie sądziłem, że przy systemie ERP musimy przewidzieć tyle działań i zależności pomiędzy nimi. Byłem też zaskoczony kolejnością niektórych działań, która nie była dla mnie oczywista

Dzień 180 projektu. Kierownik zespołu gospodarki materiałowej u klienta

Zaczęliśmy sesje planowania startu produkcyjnego nowego systemu. Spotkanie prowadził kierownik projektu ze strony firmy konsultingowej. Przedstawił nam typowy plan startu jako punkt wyjścia, a później dodawaliśmy do listy punkty specyficzne dla naszej firmy.

Nie sądziłem, że przy systemie ERP musimy przewidzieć tyle działań i zależności pomiędzy nimi (nasz plan startu ma już ponad 100 punktów!), ale to wszystko wygląda całkiem sensownie. Byłem też trochę zaskoczony kolejnością niektórych działań, która nie była dla mnie oczywista.

Na przykład okazało się, że salda kont księgi głównej oraz dane środków trwałych możemy ładować kilka dni po starcie – nie zależy od nich bieżąca praca systemu na samym początku. Pilniejsze są natomiast pozycje pojedyncze należności i zobowiązań. To informacje sterujące naszymi płatnościami dla dostawców lub wymaganymi wpływami od odbiorców.

Oczywiście w centrum całego planu znajduje się mój zespół (tak, zawsze wiedziałem, że jest najważniejszy…), bo bez prawidłowych danych o stanie zapasów w systemie właściwie nie można wykonać żadnego procesu logistycznego.

Musimy dostarczyć dokładne stany zapasów ze starego systemu na koniec dnia 31 grudnia.

W pierwszym dniu nowego roku konsultanci zaimportują te dane do nowego systemu. Mamy jeden dzień na ich dokładną weryfikację – na szczęście 1 stycznia i tak nic nie produkujemy ani nie sprzedajemy. Konsultant zespołu MM – zaproszony przez KP na spotkanie – przedstawił raporty, za pomocą których będziemy weryfikować i uzgadniać stan zapasów w nowym systemie.

Wyjaśnił też kilka typowych „pułapek”, na które musimy uważać przy tej operacji. Na przykład dla niektórych materiałów zmieniliśmy jednostkę miary z „tona” na „kilogram” przy migracji do ERP – tam musimy więc jednocześnie przeliczyć ilości razy 1000, żeby nowe dane miały sens.

To wszystko wydaje się zupełnie oczywiste teraz, kiedy o tym rozmawiamy i wpisujemy do planu projektu, ale bez tego planu łatwo byłoby kilka spraw przeoczyć przy zamieszaniu (i niewyspaniu), jakie będzie nam towarzyszyć na przełomie roku.

Dzień 240. Impreza na zakończenie projektu. Kierownik zespołu finansów u klienta

Mieliśmy kilka trudnych momentów w projekcie ERP i czasem już mnie irytowało, że na przykład co tydzień jestem wyrywany od pracy na jakieś „spotkania statusowe” lub sesje planowania startu produkcyjnego. Ale teraz widzę, jak było to potrzebne. Na przykład, kiedy wyjaśniliśmy sobie z zespołem sprzedaży nieporozumienie z numerami NIP klientów.

No i teraz zamykamy miesiąc o cztery dni wcześniej, a raporty konsolidacyjne dla centrali system generuje automatycznie. Mogę zająć się ciekawszymi zajęciami niż przesiadywanie po nocach nad Excelem na początku każdego miesiąca.

Słyszałem, że korporacja szuka kierownika projektu do wdrożenia systemu workflow dla obiegu faktur zakupowych we wszystkich naszych oddziałach w Europie. Wcześniej nigdy bym o tym nie pomyślał, ale teraz, kiedy już widziałem w praktyce, na czym polega kierowanie dużym projektem – może byłaby to właściwa rola dla mnie?