Na grupie pojawia się zdjęcie usterki z komentarzem „to trzeba poprawić”. Wszyscy widzą problem, ale nie wszyscy wiedzą, gdzie dokładnie się znajduje, kto ma go usunąć i czy późniejsze zdjęcie pokazuje już tę samą sprawę. Aplikacja na budowie powinna nadać zgłoszeniu adres w projekcie oraz czytelną drogę do odbioru. Bez tego cyfrowa dokumentacja może urosnąć równie szybko jak liczba wiadomości, z których miała nas uwolnić.
Dobry punkt wyjścia to jedna rzeczywista usterka przeprowadzona od zgłoszenia do akceptacji poprawki. Warto zobaczyć, jakie informacje są potrzebne wykonawcy, koordynatorowi i osobie odbierającej. Nie zawsze są identyczne. Dla jednej osoby najważniejszy będzie zakres, dla drugiej miejsce, dla trzeciej dokument potwierdzający zmianę. System ma połączyć te potrzeby w sprawie, którą można odnaleźć bez pamiętania dnia i godziny wysłania zdjęcia.
Lokalizacja powinna być bardziej precyzyjna niż nazwa budowy
Projekt, obiekt, kondygnacja, pomieszczenie i element mogą tworzyć różne poziomy identyfikacji. Nie każda inwestycja potrzebuje takiej samej struktury. Trzeba dobrać ją do sposobu prowadzenia prac oraz późniejszego wyszukiwania. Jeśli użytkownik wybiera miejsce z listy, nazwy muszą odpowiadać temu, czego używa zespół. Inaczej każdy zacznie dopisywać własny opis, a aplikacja zgromadzi kilka równoległych map tego samego obiektu.
Zdjęcia warto łączyć ze sprawą już podczas dodawania. Podobny problem opisujemy przy dokumentach w logistyce: plik bez kontekstu wymaga późniejszego dopasowania. Na budowie dochodzi jeszcze wersja dokumentacji i etap prac. To, co wygląda jak brak na jednym zdjęciu, może dotyczyć innego zakresu niż późniejszy protokół. Aplikacja powinna pomagać odróżnić te sytuacje, a nie zgadywać ich na podstawie nazwy pliku.
Przydział oznacza odpowiedzialność za kolejny krok
Przy zgłoszeniu ustalcie właściciela, termin reakcji i warunek zakończenia. Samo przypisanie firmy może być zbyt ogólne, jeśli po jej stronie nikt nie odbiera sprawy. Warto pokazać, kto potwierdził przyjęcie i gdzie kieruje się pytanie o zakres. Nie każdy użytkownik musi edytować wszystkie dane. Wykonawca może zgłosić gotowość do odbioru, a uprawniona osoba potwierdzić rezultat. System powinien odzwierciedlać ten podział.
Zamknięcie sprawy po dodaniu zdjęcia nie zawsze będzie właściwe. Czasem potrzebna jest weryfikacja na miejscu lub uzupełnienie dokumentu. Warto rozdzielić status wykonania od statusu odbioru. Takie podejście do kryteriów i testowania rezultatu pomaga także przy zamawianiu samej aplikacji. W obu przypadkach „gotowe” powinno mieć znaczenie uzgodnione przez uczestników, a nie wyłącznie deklarację osoby wykonującej zadanie.
Telefon musi poradzić sobie z warunkami pracy
Zgłoszenie tworzone w terenie powinno wymagać możliwie krótkiej ścieżki. Miejsce, opis, zdjęcie i typ sprawy mogą wystarczyć na start, jeśli pozostałe dane uzupełnia się później zgodnie z rolą. Przy wyborze technologii aplikacji mobilnej lub webowej sprawdźcie sprzęt, jakość połączenia i sposób dodawania załączników. Warto też ustalić widoczną informację o zapisie, aby użytkownik nie tworzył ponownie tego samego zgłoszenia.
Jeżeli aplikacja pracuje z dokumentacją z innego systemu, ustalcie, skąd pochodzi wersja obowiązująca oraz jak oznaczyć materiał archiwalny. Temat źródła prawdy danych jest tu bardzo konkretny: pracownik nie powinien wykonywać zadania według pliku, którego aktualność można potwierdzić dopiero po telefonie do biura. Nie chodzi o przechowywanie wszystkiego w jednym programie. Chodzi o rozpoznawalny związek między zleceniem a właściwą informacją.
Raport powinien prowadzić do otwartych spraw
Kierownik może potrzebować listy usterek według miejsca, wykonawcy i etapu. Ważne, aby z podsumowania dało się przejść do konkretnego zgłoszenia oraz przyczyny oczekiwania. Wspólny licznik czerwonych punktów nie wyjaśnia, czy zespół czeka na wykonawcę, materiał czy odbiór. Dalsze usprawnienia obiegu można zaplanować podobnie jak automatyzację zleceń serwisowych, z czytelnym przekazaniem zadania i miejscem na decyzję człowieka. Po zakończeniu inwestycji inne potrzeby pojawiają się przy zarządzaniu kosztami i decyzjami dotyczącymi nieruchomości.
Przed uruchomieniem warto przeprowadzić próbę także z osobą spoza zespołu projektującego aplikację. Niech samodzielnie utworzy zgłoszenie, odszuka miejsce i odnajdzie przydzieloną poprawkę. Jeżeli do obsługi potrzebuje szczegółowej instrukcji autora, uprośćcie ścieżkę albo nazewnictwo. Taka obserwacja potrafi ujawnić różnice między językiem biura a językiem używanym na budowie, zanim utrwalą się w gotowych formularzach.
Archifutura projektuje narzędzia dla nieruchomości i budownictwa na podstawie rzeczywistego przepływu informacji. Na rozmowę o aplikacji budowlanej przynieś przykładową sprawę z dokumentami oraz historią poprawki. Ustalimy, czego brakowało do jej sprawnego zamknięcia. Dobra aplikacja nie potrzebuje wiedzieć wszystkiego o inwestycji. Powinna natomiast pomagać odnaleźć problem, wykonać pracę i potwierdzić jej wynik bez kolejnego poszukiwania właściwej wiadomości.
