Jak AI może analizować harmonogram w MS Project i Primavera P6 i wykrywać zagrożenia dla terminu?

Tak, AI można podłączyć do harmonogramu w MS Project i Primavera P6 i co tydzień dostawać gotowy raport po polsku: które zadania się przesunęły względem planu bazowego, które leżą na ścieżce krytycznej i co realnie zagraża terminowi końcowemu. Raport trafia na skrzynkę project managera w poniedziałek rano, przed naradą, razem z listą pytań wyprowadzonych wprost z danych. Nie kolejny widok Ganttta, tylko tekst, który można przeczytać i przekazać dalej.

Co siedzi w tych programach i po co AI sięga do środka

Zanim wiadomo, jak podłączyć AI, trzeba wiedzieć, po które dane właściwie sięga. Oba programy przechowują harmonogram w podobnych kategoriach, choć używają innych nazw pól.

W MS Project każde zadanie (Task) ma pola: Nazwa (Name), Czas trwania (Duration), Początek (Start), Koniec (Finish), Poprzednicy (Predecessors), Procent ukończenia (% Complete) i Zasoby (Resource Names). Gdy zapisujesz plan bazowy (baseline), program dopisuje do każdego zadania trzy dodatkowe pola: Bazowy początek (Baseline Start), Bazowy koniec (Baseline Finish) i Bazowy czas trwania (Baseline Duration). To jest punkt odniesienia. Każda aktualizacja tworzy różnicę między tym, co było zaplanowane, a tym, co jest teraz. Zadania na ścieżce krytycznej MS Project oznacza czerwonym paskiem w widoku Gantt, a w kolumnie Łączny luz (Total Slack) mają wartość 0 lub ujemną.

W Primavera P6 czynności (Activity) mają podobny zestaw: Activity ID, Pierwotny czas trwania (Original Duration), Pozostały czas trwania (Remaining Duration), Łączny luz (Total Float), Bazowy start i koniec projektu (BL Project Start, BL Project Finish). Zasoby dostają pola Budgeted Units, Remaining Units i Actual Units, z których widać, kto jest przeciążony i o ile.

AI potrzebuje dokładnie tych kolumn. Nie potrzebuje całego środowiska programu, widoków, formatowania ani komentarzy w polach tekstowych. Liczy się surowa tabela: zadanie, plan bazowy, rzeczywistość, luz, zasób. Z tej tabeli wyciągnie więcej niż project manager przeglądający harmonogram wiersz po wierszu przed spotkaniem.

Jak fizycznie AI sięga po dane: API, eksport i baza danych

To jest pytanie, które pada przy każdym wdrożeniu. Program ma API czy nie? Co z tym zrobić?

MS Project Online i Project Server (wersja chmurowa Microsoft 365 i serwerowa on-premise) udostępniają dane przez OData REST API. Endpoint wygląda mniej więcej tak: https://[tenant].sharepoint.com/sites/[pwa]/_api/ProjectData/ i zwraca aktualny stan harmonogramu jako JSON. Potrzeba do tego konta z uprawnieniem do odczytu projektu i tokenu OAuth z Azure Active Directory. To oficjalnie udokumentowane API producenta, skrypt odpytuje je cyklicznie bez żadnej ingerencji człowieka.

MS Project Desktop (wersja .mpp instalowana lokalnie) nie ma API. Plik .mpp to zamknięty format binarny i AI nie otworzy go bezpośrednio. Są trzy legalne drogi: eksport do XML (Plik / Zapisz jako / XML), eksport do Excela (Plik / Eksportuj) albo eksport do CSV. XML z MS Project zawiera pełną strukturę harmonogramu ze wszystkimi polami łącznie z bazowym. Skrypt uruchamiany co poniedziałek rano może odebrać ten plik z folderu udostępnionego lub SharePointa i przekazać dane AI. Wystarczy jeden nawyk: przed naradą zapisujesz XML.

Primavera P6 EPPM (wersja serwerowa, Oracle) ma REST API dostępne przez P6 Integration API od wersji 20.12. Jest też starszy SOAP Web Service dla tych, którzy mają starsze środowisko. Autoryzacja przez sesję (login i hasło) albo token. Wymaga konta z rolą co najmniej Project Viewer lub odpowiednich uprawnień w Global Security Profile. Bez tej licencji API jest niedostępne, nawet dla kont administratorskich.

