Poprzedni styl zarządzania i narzędzia

Projekty były zarządzane w Redmine, który został nieco ulepszony przez klienta z kilkoma przydatnymi modyfikacjami. Inne działy firmy używają Microsoft Dynamics NAV do organizowania pracy i utrzymywania tam danych, systemy (Redmine i NAV) zostały połączone, aby umożliwić i zautomatyzować komunikację między działami.

Technicznie działało to w następujący sposób: Po utworzeniu i zdefiniowaniu nowego projektu w NAV istniała opcja przeniesienia tych danych do Redmine, tworząc w ten sposób nowy projekt z pewnymi atrybutami.

Redmine stał się przydatnym narzędziem, które pomagało w organizacji pracy w tej firmie. Projekty, nad którymi pracują modele JIRI, są bardzo podobne, a struktura projektu w Redmine była prosta. Projekty były dzielone na 4 lub 5 zadań i były identyczne lub podobne dla każdego projektu. Zadanie było przekazywane między wieloma cesjonariuszami w trakcie jego cyklu życia, w zależności od tego, czyja kolej miała wykonać działanie na części pracy zapakowanej w to zadanie. W ten sposób zadanie było zauważane i monitorowane tylko przez jego obecnego cesjonariusza. Do śledzenia zadań wykorzystano domyślny filtr „moich zadań” w osobistym pulpicie nawigacyjnym Redmine.

Mimo że system działał dobrze przez pewien czas, okazał się niewystarczający, aby nadążyć za nowatorskimi planami i strategiami zarządzania firmą. Strategie te zostały szczególnie skoncentrowane na zwiększeniu przejrzystości i jasności całego procesu, zdolności do przewidywania lub wykrywania przyczyn opóźnień w projekcie i adresowaniu odpowiedzialnych osób, a także na wdrażaniu skutecznego planowania zarządzania zasobami itp. Oczekiwane korzyściami byłby z pewnością szybszy i płynniejszy proces dostarczania oraz uzyskiwanie wiarygodnych danych w celu opracowania innych wewnętrznych narzędzi i mechanizmów zwiększających motywację i satysfakcję pracowników.

Przed rozpoczęciem wdrożenia menedżerowie modeli JIRI mieli już jasne pojęcie o nowym procesie, który zamierzali wdrożyć i jak powinien wyglądać przepływ pracy. Przede wszystkim skupiliśmy się na wdrożeniu tych procesów do systemu, tworząc strukturę zadań oraz dobrze definiując ich przepływ i uprawnienia, a także interfejs użytkownika dla każdej grupy użytkowników, aby mieć pewność, że odpowiednie informacje dotrą do właściwych osób w czas. Podczas wdrożenia współpracowaliśmy również z różnymi zewnętrznymi partnerami modeli JIRI, aby skonfigurować i poprawić połączenie między Easy Project a Microsoft Dynamics NAV. Wdrożenie wymagało dużo planowania i projektowania z góry. Wynika to z faktu, że cały proces produkcyjny przebiegał w Redmine, który miał zostać zastąpiony przez Easy Project zaraz po wdrożeniu, aby nie przerywać ciągłości danych. 

Szablony projektów i integracja API

Wszystkie projekty mają podobną strukturę. W przeciwieństwie do Redmine Easy Project umożliwia tworzenie szablonów projektów, które są używane jako podstawa do nowej konfiguracji projektu. W tym przypadku najbardziej znaczącą zaletą korzystania z szablonów jest możliwość zachowania struktury zadań, ich relacji i opisu każdego zadania. Nawiązaliśmy połączenie między łatwym projektem a Microsoft Dynamics NAV. Gdy w NAV tworzony jest nowy projekt, odpowiedni „typ projektu” jest wybierany w polu niestandardowym. Informacje te są wysyłane do Easy Project, który automatycznie wybiera szablon projektu dla nowej konfiguracji, dane z NAV są tam przesyłane.

Podstawowe funkcje Easy Project i osobiste pulpity nawigacyjne

Wykorzystaliśmy podstawowe funkcje, jakie oferuje Easy Project, i skonfigurowaliśmy różne typy zadań o różnym przepływie pracy. Oznacza to, że możliwe statusy dla zadania różnią się w zależności od rodzaju tego zadania. Ponadto sekwencja statusu jest zdefiniowana, aby pomóc użytkownikom zidentyfikować następny krok, a statusów można używać w różny sposób w zależności od roli użytkownika, ponieważ mają oni różne obowiązki. Statusy oraz moduły śledzące (typy zadań) zostały użyte do ustawienia osobistego pulpitu nawigacyjnego w celu filtrowania odpowiednich zadań dla każdego użytkownika. Na przykład, przełożony może monitorować status zadań do wykonania, aby osobno śledzić te zadania, w przypadku których potrzebna jest informacja zwrotna lub akceptacja z jego strony, aby zidentyfikować te, które się opóźniają itp.