Dlaczego projekty SAP tracą kontrolę? 7 błędów z perspektywy Project Managera

Każdy nowy projekt informatyczny zwykle zaczyna się pozytywnie – na początku są ambitne cele, harmonogram, budżet, zespół ekspertów i przekonanie, że skoro metodyka została sprawdzona w dziesiątkach innych projektów, tym razem wszystko również pójdzie zgodnie z planem.

A potem pojawiają się pierwsze trudności i komplikacje.

Jedno wymaganie okazuje się bardziej złożone niż zakładano. Kluczowy ekspert jest niedostępny. Integracja z innym systemem nie działa zgodnie z oczekiwaniami. Użytkownicy zgłaszają kolejne wymagania. Testy zaczynają się przesuwać, a decyzje biznesowe pozostają otwarte.

W pewnym momencie Project Manager przestaje zarządzać projektem według planu, a zaczyna przede wszystkim reagować na problemy. Na podstawie doświadczeń z projektów SAP można wskazać wiele przyczyn takiej sytuacji. Poniżej przedstawiam wybrane siedem, które najczęściej powodują utratę kontroli nad projektem.

1. Brak jednoznacznego zakresu projektu

Jednym z najczęstszych źródeł problemów w projektach SAP jest brak precyzyjnie określonego zakresu już na etapie inicjowania projektu. W przypadku SAP jest to szczególnie istotne, ponieważ system obejmuje wiele wzajemnie powiązanych procesów, modułów, interfejsów i danych. Pozornie niewielka zmiana w jednym obszarze może mieć konsekwencje w innych częściach rozwiązania.

Problem często zaczyna się od bardzo ogólnego celu, np.:

• wdrożenie nowego procesu fakturowania,
• optymalizacja FI,
• migracja do S/4HANA.

Tak sformułowany cel nie odpowiada na kluczowe pytania:

• co dokładnie zostanie zmienione,
• czego projekt nie obejmuje,
• jakie procesy są objęte analizą,
• jakie systemy i interfejsy trzeba zmodyfikować,
• jaki będzie końcowy rezultat,
• jakie są kluczowe mierniki sukcesu projektu.

Brak jednoznacznego zakresu prowadzi przede wszystkim do tzw. scope creep, czyli stopniowego rozszerzania zakresu projektu bez odpowiedniej kontroli nad czasem, budżetem i zasobami.

Co powinien zawierać dobrze zdefiniowany zakres?

Dobry zakres projektu SAP powinien jasno określać:

1. Co robimy (np.: zmiana procesu płatności dla dwóch company codes, konfiguracja nowego formatu płatności, modyfikacja określonych interfejsów, migracja określonego zakresu danych).
2. Czego nie robimy (np.: projekt nie obejmuje zmian procesu płatności dla pozostałych company codes, przebudowy istniejących interfejsów ani zmian w procesach AP niezwiązanych z nowym formatem płatności). To często najbardziej pomijany element na początku projektu. A szczegółowe doprecyzowanie w tym obszarze może później oszczędzić wiele dyskusji.
3. Jakie systemy są objęte projektem (np.: SAP S/4HANA, system bankowy, middleware, system raportowy, system zewnętrzny).
4. Jakie procesy są objęte projektem (szczegółowy opis procesu biznesowego).
5. Jakie są produkty do dostarczenia (np.: konfiguracja, development, dokumentacja, testy, migracja, szkolenie, instrukcja dla użytkowników).
6. Jakie są mierniki sukcesu projektu (np.: transakcje SAP, interfejsy i joby działające w tle spełniają uzgodnione wymagania dotyczące wydajności lub osiągnięto oczekiwane korzyści biznesowe, takie jak ograniczenie pracy manualnej, skrócenie czasu przetwarzania, zmniejszenie liczby błędów lub usprawnienie raportowania).
7. Jak będą obsługiwane zmiany zakresu.

Problemem nie jest samo pojawienie się nowych wymagań. W dużym projekcie SAP jest to wręcz nieuniknione. Błędem jest akceptowanie ich bez formalnej oceny wpływu na projekt. Każde nowe wymaganie powinno zostać ocenione pod kątem wpływu na zakres, czas i budżet.

