Ratowanie projektów, czyli czym są projekty „recovery”

Kiedy projekt wymaga naprawy?

Mówimy tutaj o konkretnych sytuacjach, które pojawiły się podczas realizacji projektu:

1. Brak holistycznej wizji całości rozwiązania i niejasności związane z wymaganiami (są one nieprecyzyjne, stoją w sprzeczności).
2. Kwestie harmonogramowe (nierealistyczny lub nadmiernie optymistyczny harmonogram).
3. Planowanie na podstawie braku kluczowych informacji i elementów lub w oparciu o błędne szacunki.
4. Braki zasobowe (zbytnie obciążenie zasobów, niemożność efektywnej ich alokacji, brak kompetencyjny na poziomie zasobów).
5. Niepełne lub brak zarządzania ryzykiem oraz zagrożeniami związane z projektami.

Problemy te mogą wystąpić w dwóch obszarach: zarządczym oraz merytorycznym. O ile te związane z zarządzaniem projektami zwykle są do opanowania, o tyle te dotyczące przygotowania merytorycznego niejednokrotnie stanowią bardzo trudną do przejścia sytuację.

Weźmy na przykład kwestię internacjonalizacji projektu, stopień skomplikowania projektu wzrasta na wschód od Odry i południe od Alp. Rośnie dywersyfikacja rynków i jeżeli firmy nie założą pewnych standardów na początku może okazać się, że pomimo wdrożonego projektu nie spełnia on założeń biznesowych firmy i generuje dużo kłopotów. – mówi Remigiusz Efinowicz, Executive Director International Sales oraz Managing Partner w Hicron.

Projekt się psuje

A teraz wyobraźmy sobie, że klient jest w czasie trwania projektu, ale wszystkie wskaźniki, w tym KPI wskazują, że przekroczone zostały plany zarówno budżetowe jak i harmonogram. Projekt zostaje wstrzymany. – Mieliśmy taką sytuację u jednego z naszych klientów z regionu DACH. Klient razem z firmą doradczą, głównym wykonawcą, utknęli na poziomie tworzenia koncepcji facility management. Samo rozwiązanie było nieefektywne, procesy fakturowania trwały około dwóch tygodni. Klient szukał rozwiązania dla tej sytuacji. Firma doradcza próbowała pomóc, ale brakowało jej kompetencji by wyjść poza typowy standard systemu ERP. Reasumując, rozwiązanie zostało wdrożone, ale było ekstremalnie nieefektywne.

Zostaliśmy zaproszeni do współpracy przy rozwiązaniu tej sytuacji. Popatrzeliśmy na główne cele przyświecające klientowi i zaproponowaliśmy alternatywne rozwiązanie, ale w pełni bazujące na wdrożonych już modułach systemu. Nasza metoda pozwoliła klientowi na koncentracji na samym biznesie, a nie na strukturze systemu. W ciągu miesiąca dopracowaliśmy koncepcję, nad którą klient pracował od roku. – mówi Remigiusz Efinowicz.

W czasie kolejnych 7 miesięcy Hicron zaimplementował i wdrożył kompletne rozwiązanie, które w istotny sposób zautomatyzowało pracę użytkowników i wpłynęło na realizację celów biznesowych klienta:

• skrócenie czasu fakturowania z 2 tygodni do 12 godzin,
• zmniejszenie liczby osób obsługujących wskazany obszar z 8 do 3.

Reasumując, klient osiągnął zakładane cele biznesowe w oparciu o to samo rozwiązanie ERP. Pierwotny dostawca był wyspecjalizowany w standardowym podejściu do zarządzania procesami przedsiębiorstwa, ale brakowało mu odwagi i wiedzy jak wyjść poza znane mu rozwiązanie i bazując na istniejącej infrastrukturze zaproponować coś innowacyjnego opartego o ten sam system ERP.

Projekt się popsuł

Inna sytuacja, międzynarodowy klient z odległej Azji. Wdrożenie standardowego rozwiązania, ale nie zostało wzięte pod uwagę wymagane zaplecze merytoryczne, co skutkowało nieprzygotowaniem do jego implementacji na zróżnicowanych rynkach. W podejściu wdrożeniowym nie uwzględniono:

• standaryzacji podstawowych procesów,
• elastyczności procesów względem wymagań regionalnych (chociażby kwestii legislacyjnych w danych krajach).

Często postrzega się te dwa punkty jako stojące w sprzeczności co prowadzi do tego, że firmy z obawy przed nadmierną komplikacją próbują wszystko upraszczać i budują rozwiązanie, którego poziom przydatności na zdywersyfikowanych rynkach jest bardzo niski. A to dlatego, że użytkownicy końcowi są niezadowoleni z tego, w jaki sposób dany system wspiera ich działalność – mówi Efinowicz.

W opisanej sytuacji konieczne jest ustabilizowanie takiego systemu i usunięcie największych problemów, a docelowo zrobienie reinżynieringu samego rozwiązania. Ta ostatnia część jest istotna, ponieważ systemy do zarządzania zasobami przedsiębiorstwa to narzędzia, które nieustannie powinny być aktualizowane zgodnie z zachodzącymi zmianami rynkowymi na danym obszarze.