Primavera P6 Professional (wersja desktopowa) nie udostępnia API bezpośrednio. Eksport XER to plik tekstowy z tabelami TASK, TASKRSRC, PROJWBS i kilkoma innymi, który spokojnie parsuje skrypt Pythona. Drugi format to P6 XML. Jeśli P6 Professional siedzi na bazie Oracle albo MS SQL Server, skrypt z odpowiednimi uprawnieniami może odpytać bazę bezpośrednio. To wymaga koordynacji z administratorem bazy i decyzji firmy o dostępie.

Typowo u klienta wygląda to tak: wersja serwerowa P6 EPPM lub Project Online pozwala na w pełni automatyczne pobieranie danych bez udziału człowieka. Wersja desktopowa wymaga jednego kroku: ktoś przed naradą klika eksport. To drobna zmiana przyzwyczajeń, ale project manager i tak otwierał program przed spotkaniem.

Co AI wyciąga: odchylenia, ścieżka krytyczna, przeciążone zasoby

Gdy skrypt pobierze dane, AI dostaje tabelę, z której może wyciągnąć trzy klasy informacji.

Odchylenia od planu bazowego. To porównanie Baseline Start z aktualnym Start i Baseline Finish z aktualnym Finish dla każdego zadania. Zadanie, które miało zacząć się 3 maja, a zaczęło 12 maja, ma odchylenie startu o dziewięć dni roboczych. AI nie tylko to wylicza: sprawdza przy okazji, czy dane zadanie ma luz w harmonogramie. Przesunięcie zadania z luzem nie zmienia daty końcowej projektu. Przesunięcie zadania z luzem równym zero to zupełnie inna rozmowa.

Zadania na ścieżce krytycznej. AI filtruje zadania z Total Slack równym zero lub ujemnym, kiedy projekt jest już za planem. Następnie sprawdza ich Procent ukończenia i Remaining Duration. Zadanie krytyczne z % Complete = 15 i Remaining Duration = 45 dni, podczas gdy do końca projektu zostało 30 dni, to konkretny alarm. Nie "coś poszło nie tak", tylko: "to zadanie wysunie datę oddania o co najmniej 15 dni, jeśli nic się nie zmieni".

Przeciążone zasoby. W MS Project widok Resource Sheet pokazuje kolumnę Peak: jeśli przekracza Max Units, zasób jest przeciążony. W P6 porównujemy Remaining Units do dostępności zasobu w danym oknie czasowym. AI sortuje listę zasobów od najbardziej do najmniej przeciążonych i wskazuje, w którym tygodniu przeciążenie osiąga szczyt, bo to właśnie wtedy zatrzyma pracę na kilku zadaniach naraz.

U klienta z branży budowlanej wykryliśmy, że kierownik robót elektrycznych był przypisany do trzech zadań krytycznych w tym samym tygodniu. Jego Peak w MS Project wynosił 180%, Max Units był ustawiony na 100%. Każdy z trzech kierowników projektu widział to w swoim pliku, ale nikt nie zestawił wszystkich planów razem. AI zestawiło to w jednym zdaniu i trafiło na naradę, zanim problem zdążył być problemem.

Cotygodniowy raport po polsku i pytania, które warto zadać na naradzie

To część, którą project managerowie cenią najbardziej. Nie kolejny widok danych, ale tekst, który można przeczytać, podpisać i przekazać zarządowi albo inwestorowi.

Raport, który generujemy co poniedziałek, zawiera zazwyczaj kilka sekcji:

• Podsumowanie tygodnia: ile zadań zaplanowanych na ubiegły tydzień zostało ukończonych, ile się przesunęło i o ile dni.
• Zadania zagrażające terminowi końcowemu: lista zadań na ścieżce krytycznej, które mają % Complete poniżej oczekiwanego, z podaniem, o ile dni przesuną projekt, jeśli nic się nie zmieni.
• Zasoby wymagające uwagi: kto jest przeciążony, w którym tygodniu przeciążenie spada i na których zadaniach krytycznych to odbija.
• Kamienie milowe w horyzoncie trzech tygodni: co ma zostać ukończone i jaki jest obecny status zadań wiodących do tych kamieni.