Podsumowanie

Definiowanie szczegółowego zakresu projektu SAP jest kluczowe na początku projektu i nie powinno być traktowane jako formalność, której nie poświęca się należytej uwagi. Jest to bowiem budowanie narzędzia do zarządzania projektem przez cały jego cykl życia.

Im bardziej skomplikowane środowisko SAP, tym ważniejsze jest określenie granic projektu. Nie chodzi o to, aby przewidzieć każdą pojedynczą zmianę. Chodzi o to, aby stworzyć jasne punkty odniesienia, dzięki którym każdą nową potrzebę można świadomie zaklasyfikować jako: „w zakresie”, „poza zakresem” albo „zmiana wymagająca formalnej decyzji”.

W przeciwnym razie projekt może formalnie realizować pierwotny plan, a jednocześnie faktycznie wykonywać zupełnie inny projekt niż ten, na który zatwierdzono budżet i termin.

2. Zbyt optymistyczne planowanie

Jednym z najczęstszych problemów projektów SAP jest zbyt optymistyczne planowanie czasu, budżetu i zasobów.

W kwestii czasu jednym z najbardziej niebezpiecznych zdań w projekcie SAP jest przykładowe: „To powinno zająć około dwóch tygodni.”

Nie dlatego, że dwa tygodnie są nierealne. Problem pojawia się wtedy, gdy szacunek nie uwzględnia rzeczywistych zależności. Choć dewelopment czy konfiguracja może potrwać założoną liczbę dni, to w oszacowaniach trzeba zawsze uwzględnić również czas potrzebny na: przygotowanie danych, integracje, testy, poprawki, akceptacje biznesu, zależności od zadań innych osób oraz dostępność kluczowych zasobów.

W rezultacie bowiem zadanie, które na poziomie technicznym wygląda na dwutygodniowe, może wpłynąć na harmonogram na kilka tygodni. Projekty SAP rzadko realizowane są w izolacji. Zmiana jednego elementu może mieć wpływ na wiele innych obszarów. To często właśnie zależności, a nie same zadania, decydują o terminie zakończenia projektu.

Dodatkowo, w zbyt optymistycznym harmonogramie zakłada się zazwyczaj, że:

• wymagania są kompletne,
• biznes szybko podejmie decyzje,
• dane testowe będą dostępne,
• konfiguracja zadziała za pierwszym razem,
• dewelopment nie będzie wymagał poprawek,
• interfejs zadziała od pierwszego testu,
• użytkownicy zaakceptują rozwiązanie,
• nie będzie problemów z transportami,
• kluczowi eksperci będą dostępni,
• inne projekty nie będą konkurować o zasoby.

Każde z tych założeń może być rozsądne indywidualnie. Problem polega na tym, że prawdopodobieństwo realizacji wszystkich założeń jednocześnie jest znacznie mniejsze.

Dlatego harmonogram zbudowany wyłącznie na „happy path” często wygląda bardzo dobrze aż do momentu rozpoczęcia realizacji. „Jeśli wszystko pójdzie dobrze” nie jest planem. Bardzo ważne jest, aby Project Manager potrafił odróżniać planowany czasu wykonania zadania od realnego czasu potrzebnego do przeprowadzenia całego procesu (a więc czasu, który uwzględnia wszystkie zależności).

Optymistyczne planowanie zasobów

Kolejnym problemem jest zbyt optymistyczne planowanie zasobów. Nawet jeśli w harmonogramie założymy, że osoba dedykowana do projektu jest w 100% dostępna przez dwa tygodnie, to w rzeczywistości ta sama osoba może też mieć: produkcyjne incydenty, inne projekty, zadania utrzymaniowe, spotkania, wsparcie użytkowników, pilne poprawki.

Dlatego często dostępność zasobu w organizacji nie oznacza jego dostępności dla projektu.

To jeden z powodów, dla których harmonogram może wyglądać realistycznie z perspektywy PM-a, ale być niemożliwy do wykonania przez zespół.

