Powrót do bloga

Rozważania na temat wdrażania oprogramowania dla przedsiębiorstw i metodologii zarządzania projektami.

Każdy projekt wdrażania systemu ERP, niezależnie od zastosowanej metodologii lub sposobu etykietowania faz, jest strukturyzowany w ten sam typowy sposób.

  1. Inicjacja projektu
  2. Planowanie
  3. Projekt
  4. Rozwój
  5. Testowanie
  6. Szkolenia i zarządzanie zmianą
  7. Przygotowanie do uruchomienia
  8. Uruchomienie
  9. Wsparcie po uruchomieniu
  10. Zamknięcie projektu

I tak jest od co najmniej 30 lat. Kiedy firmy zaczęły stosować metodykę Agile w projektach (i wiem, że idę na skróty), tak naprawdę nie zmieniło to sposobu realizacji projektów; często oznaczało to jedynie, że (szczegółowe projektowanie,) rozwój i testowanie stały się cyklami iteracyjnymi.

  1. Inicjacja i planowanie
  2. Odkrycia i projektowanie
  3. Iteracyjne opracowywanie i testowanie
  4. Szkolenia użytkowników i zarządzanie zmianą
  5. Przygotowanie do uruchomienia
  6. Uruchomienie i stabilizacja
  7. Ciągłe doskonalenie

Ponadto, gdy dodano koncepcję „ciągłego doskonalenia”, niewiele organizacji miało pomysł, w jaki sposób można ją wdrożyć w swojej działalności, zwłaszcza gdy zespół ds. projektu wdrożeniowego ulega rozwiązaniu.

Struktura użyta do organizacji projektu ERP w sposób opisany we wstępie wynika z prawidłowego zrozumienia, że ​​platforma aplikacji oprogramowania wspiera (lub powinna wspierać) organizację: cele strategiczne i zadania organizacji, strukturę organizacyjną, jej zasięg geograficzny, jej działy, procesy biznesowe, wskaźniki KPI oraz wszystkie wymagania pracowników dotyczące wydajnej i efektywnej pracy. Oznacza to, że projekt rozpoczyna się od analizy firmy, sposobu jej obecnego funkcjonowania, sposobu jej organizacji oraz (strategicznych) wymagań i celów. Analiza ta koncentruje się na wymaganiach biznesowych, wymaganiach procesowych, celach i zadaniach biznesowych. W mniejszym stopniu analiza koncentruje się na wymaganiach technologii informacyjnej: to cele i wymagania biznesowe (powinny) napędzać wymagania technologii informacyjnej. Wyjątki dotyczą wymagań dotyczących migracji i integracji aplikacji; w tym przypadku popyt pochodzi z samej technologii.

Krótko mówiąc, metodologia stosowana w projektach ERP polega na analizie wymagań i zaprojektowaniu proponowanej organizacji, (zmienionych i nowych) procesów i aplikacji, zbudowaniu platformy aplikacyjnej w oparciu o projekt oraz szkoleniu i testowaniu nowych procesów i narzędzi. Ostatnim krokiem jest uruchomienie i wsparcie organizacji oraz rozwiązanie wszystkich problemów, z którymi organizacja boryka się w pierwszych dniach, tygodniach lub miesiącach po uruchomieniu.

Pytanie brzmi, jak skuteczne i efektywne są metodologie wdrożeniowe oparte na powyższych zasadach. Wiele współczesnych projektów ERP kończy się porażką lub jest uznawanych za mniej udane. Za udany projekt uważa się obecnie projekt, który przynajmniej zapewnia funkcjonalność na poziomie porównywalnym z poprzednim (zastąpionym) systemem, a aktualizacja technologii do dzisiejszych standardów jest uznawana za sukces…

I to jest dziwne, jeśli projekt uznaje się za sukces, podczas gdy „jedynym” plusem jest tak naprawdę nowa technologia, a organizacja pod względem kultury, procesów, wsparcia celów i zadań zyskała bardzo mało lub nic. Pytanie brzmi, dlaczego nadal trzymamy się tej metodologii?

Wyzwania związane z dzisiejszym wdrażaniem systemów ERP można najlepiej podsumować w następujący sposób:

  1. Organizacja jest rozczarowana wynikami
  2. Projekt trwa dłużej niż oczekiwano
  3. Koszt projektu przekracza założony budżet
  4. Między partnerem wdrażającym a klientem istnieje frustracja