Do raportu dołącza lista pytań na naradę. Nie ogólnych, tylko wyprowadzonych z danych. Jeśli zadanie "Odbiór instalacji sanitarnej" na ścieżce krytycznej ma % Complete = 40 przy planowanym 75, AI sformułuje: "Co wstrzymuje odbiór instalacji sanitarnej? Czy inspektor nadzoru potwierdził termin wizyty?" Takich pytań nie trzeba wymyślać w pośpiechu przed spotkaniem. Są gotowe rano, przed kawą.

Format raportu można dostosować: mail na skrzynkę, PDF, plik w folderze projektu na SharePoincie, wpis do systemu zarządzania projektami. Treść ta sama, kanał dowolny.

Gdzie AI realnie pomaga, a gdzie harmonogramem trzeba zarządzać samemu

AI czyta stan i wyciąga wnioski. Nie przesuwa za Ciebie dat, nie negocjuje z podwykonawcami i nie decyduje, jak podzielić zasoby. To zostaje po stronie project managera.

Są miejsca, gdzie AI realnie skraca pracę:

• Raport statusowy na potrzeby zarządu lub inwestora: AI pisze go zwykłym językiem, bez technicznego żargonu, na podstawie tych samych danych z harmonogramu.
• Śledzenie trendu: czy projekt przyspiesza czy spowalnia w porównaniu do poprzednich tygodni. To wymaga archiwum cotygodniowych eksportów, ale skrypt może je budować automatycznie.
• Alerty między naradami: gdy zadanie krytyczne nie zostało zaktualizowane od tygodnia, AI wysyła przypomnienie do odpowiedzialnej osoby, zanim problem wyjdzie na narادzie.
• Porównanie planów kilku projektów naraz, gdy te same zasoby pracują w więcej niż jednym harmonogramie.

Czego AI nie zastąpi: oceny, czy deklarowany % Complete jest wiarygodny. Jeśli kierownik robót wpisuje 80% ukończenia, bo tak wygląda na budowie, a faktycznie roboty do wykonania zajmą jeszcze trzy tygodnie, AI tego nie wykryje. Jakość raportu zależy wprost od jakości aktualizacji harmonogramu. To nie wada systemu, to po prostu prawda o każdym narzędziu opartym na danych.

Od czego zaczyna się wdrożenie: cztery pytania przed pierwszą linią kodu

Zanim napiszemy cokolwiek, sprawdzamy cztery rzeczy:

• Która wersja programu jest w firmie: desktopowa czy serwerowa? To determinuje sposób pobierania danych i czy potrzebny jest cykliczny eksport, czy pełna automatyzacja przez API.
• Czy harmonogram ma zapisany plan bazowy? Bez niego nie ma odchyleń. W MS Project sprawdzamy, czy pola Baseline Start są wypełnione. W P6 czy projekt ma ustawiony BL Project. Zdarza się, że harmonogram jest prowadzony od miesięcy, ale baseline nigdy nie był zapisany. Wtedy zaczynamy od tej jednej czynności w programie.
• Kto i jak często aktualizuje % Complete oraz Remaining Duration? Jeśli harmonogram jest odświeżany raz na dwa tygodnie, raport cotygodniowy będzie powtarzał te same dane.
• Gdzie ma trafiać raport: mail, Teams, folder na SharePoincie, inny system zarządzania projektami?

Gdy mamy odpowiedzi, budujemy skrypt pobierający dane (Python z biblioteką do parsowania XML i XER albo z zapytaniami do API), instrukcję dla AI opisującą format raportu i logikę alarmową, oraz harmonogram uruchamiania, np. co poniedziałek o godzinie 6:00. Pierwsze uruchomienie z prawdziwymi danymi zajmuje zwykle pół dnia roboczego. Potem system pracuje sam.

Chcecie zobaczyć, jak taki raport wyglądałby na Waszym harmonogramie? Zarezerwujcie 15 minut rozmowy i pokażemy to na przykładzie. Jeśli szukacie konkretnych realizacji, sprawdźcie realne wdrożenia.