Optymistyczne planowanie fazy testów

I ostatecznie warto również podkreślić, że często dużym problemem w projektach SAP jest zbyt optymistyczne planowanie fazy testowania. Testy są często jednym z najbardziej niedoszacowanych elementów.

Typowy plan może zakładać np. 5 dni na testy integracyjne i 2 tygodnie na testy biznesowe akceptujące rozwiązanie.

Brakuje jednak często w fazie planowania harmonogramu projektu odpowiedzi na szczegółowe pytania:

• Czy dane testowe są gotowe?
• Czy wszystkie systemy są dostępne?
• Czy interfejsy działają?
• Czy użytkownicy mają odpowiednie uprawnienia?
• Kto wykonuje testy?
• Ile scenariuszy trzeba przetestować?
• Co dzieje się po znalezieniu błędu?
• Ile czasu potrzeba na poprawkę?
• Czy poprawka wymaga ponownego pełnego testu?

W praktyce testowanie nie jest bowiem pojedynczym zadaniem, a jest cyklem:

test → błąd → analiza → poprawka → transport → ponowny test → kolejny błąd → poprawka → retest.

Jeżeli harmonogram nie przewiduje miejsca na ten cykl, pierwsze problemy z testami natychmiast wpływają na termin zakończenia projektu.

3. Zbyt późne podejmowanie decyzji

Jednym z problemów, który bardzo często spowalnia projekty SAP, nie jest brak kompetencji zespołu ani problemy techniczne, lecz brak decyzji podejmowanych w odpowiednim momencie.

W projekcie SAP niemal każdego dnia pojawiają się pytania wymagające decyzji biznesowej lub projektowej. Problem pojawia się wtedy, gdy pytanie trafia do osoby decyzyjnej, ale odpowiedź pojawia się dopiero wtedy, gdy zespół nie może już bez niej kontynuować pracy.

„Zdecydujemy później” jest często kosztowną decyzją.

W projektach SAP często pojawia się przekonanie, że nie musimy decydować teraz. Wrócimy do tego później. Problem polega na tym, że koszt decyzji może rosnąć wraz z postępem projektu.

Dodatkowo, bardzo niebezpieczna jest niejasna odpowiedzialność. Często nie jest jasne: Kto właściwie ma podjąć decyzję? Analityk uważa, że decyzję powinien podjąć biznes. Biznes uważa, że powinien zdecydować IT. IT uważa, że decyzja należy do właściciela procesu. Process Owner uważa, że potrzebuje opinii Steering Committee. W efekcie pytanie zaczyna krążyć między kolejnymi osobami i powstaje klasyczna sytuacja: wszyscy są zaangażowani, ale nikt nie jest właścicielem decyzji.

Dlatego dla kluczowych decyzji warto jednoznacznie określić:

• Decision Owner – kto podejmuje decyzję,
• Decision Date – do kiedy musi zostać podjęta,
• Input – kto dostarcza informacje,
• Impact – co zostanie zablokowane, jeśli decyzji nie będzie.

Inne pułapki

Kolejną, często powtarzalną w projektach SAP pułapką jest założenie, że pojawiające się pytania, a wraz z nimi decyzje, które trzeba podjąć, gromadzone są i omawiane tylko na spotkaniach statusowych, np. raz w tygodniu. Jeżeli decyzja blokuje dewelopera od poniedziałku, a spotkanie zespołu odbywa się w piątek, zespół może stracić cały tydzień.

Dodatkowo, bardzo częstym zjawiskiem obserwowanym w projektach SAP przy pojawiających się pytaniach jest unikanie podjęcia decyzji poprzez podawanie wyjaśnienia: „Potrzebujemy więcej informacji”. To jedna z najczęstszych przyczyn odkładania decyzji. Oczywiście, niektóre decyzje rzeczywiście wymagają dodatkowej analizy – ale często jest to przeciągane w czasie, a ta analiza staje się sposobem na uniknięcie podjęcia decyzji.