Warto też zwrócić uwagę na to, że w procesie digitalizacji oczekiwania są takie, by jak najszybciej wdrażać zmiany w kontekście procesów biznesowych i rosnącej konkurencji. Reinżynieria projektu wspiera skracanie cyklu zmian w obszarze działań operacyjnych firmy.

To kosztuje zbyt dużo

Zdarza się również, że powodem, dla którego uruchamiany jest projekt „recovery” są zbyt wysokie koszty związane z implementacją rozwiązania na różne rynki, tzw. rollouty. Zmiana optykia w zakresie przenoszenia wymagań dla nowych obszarów, wymaga podejścia konsultingowego. Przykładem może być firma, która robiła wiele różnych międzynarodowych wdrożeń swojego systemu. Po znacznym przekroczeniu budżetu i terminów w Stanach Zjednoczonych zwrócili się do Hicron z zapytaniem czy istnieje możliwość opracowania nowego podejścia w zakresie tego typu projektów. Nadrzędnym celem było przyspieszenie procesu rolloutów jak również obniżenie kosztów.

W tej sytuacji nie byliśmy partnerem wdrożeniowym, nie implementowaliśmy żadnego oprogramowania, zajmowaliśmy się wyłącznie wsparciem konsultingowym. Problem został rozwiązany we współpracy z kierownictwem całego programu – wspomina Remigiusz Efinowicz.

Kluczowymi aspektami okazały się zarządzanie wymaganiami przy okazji nowych rynków i rozwiązanie problemu związanego z przekroczonymi terminami implementacji. W tego typu sytuacjach należy rozgraniczyć wymagania projektowe na dwie grupy:

1. wymagania legislacyjne – związane z systemem ekonomiczno-prawnym danego obszaru.
2. wymagania funkcjonalne – związane z przyzwyczajeniami, uwarunkowaniami kulturowymi danego regionu.

Warto wziąć pod uwagę fakt, że w takiej sytuacji może pojawić się konflikt pomiędzy właścicielem systemu centralnego, a podmiotem wchodzącym w skład organizacji. Spółka zależna stara się zazwyczaj zachować swoje metody funkcjonowania, które główna organizacja próbuje ujednolicić.

Naszą propozycją było to, aby w pierwszej kolejności zająć się wdrożeniem wymagań prawnych, a co do pozostałych, zaleciliśmy aby trafiły one na listę wymagań funkcjonalnych, którymi będzie zarządzało powołane specjalnie w tym celu gremium centralne – ciało zarządzające. Pozwoli to na wyłonienie i wdrożenie najlepszych praktyk wywodzących się zarówno z głównej spółki, jak i podmiotu zależnego. Kolejną propozycją było stworzenie akceleratorów i narzędzi pomagających przy implementacji rozwiązań informatycznych na nowe rynki, takie jak gotowe wzorce dokumentacji. I trzecim aspektem, który zaproponowaliśmy była zmiana podejścia do rolloutów. Polegała ona na tym, by potraktować pewne rynki jako klastry – wykazujące się pewnym podobieństwem: legislacyjnym, geograficznym lub kulturowym, i klastry te uruchamiać jednocześnie. Podejście to sprawiło, że pojedyncze rynki przestały być wyzwaniem i dodatkowym kosztem. – dodaje Efinowicz.

Akceleratory wspierające systematyzację projektów

W sytuacji, w której jesteśmy zmuszeni do reinżynieringu wdrożonego już rozwiązania opieramy się na stworzonych przez nas akceleratorach, które pomagają nam w tego typu przedsięwzięciach. Systematyzują i zapewniają jakość poprzez narzucenie standardu implementacji. Dzięki nim my i nasi klienci unikamy wielu problemów przy wdrożeniach. – mówi Remigiusz Efinowicz.

Akceleratory powstały, ponieważ osoby zajmujące się wdrożeniem: konsultanci, programiści, PMowie, każdy posiada swoje indywidualne podejście. Biorąc po uwagę holistyczny obraz rozwiązania indywidualizm ma negatywny wpływ na projekt. Akceleratory wymuszają pewien sposób implementacji, a wszyscy uczestnicy posługując się nim prowadzą spójne wdrożenie we wszystkich jego elementach. Docelowo pozwala także na obniżenie kosztów serwisowania, ponieważ wszystkie jego składowe realizowane są w oparciu o te same założenia i standardy.

Zapewnić wsparcie

Proces utrzymania wdrożonego rozwiązania ma bardzo istotny wpływ nie tylko na bieżące działanie przedsiębiorstwa, ale również na jego przyszłość. Najlepiej zaimplementowane rozwiązanie, które nie będzie w odpowiedni sposób rozwijane może z czasem utracić sporo na elastyczności. Z tego typu sytuacją mamy też często do czynienia w momencie podjęcia decyzji o rozszerzeniu działalności biznesowej na nowe rynki, kiedy okazuje się że nie jest to możliwe w oparciu o system będący w użyciu.

Źródło: HICRON