Oprogramowanie Hadrone PPM posiada wbudowane, stałe przepływy prac (z ang. workflows) służące do weryfikacji i zatwierdzania projektu, akceptacji zmian w planie bazowym projektu, zlecania zadań projektowych, rozliczania i zamykania projektu, zatwierdzania budżetów wykorzystywanych do finansowania projektów oraz zatwierdzania planów dostępności kompetencji i ich stawek. Osoby posiadające określone uprawnienia w oprogramowaniu Hadrone PPM są informowane o konieczności podjęcia decyzji i w ramach oprogramowania mogą takie decyzje podejmować.
Po co więc integrować Hadrone PPM z zewnętrznym systemem workflow? Większe organizacje, które posiadają rozbudowane procesy decyzyjne, których przebieg bazuje na specyficznych atrybutach (np. wielkość budżetu, kategoria projektu i inne atrybuty), mają rozbudowane potrzeby kształtowania przepływów prac uwzględniając ich wymagania. W takich właśnie sytuacjach uzasadnione staje się wykonanie takiej integracji z wykorzystaniem dedykowanego systemu, który umożliwia elastyczne kształtowanie przepływów prac.
Jakie korzyści wynikają z zastosowania zewnętrznego systemu workflow?
Systemy workflow są powszechnie stosowane w organizacjach i często oczekiwane jest, że nowowdrażany system (taki jak PPM) będzie korzystał z technologii workflow, którą Klient już posiada i nie będzie wprowadzał kolejnego rozwiązania, które zajmuje się tym samym (czyli przepływami prac). Oprogramowanie Hadrone PPM zostało więc tak zbudowane, aby umożliwić integrację z systemami klasy workflow.
Posiadanie dedykowanego rozwiązania workflow zapewnia Klientowi wiele korzyści, do których należą w szczególności poniższe:
- Swobodne kształtowanie przepływów prac, z wykorzystaniem zaawansowanych i elastycznych funkcjonalności dedykowanych do zarządzania przepływami prac.
- Prowadzenie procesów akceptacji dot. obszaru projektów w tym samym systemie, w którym użytkownicy podejmują inne decyzje (jedno środowisko pracy dla użytkowników).
- Niezależność od dostawcy oprogramowania PPM w kształtowaniu przepływów prac, uwzględniając w szczególności zmiany organizacyjne i procesowe, które dzieją się na co dzień.
W jakich obszarach najczęściej wykonywana jest taka integracja?
Z naszych doświadczeń z wdrożeń oprogramowania Hadrone PPM wynika, że integracja z systemem workflow najczęściej odbywa się w poniższych obszarach:
- Weryfikacja i zatwierdzenie projektu.
- Weryfikacja i zatwierdzenie zmiany w planie bazowym projektu.
- Przejście do kolejnego etapu w projekcie.
- Rozliczenie i zamknięcie projektu.
Integracje realizowane przez poszczególnych Klientów często są specyficzne, dopasowane do potrzeb organizacji oraz możliwości i ograniczeń systemów IT. Poniżej opisujemy przykładową logikę takich integracji, w podziale na w/w obszary.
Przykład: Weryfikacja i zatwierdzenie projektu
Po zaplanowaniu projektu w Hadrone PPM Kierownik projektu wysyła projekt do weryfikacji. Wówczas Hadrone PPM wysyła webhooka, który może przechwycić system workflow i na jego podstawie uruchomić określony przepływ prac dot. weryfikacji i zatwierdzania projektu. Użytkownik nie musi więc przechodzić z Hadrone PPM do systemu workflow i ręcznie uruchamiać przepływ prac. Dzięki tej integracji przepływ zostanie uruchomiony automatycznie. Jeśli system workflow nie ma możliwości przechwytywania webhooks, to wówczas należy zastosować oprogramowanie pośredniczące między Hadrone PPM i systemem workflow (np. Apache Airflow), które odbierze webhooka wysłanego przez Hadrone PPM i uruchomi poprzez API odpowiedni przepływ prac w systemie workflow.
Teraz rozpoczyna się proces weryfikacji i finalnego zatwierdzania projektu. W zależności od charakterystyki projektu (kategoria, wartości klasyfikacji, wielkość budżetu etc.) ścieżka akceptacyjna będzie się różnić i właśnie tutaj swoją siłę pokazuje system workflow. Pozwala on bowiem elastycznie ustalić ścieżki decyzyjne. Dodatkowo w trakcie procesowania decyzji będzie się odbywać komunikacja między systemem workflow a Hadrone PPM, aby pobierać dodatkowe dane potrzebne z projektu w Hadrone PPM do podejmowania decyzji (żeby użytkownik nie musiał wpisywać ich ręcznie), a finalnie z wykorzystaniem API w Hadrone PPM zostanie odzwierciedlony efekt podjętej decyzji (np. zmiana statusu projektu na zatwierdzony oraz dodanie decyzji do rejestru decyzji w projekcie, wraz z linkiem do określonego przepływu prac). Różne osoby, które są angażowane w proces decyzyjny, nie muszą się przełączać między systemami – wszystkie kroki wykonują w znanym sobie środowisku workflow, a część z nich może nawet nie wiedzieć, że Hadrone PPM istnieje i nie musi się logować do Hadrone PPM.
Zatwierdzenie projektu może się wiązać z jeszcze jedną integracją – z systemem ERP. Po zatwierdzeniu projektu w systemie ERP może zostać automatycznie założony odpowiedni obiekt (np. MPK, element PSP, zlecenie kontrolingowe), który umożliwi późniejsze ewidencjonowanie ponoszonych wydatków w kontekście określonych projektów. Opis integracji Hadrone PPM z systemem ERP w zakresie budżetu znajduje się w artykule „Integracja Hadrone PPM z systemem ERP (budżet projektu)”.
Przykład: Weryfikacja i zatwierdzenie zmiany w planie bazowym projektu
Weryfikacja i zatwierdzenie zmiany w planie bazowym najczęściej odbywa się bardzo podobnie do weryfikacji i zatwierdzania samego projektu.
Kierownik projektu tworzy w projekcie w Hadrone PPM wniosek o zmianę, wybierając zakres zmian, jakie chce wprowadzić w planie bazowym projektu i wysyła wniosek do akceptacji. Wówczas Hadrone PPM wysyła webhooka, który może przechwycić system workflow i na jego podstawie uruchomić określony przepływ prac dot. weryfikacji i zatwierdzenia w planie bazowym projektu. Jeśli system workflow nie ma możliwości przechwytywania webhooks, to analogicznie jak w wyżej opisanym przykładzie dot. zatwierdzania projektu należy zastosować oprogramowanie pośredniczące między Hadrone PPM i systemem workflow (np. Apache Airflow), które obsłuży tę komunikację.
Proces weryfikacji i finalnego zatwierdzania zmiany w planie bazowym projektu może mieć różny przebieg, analogicznie jak zatwierdzanie projektu. Proces ten może być elastycznie kształtowany w systemie workflow. W trakcie procesowania wniosku o zmianę będzie się odbywać komunikacja między systemem workflow a Hadrone PPM, aby pobierać dodatkowe dane z projektu w Hadrone PPM potrzebne do podejmowania decyzji, a finalnie w Hadrone PPM zostanie odzwierciedlony efekt podjętej decyzji (np. zatwierdzona lub odrzucona zmiana w planie bazowym oraz dodanie decyzji dot. tego wniosku do rejestru decyzji w projekcie, wraz z linkiem do określonego przepływu prac). Podobnie jak wcześniej różne osoby, które są angażowane w proces decyzyjny nie muszą się przełączać między systemami – wszystkie kroki wykonują w znanym sobie środowisku workflow, bez konieczności przełączania się do innego systemu (w tym przypadku Hadrone PPM).
Przykład: Przejście do kolejnego etapu w projekcie
Hadrone PPM umożliwia tworzenie różnych schematów etapów, dopasowanych do projektów określonego typu, z własnymi etapami. Przykładowo schemat etapów dla projektu IT może obejmować inne etapy, niż schemat etapów dla projektu inwestycyjnego czy remontowego. Etapy mogą być zmieniane w projekcie ręcznie przez Kierownika projektu lub automatycznie przez zewnętrzny system workflow. To drugie rozwiązanie jest stosowane wówczas, gdy do przejścia do kolejnego etapu wymagane jest uzyskanie odpowiednich zgód w ramach procesu decyzyjnego.
Kroki akceptacyjne mogą się różnić w przypadku różnych typów projektów (które mają różne etapy) – system workflow pozwala na przygotowanie dedykowanych przepływów prac do kontrolowanego przejścia między różnymi etapami w różnych schematach etapów, aby dopasować się do wymagań danej organizacji. Komunikacja między systemem workflow a oprogramowaniem Hadrone PPM odbywa się z wykorzystaniem API Hadrone PPM.
Przykład: Rozliczenie i zamknięcie projektu
W niektórych organizacjach po zakończeniu realizacji projektu nie jest on od razu zamykany, ale przechodzi do rozliczenia i formalnego zamknięcia. W trakcie rozliczania spływają jeszcze faktury i wykonywane są inne wymagane przez organizacje czynności (np. utworzenie środków trwałych, przygotowanie raportu zamknięcia projektu etc.). Finalnie, po zrealizowaniu wszystkich wymaganych kroków, projekt jest zamykany.
Proces rozliczania i zamykania projektu też może być złożony i może wymagać wykorzystania odpowiednich przepływów prac. W takiej sytuacji, gdy Kierownik projektu wyśle projekt do rozliczenia, to Hadrone PPM wyśle webhooka, który może przechwycić system workflow i na jego podstawie uruchomić określony przepływ prac dot. rozliczenia i zamknięcia projektu. Jeśli system workflow nie ma możliwości przechwytywania webhooks, to analogicznie jak w wyżej opisanych przykładach należy zastosować oprogramowanie pośredniczące między Hadrone PPM i systemem workflow (np. Apache Airflow), które obsłuży tę komunikację. Po wykonaniu wszystkich wymaganych czynności system workflow z wykorzystaniem naszego API zamknie projekt w Hadrone PPM.
Kto wykonuje i utrzymuje integrację systemu workflow i Hadrone PPM?
Integrację systemu workflow z oprogramowaniem Hadrone PPM najczęściej wykonuje wewnętrzny zespół zajmujący się zarządzaniem przepływami prac w systemie workflow (lub partner zewnętrzny, któremu powierzono te zadania). Taki zespół przygotowuje przepływy prac na potrzeby różnych obszarów organizacji i różnych procesów, a obszar PPM jest tylko jednym z nich. Naszą rolą jest wówczas wsparcie tego zespołu w zakresie metod komunikacji z Hadrone PPM (czyli wykorzystanie odpowiednich webhooks i metod REST API). Dzięki temu Klient ma dużą elastyczność w inicjalnym kształtowaniu i późniejszym wprowadzaniu zmian do przepływów prac, wraz ze zmieniającymi się potrzebami organizacji, bez konieczności angażowania dostawcy systemu PPM.
Klient może również zlecić nam wykonanie takiej integracji. Wówczas dobieramy partnera technicznego, który zna oprogramowanie Hadrone PPM oraz system workflow wykorzystywany przez Klienta.
Warto pamiętać, że integracja między systemami to nie jest jednorazowe wydarzenie. Integracje wymagają prac utrzymaniowych, które obejmują:
- monitorowanie poprawności funkcjonowania integracji,
- reagowanie na błędy występujące w procesach integracyjnych,
- modyfikacje reguł i zakresu integracji wynikające ze zmian wprowadzanych w organizacji i w systemach, które zostały zintegrowane.
W zależności od potrzeb Klienta za utrzymanie integracji może odpowiadać zespół wewnętrzny lub dostawca zewnętrzny.