W pewnym momencie trzeba przejść z: „Potrzebujemy jeszcze informacji” do: „Mamy wystarczającą ilość informacji, aby podjąć decyzję przy akceptowalnym poziomie ryzyka”. Projekt nie może czekać na moment, w którym wszystkie informacje będą znane, ponieważ taki moment często nigdy nie nastąpi.

Podsumowanie

Biorąc pod uwagę wszystko powyższe, decyzje powinny mieć własny mechanizm obsługi, np. Decision Log, który będzie zawierał nie tylko listę otwartych tematów, ale również:

• czego dotyczy decyzja,
• jakie są dostępne opcje,
• kto jest właścicielem,
• do kiedy decyzja musi zostać podjęta,
• jaki jest wpływ braku decyzji,
• kiedy temat został eskalowany.

Project Manager nie musi podejmować każdej decyzji. Musi jednak dopilnować, aby decyzje były podejmowane na czas przez właściwe osoby.

4. Niewystarczające zaangażowanie biznesu

Jednym z najbardziej niedocenianych problemów projektów SAP jest niewystarczające zaangażowanie biznesu. Projekt SAP nie jest przecież wyłącznie projektem IT. System ma przede wszystkim wspierać procesy biznesowe, dlatego bez aktywnego udziału osób, które znają te procesy, zespół projektowy może stworzyć rozwiązanie technicznie poprawne, ale niedopasowane do rzeczywistych potrzeb organizacji.

Jednym z najczęstszych błędów jest traktowanie zespołu biznesowego jako odbiorcy rozwiązania zamiast jako części zespołu projektowego. Projekt SAP nie może być wdrożony wyłącznie przez IT.

IT buduje → biznes na końcu sprawdza.

W rzeczywistości prawidłowy model powinien wyglądać bardziej jak:

Biznes definiuje potrzebę → wspólnie projektujemy rozwiązanie → IT implementuje → biznes testuje → wspólnie podejmujemy decyzję o uruchomieniu.

Konsultant SAP może bardzo dobrze znać system, ale nie musi znać specyfiki konkretnej organizacji. Dlatego właśnie zaangażowanie biznesu od samego początku projektu jest bardzo ważne. Biznes powinien czynnie uczestniczyć w fazie planowania i zbierania wymagań, a więc brać udział w warsztatach, formułowaniu wymagań, podejmowaniu kluczowych decyzji.

Rola biznesu

Jednak zaangażowanie biznesu nie powinno kończyć się tylko na fazie planowania i testowania. Oczywiste jest, że użytkownicy końcowi mają swoje codzienne operacyjne obowiązki. Niemniej, w trakcie fazy realizacji, czyli budowania rozwiązania, bardzo często potrzebne są również decyzje biznesowe – bo pojawiają się pytania.

Niejednokrotnie biznes nie jest traktowany jako stały element zespołu projektowego, nie jest zapraszany na spotkania projektowe, bo przecież nie ma czasu, nie ma takiej potrzeby, kluczowe decyzje są podejmowane bez biznesu w oparciu o jakieś założenia lub najlepsze praktyki. A potem, kiedy następuje faza biznesowych testów, okazuje się, że nie takie były oczekiwania tych, którzy będą z rozwiązania korzystać.

Niewystarczające zaangażowanie biznesu często wynika z chęci jego odciążenia. Logika wygląda następująco: „Nie angażujmy użytkowników za bardzo, ponieważ mają dużo pracy operacyjnej”. Tymczasem później biznes musi poświęcić znacznie więcej czasu na: wyjaśnianie problemów, dodatkowe warsztaty, poprawki, ponowne testy, szkolenia, obsługę problemów po Go-Live. Oszczędność czasu biznesu na początku projektu może więc wygenerować znacznie większe obciążenie na jego końcu.

W fazie testowania niezmiernie ważne jest, aby odpowiednio dużo czasu zaplanować na zadania projektowe biznesu. Bo testowanie to dużo więcej niż tylko sprawdzanie działania rozwiązania. Biznes musi mieć czas na rzetelne przygotowanie scenariuszy i wszystkich danych testowych. Ta faza przygotowań do testów nie jest często traktowana poważnie, a stanowi podstawę sukcesu projektu.

