Jak AI czyta dane z PlanRadar i Archdesk i co robi z usterkami, terminami i protokołem odbioru?

AI połączone z PlanRadar i Archdesk może codziennie zestawiać otwarte usterki, wyłapywać te po terminie, sygnalizować zadania bez przypisanego wykonawcy i przygotowywać projekt protokołu odbioru do przejrzenia przez kierownika. Nie trzeba do tego logować się do obu systemów osobno ani przeklejać danych do Excela. Dane są w systemach, API je udostępnia, a AI robi z nich konkretny komunikat lub dokument.

Co siedzi w PlanRadar i Archdesk, co warto wyciągnąć

PlanRadar trzyma zgłoszenia usterek jako tickety. Każdy ticket ma: numer, tytuł, opis, status (New, In Progress, Done, Closed), priorytet (Low, Medium, High, Critical), Due Date, Assigned To (firma albo konkretna osoba), lokalizację na rzucie piętra i listę załączonych zdjęć. Do każdego ticketu dochodzą komentarze i pełna historia zmian statusu. Poza ticketami PlanRadar przechowuje formularze inspekcji, wpisy dziennika budowy i raporty zbiorcze.

Archdesk to inna warstwa tego samego placu budowy. Tam siedzi harmonogram etapów z polami Start Date i End Date, zadania z polem Assignee, dokumenty: specyfikacje, rysunki, RFI (Request for Information), raporty z wizyt na budowie (Site Visit) i lista podwykonawców przypisanych do etapów. Kosztorysy i zmiany zakresu też tam trafiają.

Razem te dwa systemy dają pełny obraz: co jest do poprawienia i jakie zdjęcia to dokumentują (PlanRadar) oraz kto, kiedy i za ile ma to wykonać (Archdesk). Problem polega na tym, że oba systemy trzeba przeglądać osobno, a informacje się nie sumują automatycznie. Właśnie tę lukę wypełnia AI.

Codzienny raport usterek: jak to działa w praktyce

Typowe połączenie, które wdrażamy, działa tak: każdego ranka o ustalonej godzinie AI pobiera przez API PlanRadar wszystkie tickety, gdzie Status != Closed i Due Date jest w przeszłości lub dzisiaj. Grupuje je po polu Assigned To, czyli po wykonawcy lub podwykonawcy. Dla każdej grupy liczy, ile dni minęło od terminu.

Z Archdesk dociąga aktualny status podzleceń przypisanych do tych samych firm. Jeśli podwykonawca ma zablokowane płatności albo jego etap jest oznaczony jako wstrzymany, to informacja o tym pojawia się obok listy jego zaległych ticketów.

Zestawienie trafia mailem do kierownika projektu albo do kanału Teams. Nie ma w nim ogólnych komentarzy. Jest lista: numer ticketu, opis usterki, ile dni po terminie, kto odpowiada. U jednego z klientów zarządzających czterema budowami jednocześnie, ten raport zastąpił poranne sprawdzanie trzech paneli w różnych systemach. Wcześniej zajmowało to godzinę i i tak coś umykało. Teraz raport jest o 7:00, przegląd trwa 10 minut.

Zadania bez wykonawcy: cichy problem, który AI wyłapuje

W Archdesk każde zadanie ma pole Assignee. W PlanRadar każdy ticket ma pole Assigned To. Oba regularnie stoją puste, bo ktoś wrzucił zadanie szybko, bez przypisania. Nikt nie pilnuje listy, bo jest za długa.

AI przegląda oba systemy raz dziennie. Wyciąga wszystkie rekordy, gdzie pole odpowiedzialne za wykonawcę jest puste, a termin realizacji wpada w najbliższe siedem dni. Lista trafia do kierownika projektu z jednym pytaniem: kto to robi?

To brzmi jak drobiazg. Ale na budowie, gdzie w ciągu tygodnia przybywa kilkanaście nowych ticketów i kilka nowych zadań w Archdesk, taka lista potrafi zebrać kilkadziesiąt pozycji w ciągu miesiąca. Bez automatycznego filtra przepadają.

Jak AI przygotowuje projekt protokołu odbioru

Protokół odbioru robót zbiera wykonane prace, zamknięte usterki i uwagi do odbioru. Dane do niego leżą w PlanRadar i Archdesk, ale zebranie ich ręcznie zajmuje godziny.

AI pobiera z PlanRadar wszystkie tickety ze statusem Closed albo Done zamknięte w danym przedziale czasu: ostatni etap, ostatni miesiąc albo wskazany zakres dat. Dla każdego ticketu wyciąga: numer zgłoszenia, opis usterki, datę otwarcia, datę zamknięcia, kto zamknął, ile zdjęć potwierdzających dołączono. Z Archdesk dociąga listę etapów budowy i przypisane dokumenty, w tym raporty z wizyt na budowie (Site Visit).

