Aplikacja do snaggingu - jak usprawnić odbiory i zarządzanie usterkami?

Aplikacja do snaggingu służy do wyłapywania, opisywania i rozliczania usterek przy odbiorach budynków i lokali. Brzmi skromnie. W praktyce to narzędzie, od którego zależy, czy odbiór czterdziestu mieszkań zajmie kilka spokojnych tygodni, czy zamieni się w miesiące wymiany maili, telefonów i zdjęć, których nikt nie potrafi przypisać do konkretnego pokoju. Snagging (od angielskiego „snag", czyli drobna usterka) to cały proces: przegląd, spisanie niedoróbek, przekazanie ich wykonawcom, sprawdzenie poprawek i zamknięcie sprawy. Każdy generalny wykonawca i każdy deweloper go prowadzi, tylko różnymi metodami. Część firm pracuje na wydrukowanych rzutach i długopisie, część na arkuszach, część na zdjęciach wrzucanych do grupy w komunikatorze. Kłopot pojawia się zawsze w tym samym miejscu: między zauważeniem usterki a potwierdzeniem, że naprawdę została usunięta.

Jako software house budujemy aplikacje terenowe i systemy dla firm budowlanych i deweloperów. Poniżej opisujemy, jak powinno działać narzędzie do odbiorów, na co zwracać uwagę przy wyborze albo projektowaniu go i gdzie zwykle ukrywają się problemy, których nie widać na prezentacji dostawcy.

Czym jest snagging i dlaczego usterki potrafią ciągnąć się miesiącami

Odbiorów w życiu inwestycji jest kilka. Wewnętrzne przeglądy kierownika budowy przed zgłoszeniem lokalu do odbioru, odbiór techniczny z inwestorem, odbiór lokalu z klientem, a potem zgłoszenia w okresie gwarancji. Każdy z nich produkuje listę usterek, w branży nazywaną snag listą. Pojedyncza pozycja jest zwykle banalna: rysa na parapecie, nierówno osadzone drzwi, brak silikonu przy wannie. Problemem nie jest pojedyncza rysa, tylko skala. Budynek z kilkudziesięcioma lokalami łatwo generuje kilkaset pozycji, rozrzuconych między kilkunastu podwykonawców. Każda ma swój termin, swoje zdjęcie i swoją historię. Dopóki lista żyje w kilku miejscach naraz, nikt nie ma pewności, która wersja jest aktualna.

Do tego dochodzi klient. Kupujący mieszkanie ocenia dewelopera w dużej mierze po odbiorze i po tym, jak szybko znikają zgłoszone przez niego usterki. Na spotkaniu słyszy, że wszystko zostało zapisane. Trzy tygodnie później dzwoni z pytaniem, czy ktoś w ogóle przyjdzie naprawić drzwi.

Jak wygląda odbiór bez systemu

Typowy scenariusz wygląda mniej więcej tak. Inspektor chodzi po lokalu z wydrukiem rzutu i notesem, robi zdjęcia telefonem, a wieczorem przepisuje notatki do arkusza. Zdjęcia trafiają do folderu nazwanego numerem mieszkania. Albo nie trafiają, bo wśród dwustu ujęć z dnia trudno ustalić, które przedstawia łazienkę w lokalu 14, a które w 41. Następnego dnia ktoś z biura rozsyła arkusz do podwykonawców. Każdy dostaje całość i sam szuka swoich pozycji. Część odpowiada mailem, część telefonicznie, część wcale. Informacja o naprawie wraca do kierownika w formie „zrobione", bez zdjęcia i bez daty. Przy ponownym odbiorze okazuje się, że połowa pozycji nadal jest otwarta, a nikt nie wie, czy ktoś tam w ogóle był.

Każdy z tych kroków da się zrobić dobrze na papierze. Tylko że wymaga to dyscypliny od kilkunastu osób z różnych firm jednocześnie. Tego nie da się utrzymać przy kilku inwestycjach prowadzonych równolegle.

Co powinna umieć aplikacja do snaggingu?

Rdzeń jest prosty: usterka jako rekord z lokalizacją, zdjęciem, opisem, kategorią, osobą odpowiedzialną, terminem i statusem. Wiele elementów przypomina narzędzia, z których korzysta serwis terenowy w aplikacji mobilnej, ale budowa ma swoją specyfikę. Liczą się szczegóły.

Usterka przypięta do rzutu

Najważniejsza funkcja to możliwość wbicia pinezki w konkretne miejsce na rzucie lokalu lub kondygnacji. Opis „ściana w kuchni" ma kilka możliwych interpretacji. Pinezka nie ma żadnej. Podwykonawca, który przychodzi po raz pierwszy do lokalu, od razu widzi, gdzie szukać problemu. Rzuty trzeba wcześniej wgrać i uporządkować według inwestycji, budynku, klatki i lokalu. To praca, która wykonuje się raz na etap inwestycji, a oszczędza czas przy każdym odbiorze. W bardziej zaawansowanych projektach lokalizacja usterki może też odwoływać się do modelu budynku, który zbliża się do koncepcji cyfrowego bliźniaka nieruchomości.

Wpis w kilkanaście sekund

Inspektor w trakcie odbioru nie ma czasu na formularz z dziesięcioma polami. Zdjęcie, pinezka, kategoria z listy i krótki opis, często podyktowany głosem. Resztę, na przykład przypisanie do podwykonawcy, system może uzupełnić sam na podstawie kategorii i zakresu umowy.

Interfejs musi też działać w realnych warunkach budowy: w rękawicach, w słabym świetle, na zakurzonym ekranie. Duże przyciski i czytelny kontrast to nie kwestia estetyki. Zasady projektowania przycisków w aplikacjach mobilnych mają tu bardzo praktyczne znaczenie, bo każde chybione kliknięcie to kilka sekund razy kilkaset usterek.

Checklisty dla różnych rodzajów odbiorów

Odbiór stanu deweloperskiego wygląda inaczej niż przegląd części wspólnych czy odbiór instalacji. Aplikacja powinna pozwalać budować szablony list kontrolnych: co sprawdzić w łazience, w kuchni, na balkonie. Inspektor przechodzi punkt po punkcie i nie musi pamiętać, że w poprzedniej inwestycji problemem były progi balkonowe. Szablon to pamięta.

Praca bez zasięgu

W piwnicach, garażach podziemnych i klatkach schodowych z grubymi stropami zasięg znika. Aplikacja, która w takim miejscu pokazuje kręcące się kółko, przestaje być używana po tygodniu. Tryb offline oznacza, że usterki, zdjęcia i rzuty są zapisywane na urządzeniu, a synchronizacja z serwerem następuje automatycznie, gdy sieć wróci. Technicznie opiera się to na lokalnym przechowywaniu danych w React Native albo w bazie na urządzeniu, do tego dochodzi obsługa konfliktów, gdy dwie osoby edytują tę samą usterkę bez połączenia.

Zdjęcia w pełnej rozdzielczości szybko zajmują miejsce. Zwykle aplikacja kompresuje je przed wysłaniem, a oryginały trafiają do magazynu plików w chmurze, takiego jak Amazon S3 do przechowywania plików.

Od zgłoszenia do zamknięcia, czyli obieg jednej usterki

Sam wpis na liście to dopiero początek. O wartości systemu decyduje to, co dzieje się dalej. W dobrze zaprojektowanym obiegu każda usterka przechodzi przez jasno zdefiniowane statusy:

1. zgłoszona - wpis z odbioru, jeszcze bez weryfikacji,
2. przypisana - trafiła do konkretnego podwykonawcy z terminem,
3. w naprawie - wykonawca potwierdził przyjęcie,
4. do weryfikacji - wykonawca oznaczył naprawę i dodał zdjęcie „po",
5. zamknięta - kierownik lub inspektor potwierdził naprawę na miejscu,
6. odrzucona lub ponownie otwarta - gdy poprawka nie jest wystarczająca.

Najwięcej zależy od dwóch ostatnich kroków. Wykonawca nie może sam zamknąć zgłoszenia. Może tylko zgłosić je do weryfikacji, a zamyka osoba po stronie generalnego wykonawcy lub dewelopera. Zdjęcie przed i po, zrobione z tego samego miejsca, rozwiązuje większość sporów bez dodatkowej wizyty. Menedżer potrzebuje widoku całości. Najczęściej sprawdza się tablica ze statusami w kolumnach, znana z tablic Kanban w zarządzaniu projektami, filtrowana po budynku, lokalu albo wykonawcy. Kilka sekund wystarczy, żeby zobaczyć, że jedna firma od wykończeń ma trzydzieści przeterminowanych zgłoszeń, a reszta mieści się w terminach.

Przypomnienia działają automatycznie. Zbliżający się termin, przekroczenie terminu, odrzucona naprawa - każde z tych zdarzeń może wysłać powiadomienie do właściwej osoby. Jeśli firma korzysta z innych systemów, te same zdarzenia można przekazywać dalej przez webhook w aplikacji webowej, czyli automatyczne powiadomienie wysyłane do innego programu w chwili, gdy coś się zmieni.

Protokół odbioru i podpis klienta

Odbiór z klientem kończy się protokołem. W aplikacji protokół generuje się automatycznie z listy usterek: z numerem lokalu, datą, uczestnikami, pinezkami na rzucie i miniaturami zdjęć. Klient podpisuje go palcem na tablecie, a kopia w PDF trafia do niego mailem jeszcze przed wyjściem z mieszkania. Nie ma przepisywania notatek wieczorem ani ryzyka, że coś zgubi się po drodze.

Podobny mechanizm zbudowaliśmy w aplikacji z e-podpisem dla GreenTransit, w której papierowa dokumentacja transportowa została zastąpiona elektronicznym obiegiem z podpisem i generowaniem dokumentów PDF. Branża jest inna, zasada ta sama: dokument powstaje z danych, a nie z ręcznie wypełnianego formularza.

Protokoły, zdjęcia i historia zmian muszą być potem łatwe do odnalezienia, także po latach, gdy klient zgłosi usterkę w ramach gwarancji. Tu snagging łączy się z szerszym tematem, jakim są systemy DMS do zarządzania dokumentami. Dokumentacja odbiorowa nie powinna żyć w osobnym folderze, do którego dostęp ma tylko jedna osoba z działu technicznego.

Kto korzysta z aplikacji i co widzi

W odbiorach uczestniczy kilka stron o bardzo różnych potrzebach. Uprawnienia trzeba zaprojektować od początku, bo odpowiadają na pytanie, kto może dodać usterkę, kto ją zamknąć, a kto tylko ją obejrzeć.

Najczęściej spotykany układ ról obejmuje:

• inspektora lub kierownika robót - dodaje i zamyka usterki, widzi całą inwestycję,
• podwykonawcę - widzi tylko usterki przypisane do swojej firmy, zmienia ich status i dodaje zdjęcia po naprawie,
• dział obsługi klienta dewelopera - śledzi usterki zgłoszone przez nabywców i odpowiada na ich pytania,
• klienta - widzi usterki ze swojego lokalu i ich status,
• zarząd - ogląda raporty zbiorcze bez możliwości edycji.

Podwykonawca to szczególny przypadek. Często nie chce instalować kolejnej aplikacji dla jednego zlecenia. Rozwiązaniem bywa prosty widok w przeglądarce, otwierany z linku w powiadomieniu. Tu sprawdza się aplikacja PWA działająca w przeglądarce, którą można też dodać do ekranu telefonu jak zwykłą aplikację. Klient po odbiorze kluczy zmienia rolę. Z uczestnika odbioru staje się osobą, która zgłasza usterki gwarancyjne. Dobrze, jeśli robi to w tym samym systemie, w portalu klienta, zamiast pisać maile na ogólną skrzynkę. Deweloper ma wtedy pełną historię lokalu od pierwszego odbioru. W wielu firmach taki portal jest częścią szerszego oprogramowania dla branży nieruchomości i PropTech, obejmującego sprzedaż, dokumenty i obsługę posprzedażową.

Dane z odbiorów i zastosowanie AI

Po kilku inwestycjach w systemie zbiera się materiał, którego nie da się uzyskać z arkuszy. Ile usterek przypada średnio na lokal, które kategorie powtarzają się najczęściej, który podwykonawca naprawia szybko, a który regularnie przekracza terminy. Te liczby mają bezpośrednie przełożenie na wybór wykonawców przy kolejnym projekcie i na treść umów. Raport per kategoria pokazuje też problemy projektowe. Jeśli w trzech kolejnych budynkach powtarza się ten sam typ usterki, na przykład przy montażu stolarki, przyczyna zwykle leży w detalu projektowym albo w technologii wykonania, a nie w przypadku.

AI pojawia się w aplikacjach do odbiorów coraz częściej, ale rozsądnie jest traktować ją jako pomoc, a nie autopilota. Model rozpoznawania obrazu, czyli computer vision oparte na sztucznej inteligencji, może zasugerować kategorię usterki na podstawie zdjęcia albo wykryć, że to samo zgłoszenie zostało dodane dwa razy. Model językowy może z kolei zamienić podyktowaną notatkę w uporządkowany opis. Decyzja o zamknięciu usterki zostaje po stronie człowieka.

Dane z odbiorów przydają się też po przekazaniu budynku zarządcy. Historia usterek i napraw to cenny materiał dla zespołu, który wdraża Facility Management Software do zarządzania budynkiem, bo pokazuje słabe punkty obiektu od pierwszego dnia.

Gotowa aplikacja do snaggingu czy własne narzędzie

Na rynku działa sporo gotowych aplikacji do odbiorów i usterek, rozliczanych zwykle w abonamencie. Dla generalnego wykonawcy, który potrzebuje uporządkować odbiory na kilku budowach, często to wystarczy. Wdrożenie jest szybkie, a funkcje podstawowe są dopracowane. Własne narzędzie zaczyna mieć sens, gdy snagging jest częścią większego procesu, a nie osobną wyspą. Najczęściej dzieje się tak, gdy deweloper chce połączyć odbiory z systemem CRM do obsługi klientów i portalem nabywcy, gdy firma ma własny proces odbiorów, którego gotowe szablony nie oddają, albo gdy potrzebuje integracji z systemami wykonawców i rozliczeniami potrąceń za nieusunięte usterki. Znaczenie ma też skala: przy wielu inwestycjach rocznie koszt abonamentu liczonego od użytkownika lub od lokalu potrafi rosnąć szybciej niż zakładano. Przy budowie własnej aplikacji mobilnej trzeba wybrać technologię. Aplikacje terenowe zwykle powstają jako aplikacje wieloplatformowe, bo zespoły używają zarówno Androida, jak i iPhone'ów, a budżet rzadko pozwala na dwie osobne wersje. Najczęściej wybór pada między React Native a Flutterem. Dla odbiorów decydują przede wszystkim jakość trybu offline, obsługa aparatu i wydajność przy dużej liczbie zdjęć.

Niezależnie od wybranej drogi wdrożenie najlepiej zacząć od pilotażu na jednym etapie inwestycji. Kilka tygodni pracy z prawdziwymi inspektorami i podwykonawcami pokazuje, które pola są zbędne, gdzie aplikacja spowalnia odbiór i czego brakuje w raportach. Wnioski z pilotażu wracają do projektowania interfejsu i doświadczeń użytkownika, zanim aplikacja trafi na wszystkie budowy.

W Boring Owl tworzymy oprogramowanie dla budownictwa i ConTech: aplikacje dla pracowników terenowych z trybem offline, systemy obiegu dokumentów, protokoły kontrolne i raportowanie postępu prac. Takie narzędzia projektujemy jako aplikacje mobilne na iOS i Androida, zwykle z panelem webowym dla biura.