Zadania dla biznesu

Biznes powinien:

• przygotować dane testowe,
• wykonać testy,
• potwierdzić scenariusze,
• podjąć decyzje,
• zaakceptować rozwiązanie,
• czynnie uczestniczyć w przygotowaniu organizacji do Go-Live.

To wszystko wymaga zabezpieczenia zasobów po stronie biznesu.

Zadaniem Project Managera powinna być również ochrona czasu Key Userów. Jeżeli organizacja wymaga od Key Usera: „Normalna praca + 30% projektu SAP” bez zmiany jego pozostałych obowiązków, może się okazać, że projekt otrzyma tylko te 30% czasu, które pozostanie po wykonaniu wszystkich pilnych zadań operacyjnych. A to może się okazać niewystarczające dla projektu.

Dlatego bardzo ważne jest ustalenie od samego początku:

• ile czasu biznes przeznacza na projekt,
• jakie zadania operacyjne mogą zostać przekazane innym osobom,
• kto zastępuje Key Usera podczas jego nieobecności,
• które aktywności projektowe są obowiązkowe.

Zaangażowanie biznesu musi być zabezpieczone organizacyjnie, a nie tylko oczekiwane.

Podsumowanie

Podsumowując powyższe, w projekcie SAP biznes nie powinien być traktowany jako odbiorca gotowego rozwiązania, ale jako jego współtwórca. W związku z tym powinien być angażowany na każdym etapie projektu. Project Manager może koordynować projekt, konsultant może zaprojektować rozwiązanie, a deweloper może je zbudować. Żaden z nich nie zastąpi jednak właściciela biznesowego procesu.

Dlatego jednym z kluczowych warunków powodzenia projektu SAP jest nie samo „posiadanie biznesu w projekcie”, ale zapewnienie, że biznes ma czas, kompetencje i mandat do podejmowania decyzji oraz akceptowania rezultatów projektu.

5. Testy traktowane jako jeden z ostatnich etapów projektu

Jednym z częstych błędów w projektach SAP jest traktowanie testów jako końcowej fazy projektu, która rozpoczyna się dopiero wtedy, gdy konfiguracja i development są już zakończone.

Podejście często wygląda tak:

Analiza → Projektowanie → Konfiguracja/Dewelopment → Testy → Go-Live

Na pierwszy rzut oka jest to logiczne. Problem polega na tym, że w projekcie SAP testowanie nie powinno być wyłącznie etapem następującym po implementacji. Testowanie powinno towarzyszyć projektowi od początku.

Jeżeli testy zaczynają się zbyt późno, projekt może przez wiele miesięcy budować rozwiązanie, którego poprawność biznesowa zostaje zweryfikowana dopiero pod koniec.

„Najpierw zbudujmy, potem przetestujemy” – to jedno z najbardziej ryzykownych założeń. Zespół kończy konfigurację i development, a następnie przekazuje rozwiązanie do testerów.

Wtedy pojawiają się pytania:

• Czy proces rzeczywiście odpowiada wymaganiom?
• Czy wszystkie scenariusze zostały uwzględnione?
• Czy integracje działają?
• Czy dane są poprawne?
• Czy użytkownicy mogą wykonać proces end-to-end?
• Czy wyjątki biznesowe zostały obsłużone?
• Czy raporty pokazują właściwe dane?

Jeżeli odpowiedź na któreś z tych pytań brzmi „nie”, projekt odkrywa problem bardzo późno.

A im później wykryty zostaje błąd, tym większy może być koszt jego usunięcia.

Testy bowiem nie są tylko mechanizmem kontroli jakości, ale także mechanizmem wczesnego wykrywania błędnych założeń.        

Bardzo niebezpieczna jest sytuacja, w której użytkownicy biznesowi po raz pierwszy widzą docelowe rozwiązanie dopiero podczas UAT. Wtedy bowiem może się okazać, że: „To nie jest proces, którego potrzebujemy.”