Z tych danych AI generuje wypełniony szkielet protokołu. Nie jest to dokument gotowy do podpisania. To ważna różnica. Kierownik albo inspektor nadzoru musi go przejrzeć, uzupełnić o ocenę jakościową i własne uwagi, a potem podpisać. Ale zamiast zaczynać od pustego Worda i szukać po systemach przez dwie godziny, zaczyna od dokumentu wypełnionego w 80%. Wzorzec protokołu ustawiamy raz pod wymagania inwestora, potem AI go wypełnia przy każdym odbiorze etapowym.

Streszczenie stanu budowy dla kogoś, kto nie jest cały dzień w systemie

Kierownik budowy wie, co się dzieje. Problem mają prezes nadzorujący kilka projektów jednocześnie albo inwestor, który chce wiedzieć co słychać bez dzwonienia. Dla nich AI generuje streszczenie.

W punktach, bez owijania w bawełnę:

• Ile ticketów otwarto w ostatnich 7 dniach i jakie mają priorytety
• Ile ticketów jest po terminie i do których wykonawców należą
• Jakie etapy z Archdesk zbliżają się do daty zakończenia w ciągu 14 dni
• Czy są zadania bez Assignee z terminem w bieżącym tygodniu
• Czy pojawiły się nowe wpisy w dzienniku budowy lub raporty Site Visit
• Czy któryś ticket z priorytetem Critical czeka na zamknięcie ponad 48 godzin

Żadnego "projekt postępuje zgodnie z planem" bez pokrycia w danych. Jeśli coś jest nie tak, streszczenie to pokazuje wprost. Jeśli wszystko gra, mówi: otwarte 3 tickety, wszystkie w terminie, żadnych zadań bez przypisania. I tyle.

Co z metadanymi zdjęć z budowy

Każdy ticket w PlanRadar może mieć kilka zdjęć. AI przez API pobiera metadane: kiedy zdjęcie dodano, przez kogo, do którego ticketu należy i czy ten ticket jest zamknięty czy wciąż otwarty. To pozwala sprawdzić, czy dla usterek przeterminowanych ktokolwiek był na miejscu i dodał dokumentację fotograficzną. Brak zdjęcia przy usterki, która wisi od dwóch tygodni, to osobny sygnał w raporcie.

Analiza treści zdjęcia, czyli to, co na nim faktycznie widać, wymaga modelu multimodalnego. To technicznie możliwe i ma sens przy odbiorach jakościowych, ale to bardziej zaawansowany krok. Na start wystarczy meta-analiza: czy zdjęcie jest, kiedy dodane, przez kogo, czy ticket, do którego należy, zmienił status po jego dodaniu.

Od czego zaczynamy połączenie z tymi systemami

Krok pierwszy: dostęp do API. PlanRadar udostępnia REST API z tokenem Bearer, Archdesk podobnie. Ktoś z firmy musi wygenerować klucze i wskazać, które projekty wchodzą do automatu. Nie ma sensu ciągnąć danych ze wszystkich projektów z ostatnich pięciu lat, zawężamy do aktywnych budów.

Krok drugi: decyzja, co się dzieje i kiedy. Codzienny raport o 7:00 rano? Alert w czasie rzeczywistym przy każdym nowym tickecie z priorytetem Critical, przez webhook PlanRadar? Projekt protokołu odbioru na żądanie, gdy kierownik wpisze komendę w czacie? Każdy z tych trybów konfigurujemy inaczej.

Krok trzeci: format wyjścia. Mail, wiadomość Teams, plik DOCX w folderze projektu, wpis w Archdesk jako komentarz do zadania. Zazwyczaj zaczynamy od maila, bo działa wszędzie bez dodatkowej integracji.

Pilot trwa kilka tygodni na jednym projekcie. Sprawdzamy wtedy, czy dane w systemach mają wystarczającą jakość. Jeśli 40% ticketów nie ma ustawionego Due Date, to automat pilnujący terminów nie da sensu, dopóki firma nie poprawi nawyków przy tworzeniu zgłoszeń. To też wychodzimy na pilocie, zanim skalujemy na resztę projektów.

Jeśli Twoja firma korzysta z PlanRadar albo Archdesk i chcesz zobaczyć, co realnie można z tym zrobić, zajrzyj do naszych realnych wdrożeń albo umów się na bezpłatny audyt. Pokażemy, które dane w Twoim systemie są gotowe od razu, a co trzeba najpierw uporządkować po stronie procesów.