Próbując powiązać te frustracje ze sposobem organizacji projektu wdrożeniowego lub zastosowaną metodologią, możemy stwierdzić, że następujące obszary stanowią główne przyczyny tzw. niepowodzeń wdrożeń ERP:

  1. Zarządzanie projektami i nadzór: rozrost zakresu, problemy z przydzielaniem i dostępnością zasobów oraz oczywiście nieumiejętność zorganizowania projektu przez kierownika projektu z powodu braku wsparcia lub dlatego, że metodologia nie jest wdrożona w organizacji i organizacja/kierownictwo jej nie rozumie.
  2. Zarządzanie zmianą i szkolenia użytkowników: Pracownicy opierają się zmianom z powodu nieznajomości systemu lub obawy przed utratą pracy, a także z powodu braku odpowiedniego przeszkolenia i komunikacji. Ilość i zakres szkoleń wymaganych, aby użytkownicy mogli skutecznie zrozumieć istotę projektu, są często niedoceniane. Oczywiście, na późniejszym etapie projektu szkolenia z obsługi nowego systemu i procesów są zbyt ograniczone i nieefektywne.
  3. Wpływ kulturowy i organizacyjny: Działy i interesariusze nie podzielają wspólnego celu i/lub wizji, co jest częstym problemem w wielu projektach. Co więcej, projekt nie jest zgodny ze strategicznymi celami firmy, a jej kierownictwo nie chce uznać jego znaczenia w tym obszarze (co prowadzi do drastycznego braku wsparcia), co jest głównym czynnikiem powodującym porażki i frustrację. A co więcej, w zarządzaniu zmianą: zmiana kulturowa wymagana do dostosowania się do nowych procesów i narzędzi jest niedoceniana lub wręcz ignorowana, co ponownie powoduje rozczarowanie i frustrację. Dwa inne ważne punkty, na które należy zwrócić uwagę: komunikacja i elastyczność. Kierownictwo dostrzega presję projektu (zmiany) na organizację dopiero zbyt późno, co wywołuje panikę, która zmniejsza chęć do elastyczności, kreatywności i otwartości na zmiany w projekcie. Zauważamy również, że im trudniejsza sytuacja, tym bardziej komunikacja z organizacją ulega osłabieniu i jest zapominana.
  4. Reengineering procesów: Jak podkreślono wcześniej w tym artykule, dokładne zrozumienie i udokumentowanie obecnych procesów przed zaprojektowaniem nowych procesów lub przejściem na nowy system ERP jest znacznie bardziej złożone i czasochłonne, niż się spodziewano lub na co organizacje są gotowe (w co) inwestować. Dostosowanie pożądanych procesów biznesowych do standardowych procesów systemu ERP bez konieczności przeprowadzania intensywnych dostosowań może być trudne i frustrować lub demotywować zespół projektowy.

Czy to jedyne powody frustracji i problemów z projektem? Warto zauważyć, że migracja danych jest często wymieniana jako wyzwanie dla projektu. Chociaż w niektórych projektach powoduje opóźnienia i dodatkowe koszty, migracja danych prawie nigdy nie jest powodem rozczarowania lub niezadowolenia z tego, co projekt wniósł do organizacji (doświadczonej wartości). Ponadto trudności z rozwojem dostosowań i integracji mogą powodować, a wręcz prawie powodować, dodatkowy czas i koszty. Nigdy jednak nie są one powodem, dla którego po uruchomieniu ludzie mają wrażenie, że nie wszystko, czego oczekiwano lub co jest wymagane, zostało dostarczone. Powiedziałbym nawet, że jest odwrotnie: jedyne, co naprawdę mierzy się i kontroluje, to dostarczanie oprogramowania. Funkcjonalność aplikacji, migracja, dostosowania, integracje, raporty itd. to w zasadzie „łatwe rzeczy” do zarządzania.

A gdy oceny projektów wykazują, że testowanie lub wsparcie powdrożeniowe stanowią wyzwania, powiedziałbym, że wiąże się to raczej ze słabym zarządzaniem projektem i/lub brakiem motywacji organizacji do przydzielenia odpowiedniej liczby osób oraz uznania znaczenia i wpływu projektu, o którym wspomniano wcześniej.

Uważam, że powody wskazane powyżej są przyczynami niepowodzenia projektu i wymagają od nas ponownego przemyślenia stosowanej przez nas metodologii oraz zastanowienia się nad zasobami i umiejętnościami, jakich potrzebujemy, aby skutecznie zarządzać projektem ERP i realizować go.

Należy wspomnieć, że zwinna lub alternatywna metodologia wdrażania projektu ma większe szanse na powodzenie niż podejście kaskadowe ze względu na elastyczność i możliwość adaptacji, zaangażowanie użytkowników, ograniczanie ryzyka i usprawnioną komunikację.

Warto również wspomnieć, że moim zdaniem, po początkowym, trudnym projekcie wdrożenia systemu ERP, projekty ciągłego doskonalenia będą miały znacznie większe szanse na powodzenie, a organizacje odniosą z nich znacznie większe korzyści, oczywiście tylko wtedy, gdy będą one nadal dopuszczać te projekty i uczynią „apetyt na zmiany” podstawową wartością organizacji. W tym kontekście należy podkreślić, że systemy chmurowe mają tę zaletę, że są najlepszym narzędziem do ciągłego doskonalenia.

Chciałbym, aby niniejszy dokument posłużył jako dokument do dyskusji i początek dyskusji w p2-i oraz wśród partnerów i klientów, co pomoże nam udoskonalić naszą organizację i nasze usługi w zakresie:

  1. Ustal właściwą metodologię
  2. Zorganizujmy naszą funkcję PM
  3. Zatrudnij ludzi, których potrzebujemy do wykonania zadania zgodnie z metodologią
  4. Szkolenie i ciągłe szkolenie naszych pracowników, aby mogli odnieść sukces w naszej metodologii
  5. Szkolenie i organizacja grupy sprzedażowej w celu umożliwienia sprzedaży naszych projektów
  6. Realizuj projekty z sukcesem

Chętnie poznam Twoje komentarze i opinie!

 

Napisane przez Amita Kumara

9 grudnia 2024 r.