To nie musi oznaczać błędu technicznego.

Może oznaczać, że projekt wcześniej nie zweryfikował wystarczająco dokładnie:

• wymagań,
• procesu TO-BE,
• wyjątków,
• oczekiwań użytkowników.

UAT nie powinien być momentem, w którym biznes projektuje rozwiązanie od nowa. Powinien być przede wszystkim potwierdzeniem, że rozwiązanie spełnia wcześniej uzgodnione wymagania. Jeśli to możliwe, warto wprowadzać w projekcie mechanizmy, które pozwolą biznesowi na walidację budowanego rozwiązania lub jego elementów w trakcie trwania dewelopmentu.

Presja testowania

Bardzo poważnym i częstym problemem jest również to, że testy końcowe UAT zaczynają się zbyt późno, a termin Go-Live pozostaje bez zmian. Projekt ma ustaloną datę Go-Live. Development się opóźnia. Pierwotnie na testy przewidziano sześć tygodni. Po opóźnieniu dewelopmentu zostają trzy tygodnie. Data Go-Live jednak pozostaje niezmieniona. I na biznes nakładana jest presja, że muszą jak najszybciej zakończyć testowanie.

W praktyce oznacza to:

opóźnienie dewelopmentu → skrócenie testów → mniej scenariuszy → mniej czasu na poprawki → większe ryzyko przed Go-Live.

Często projekt próbuje „nadrobić” opóźnienie właśnie kosztem testów. To szczególnie niebezpieczne, ponieważ testy są wtedy traktowane jako bufor harmonogramu, a nie jako niezbędny element jakości rozwiązania.

Jeżeli testy zaczynają się późno, pojawia się duża liczba błędów jednocześnie.

Na przykład:

50 błędów → 10 deweloperów → 2 tygodnie do Go-Live.

Zespół zaczyna wtedy pracować w trybie:

błąd → poprawka → transport → test → kolejny błąd → poprawka → transport → test.

W pewnym momencie coraz trudniej określić, która wersja rozwiązania jest właściwie przetestowana. Może powstać chaos transportowy i testowy.

Project Manager powinien również uważać na sytuację: „Nie mamy już czasu na kolejne testy, więc musimy przejść do Go-Live”.

To jest bardzo ważny sygnał ostrzegawczy. Brak czasu nie oznacza, że rozwiązanie jest gotowe. Jeżeli testy zostały skrócone z powodu wcześniejszych opóźnień, należy świadomie ocenić: co zostało przetestowane, czego nie przetestowano i jakie ryzyko przyjmujemy. Tylko na podstawie tych wszystkich faktów można podjąć decyzję, czy GoLive powinien się odbyć.

Podsumowanie

Podsumowując wszystko powyższe, z perspektywy Project Managera bardzo ważna jest zmiana z podejścia: „Najpierw zbudujemy rozwiązanie, a potem sprawdzimy, czy działa” na rzecz: „Od początku projektu wiemy, w jaki sposób udowodnimy, że rozwiązanie działa”.

Testowanie powinno więc być obecne już podczas definiowania wymagań. Jeżeli biznes wymaga określonego rezultatu, powinno być wiadomo, jak ten rezultat zostanie później zweryfikowany.

W dobrze prowadzonym projekcie SAP testy nie są ostatnią przeszkodą przed Go-Live. Są mechanizmem kontroli jakości przez cały projekt.

A jedna zasada jest szczególnie ważna: Im później wykryjemy problem, tym mniej mamy czasu oraz możliwości jego naprawy i tym większa jest presja na projekt. Dlatego testów nie należy przesuwać na koniec projektu – należy zadbać o to, aby problemy były możliwe do wykrycia jak najwcześniej.

6. Brak kontroli nad zmianami

Jednym z problemów, które mogą w największym stopniu destabilizować projekt SAP, jest brak kontroli nad zmianami. W praktyce niemal każdy projekt w trakcie realizacji otrzymuje nowe wymagania, zmiany biznesowe, dodatkowe scenariusze lub korekty wcześniejszych ustaleń. Sam fakt pojawiania się zmian nie jest więc problemem.

Problem zaczyna się wtedy, gdy zmiany są wprowadzane bez oceny ich wpływu na zakres, budżet, harmonogram, zasoby i ryzyko projektu. Wtedy projekt stopniowo zaczyna wyglądać inaczej niż ten, na który pierwotnie zatwierdzono budżet i termin.

Bardzo często Project Manager słyszy: „To tylko mała zmiana”.

W projektach SAP właśnie od takich zdań zaczyna się wiele problemów. Jedna mała zmiana. Potem kolejna. Następnie dodatkowy raport. Nowe pole. Dodatkowy interfejs. Zmiana procesu. Kolejny wyjątek. Każda zmiana może wydawać się niewielka, ale ich suma może znacząco zmienić projekt.

Dlatego Change Request nie powinien być postrzegany jako biurokracja. Jest narzędziem kontroli projektu. Każda zmiana może być racjonalna. Project Manager nie powinien więc traktować każdej zmiany jako czegoś negatywnego.

Powinien natomiast zadać pytania:

• Jaki jest wpływ tej zmiany?
• Ile dodatkowej pracy wymaga?
• Które zadania zostaną przesunięte?
• Czy potrzebujemy dodatkowych zasobów?
• Czy zmienia się zakres projektu?
• Czy zmienia się budżet?
• Czy zmienia się data Go-Live?
• Jakie nowe ryzyka powstają?
• Kto zatwierdza zmianę?

Dopiero wtedy można podjąć świadomą decyzję.

Jeżeli projekt przyjmuje nowe wymagania bez aktualizacji harmonogramu, budżetu i zakresu, Project Manager w pewnym momencie zaczyna odpowiadać za projekt, którego pierwotnie nie planował. Zarządzanie zmianą jest zatem bardzo kluczowym elementem prowadzenia projektu i zapewnienia jego sukcesu.

Konsekwencje zmian

Bardzo ważne jest również, aby zespół projektowy i osoby podejmujące ostateczną decyzję o dodaniu zmiany do zakresu projektu miały pełną świadomość, że choć dana zmiana zakresu nie musi oznaczać konieczności wprowadzania dodatkowego budżetu, to prawie zawsze będzie wiązała się z innymi konsekwencjami.

Kluczowa zasada brzmi: Jeżeli zwiększamy zakres bez zwiększenia budżetu, musimy zmienić coś innego.

Możliwe warianty to:

• Zakres ↑ + Budżet ↑ – projekt zostaje rozszerzony i otrzymuje dodatkowe finansowanie.
• Zakres ↑ + Termin ↑ – dodajemy funkcjonalność, ale przesuwamy Go-Live.
• Zakres ↑ + Zasoby ↑ – dodajemy zasoby, aby utrzymać termin.
• Zakres ↑ + Priorytetyzacja ↓ – dodajemy nową funkcję, ale usuwamy lub przesuwamy inną.

Problem zaczyna się wtedy, gdy organizacja oczekuje:Zakres ↑ + termin bez zmian + budżet bez zmian + zasoby bez zmian – to jest matematycznie bardzo trudne do utrzymania.

Podsumowanie

Kontrola nad zmianami nie oznacza blokowania biznesu ani projektu. Oznacza zapewnienie, że każda istotna zmiana jest świadomą decyzją, a nie przypadkowym rozszerzeniem projektu.

Project Manager powinien stworzyć środowisko, w którym można powiedzieć: „Tak, możemy to zrobić”, ale zaraz potem: „Sprawdźmy, jaki będzie wpływ na zakres, termin, budżet i ryzyko.”

Dzięki temu decyzja nie brzmi: „Czy możemy dodać jeszcze jedną funkcję?”, ale: „Czy jesteśmy gotowi zaakceptować konsekwencje dodania tej funkcji?”.

W projektach SAP zmiany są nieuniknione. Brak kontroli nad zmianami nie jest.

A najważniejsza zasada brzmi: Nie zarządzamy tym, ile zmian pojawia się w projekcie. Zarządzamy tym, jakie zmiany akceptujemy, kiedy je realizujemy i jaki mają wpływ na cały projekt.

7. Project Manager dowiaduje się o problemach zbyt późno

Projekt nie traci kontroli w dniu, w którym pojawia się problem. Traci ją wtedy, gdy problem jest niewidoczny albo jest ignorowany zbyt długo.

Jeżeli zadanie jest opóźnione o jeden dzień, można jeszcze łatwo zareagować. Jeżeli po trzech tygodniach nadal słyszymy: „Jesteśmy prawie gotowi”, to sytuacja wygląda już zupełnie inaczej.

Dlatego Project Manager potrzebuje nie tylko statusu „zielony/żółty/czerwony”, ale przede wszystkim wiarygodnej informacji.

Warto regularnie monitorować:

• kluczowe kamienie milowe,
• zadania na ścieżce krytycznej,
• otwarte decyzje,
• zależności,
• ryzyka,
• Change Requesty,
• defekty,
• dostępność kluczowych zasobów,
• gotowość biznesu do testów i Go-Live.

Najgorszym statusem projektu nie jest czerwony. Najgorszy jest fałszywie zielony. Czerwony projekt można jeszcze ratować. Projekt, o którym wszyscy długo myślą, że jest zielony, a który faktycznie jest czerwony, może być znacznie trudniejszy do uratowania.

Zarządzanie projektem SAP nie polega na tym, żeby przewidzieć każdy problem. To niemożliwe. Rolą Project Managera jest stworzenie takiego sposobu pracy, aby problemy były:

widoczne odpowiednio wcześnie → przypisane do właściciela → rozwiązane lub eskalowane.

Dlatego dobry Project Manager powinien regularnie zadawać kilka prostych pytań i uzyskiwać na nie wiarygodne i szczere odpowiedzi:

1. Co może zagrozić terminowi?
2. Jakie decyzje są nadal otwarte?
3. Które zadania są opóźnione i dlaczego?
4. Czy zakres projektu nadal jest taki sam jak na początku?
5. Czy mamy odpowiednie zasoby biznesowe i techniczne?
6. Czy testy rzeczywiście potwierdzają gotowość rozwiązania?
7. O czym powinienem wiedzieć dzisiaj, zanim dowiem się o tym za miesiąc?

To ostatnie pytanie jest szczególnie ważne.

Sii x SAP

Jako SAP Silver Partner posiadamy wieloletnie doświadczenie we wdrażaniu rozwiązań ERP w firmach o różnej skali i poziomie złożoności procesów.

Oferta SAP

Podsumowanie

Projekty SAP nie tracą kontroli z powodu jednego dużego błędu. Najczęściej jest to suma małych problemów:

niejasny zakres + optymistyczne planowanie + opóźnione decyzje + ograniczone zaangażowanie biznesu + późne testy + niekontrolowane zmiany + zbyt późna informacja o problemach.

Każdy z tych elementów osobno może wydawać się możliwy do opanowania. Problem zaczyna się wtedy, gdy występują jednocześnie.

Dlatego skuteczny Project Manager nie skupia się wyłącznie na tym, czy projekt realizuje plan. Powinien przede wszystkim obserwować, czy projekt nadal ma warunki, aby ten plan zrealizować. Bo w projektach SAP problemy rzadko pojawiają się nagle. Najczęściej przez długi czas dają sygnały ostrzegawcze. Trzeba tylko odpowiednio wcześnie je zauważyć.

Bibliografia i źródła

1. SAP – SAP Activate Methodology
2. SAP Learning – Describing the SAP Activate Methodology Structure
3. SAP Help Portal – Getting Started with SAP Activate
4. Project Management Institute (PMI) – What is Project Management?
5. Project Management Institute – Scope and Stakeholder Management: Pain Points, Perils, and Prosperity
6. Project Management Institute – The Standard for Risk Management in Portfolios, Programs, and Projects
7. Project Management Institute – Managing Stakeholders to Achieve True Implementation Success
8. Project Management Institute – Scope Change Control