Matryca odpowiedzialności w aplikacji: kto zatwierdza, kto poprawia, kto odpowiada

Dlaczego matryca odpowiedzialności w aplikacji jest kluczowa na budowie

Cyfrowa aplikacja bez matrycy odpowiedzialności = cyfrowy chaos

Cyfrowe narzędzia nadzoru budowlanego rozwiązują wiele problemów, ale jeden warunek jest niezmienny: bez jasnego podziału odpowiedzialności powstaje tylko szybszy chaos. Usterki krążą po systemie, zadania się dublują, a decyzje nie zapadają, bo nikt nie czuje się ostatecznie odpowiedzialny. Zamiast „ktoś” w aplikacji musi być jednoznacznie wskazane, kto zgłasza, kto poprawia, kto zatwierdza i kto finalnie odpowiada.

Na budowie szczególnie groźne są sytuacje, w których system przydziela zadania przypadkowo albo „do wszystkich”. Wtedy każdy zakłada, że zareaguje ktoś inny. Bez jasno skonfigurowanej matrycy odpowiedzialności w aplikacji, nawet najlepsze cyfrowe checklisty i raporty stają się jedynie archiwum niewyjaśnionych spraw, a nie narzędziem kontroli jakości.

Matryca odpowiedzialności w aplikacji porządkuje przepływ zadań w inspekcjach, definiuje ścieżkę zatwierdzania usterek i sprawia, że każde zgłoszenie ma właściciela. Dzięki temu inspektor nadzoru, kierownik budowy, wykonawcy i podwykonawcy wiedzą, co do nich należy i czego mogą wymagać od innych.

Różnica między odpowiedzialnością prawną a operacyjną w aplikacji

Na budowie istnieją dwie płaszczyzny odpowiedzialności: prawna i operacyjna. Odpowiedzialność prawna wynika z przepisów Prawa budowlanego, umów, uprawnień i pełnionych funkcji (np. kierownik budowy, inspektor nadzoru inwestorskiego, projektant). Tego nie da się „przeklikać” w aplikacji. Kierownik budowy zawsze będzie odpowiadał za prowadzenie budowy, a inspektor nadzoru za kontrolę zgodności robót z projektem i przepisami.

Odpowiedzialność operacyjna dotyczy natomiast tego, kto technicznie wykonuje czynność w systemie: zakłada zgłoszenie, aktualizuje status usterki, wysyła raport, akceptuje zdjęcia z inspekcji. Tu aplikacja daje dużą swobodę. Można zdecydować, że część zadań kierownika przejmie „koordynator usterek”, a inspektor będzie tylko zatwierdzał wybrane etapy.

Klucz polega na tym, aby matryca odpowiedzialności w aplikacji nie myliła odpowiedzialności operacyjnej z prawną. To, że w systemie usterki zatwierdza inżynier kontraktu, nie zwalnia kierownika budowy z obowiązków wynikających z Prawa budowlanego. Konfigurując role, trzeba zawsze weryfikować, czy przepływy w aplikacji nie wchodzą w konflikt z faktycznymi obowiązkami formalnymi na budowie.

Krótki przykład: poprawka dachu „wisi” 3 tygodnie

Wyobraźmy sobie sytuację: w aplikacji odnotowano nieszczelność dachu. Zgłoszenie trafiło jako zadanie „do wszystkich wykonawców branżowych”, a rola „właściciela sprawy” w systemie nie została przypisana. Po tygodniu ktoś dodał komentarz, że to „pewnie błąd w obróbce blacharskiej”. Po kolejnym tygodniu kierownik budowy założył, że inspektor już to przekierował do właściwego podwykonawcy. Inspektor zaś uznał, że skoro zgłoszenie jest w systemie, to wykonawca już działa.

Efekt: po trzech tygodniach na budowie zbiera się woda, pojawiają się zacieki, a inwestor widzi w aplikacji tylko rosnącą liczbę komentarzy. Brakuje jednego najważniejszego elementu: w systemie nie zdefiniowano roli, która finalnie odpowiada za doprowadzenie usterki do zamknięcia. Jest „ktoś powinien”, ale nie ma „ten konkretny użytkownik / rola musi”.

Takie sytuacje są typowym skutkiem braku matrycy odpowiedzialności. Od strony technicznej aplikacja działa, raporty się generują, ale z perspektywy nadzoru inwestorskiego i jakości robót powstaje czarna dziura. Gdyby matryca była jasno wdrożona, zgłoszenie automatycznie otrzymałoby właściciela (np. „kierownik robót dachowych – A”), a aplikacja pilnowałaby terminów i eskalacji.

Co sprawdzić: szybki test do zrobienia z zespołem

Najprostszy sposób, by ocenić, czy matryca odpowiedzialności w aplikacji działa, to krótki warsztat z zespołem. Zrób to w formie krótkiego ćwiczenia:

• Krok 1: Narysuj na tablicy proces „zgłoszenie usterki od momentu odkrycia do zatwierdzenia poprawki”.
• Krok 2: Poproś, aby każda osoba w zespole dopisała nad strzałkami: kto w aplikacji robi dany krok.
• Krok 3: Zaznacz różnymi kolorami: kto zgłasza, kto przekazuje, kto poprawia, kto zatwierdza, kto zamyka w systemie.

Jeżeli choć w jednym punkcie padają odpowiedzi typu „to zależy”, „różnie bywa”, „wszyscy mamy dostęp”, to sygnał, że matryca odpowiedzialności w aplikacji jest niepełna albo niezakomunikowana. Warto od razu doprecyzować role i uzupełnić konfigurację w systemie.

Podstawy matrycy odpowiedzialności (R–A–C–I) przełożone na realia budowy

Cztery typy ról RACI: proste definicje pod kątem budowy

Model RACI to popularny sposób opisu matrycy odpowiedzialności. W wersji praktycznej dla budowy oznacza:

• R – Responsible (odpowiedzialny za wykonanie): osoba, która robi zadanie w aplikacji lub w terenie. Np. wykonawca poprawia usterkę, inżynier wprowadza dane do raportu, inspektor przeprowadza inspekcję.
• A – Accountable (odpowiedzialny ostatecznie): osoba, która zatwierdza wynik i odpowiada za to, że zadanie jest wykonane. W matrycy zawsze powinna być tylko jedna rola A dla danego kroku.
• C – Consulted (konsultowany): osoby, z którymi trzeba się skonsultować przed decyzją lub w trakcie realizacji zadania. Mogą dodawać uwagi w aplikacji, akceptować część dokumentów technicznych.
• I – Informed (informowany): osoby, które muszą być poinformowane, ale nie ingerują w decyzje. W aplikacji to np. automatyczne powiadomienia po zamknięciu usterki czy wysłaniu raportu.

Matryca odpowiedzialności RACI w aplikacji nadzoru budowlanego nie polega na tworzeniu skomplikowanych wykresów. Sednem jest jednoznaczne ustalenie, kto jest R, kto A, a kto tylko C lub I w najważniejszych procesach: zgłaszanie usterek, odbiory, raporty, niezgodności BHP.

Przykłady RACI: inspekcja zbrojenia, odbiór częściowy, zgłoszenie usterki

Dobrym sposobem na zrozumienie matrycy odpowiedzialności w aplikacji jest rozpisanie kilku typowych sytuacji.

Inspekcja zbrojenia

• R (Responsible): inspektor nadzoru robi inspekcję, wprowadza wyniki i zdjęcia do aplikacji.
• A (Accountable): kierownik budowy zatwierdza, że zbrojenie może zostać zalane betonem (z perspektywy operacyjnej w aplikacji) lub odwrotnie – inspektor jako A akceptuje ukrycie robót.
• C (Consulted): projektant konstrukcji, jeśli są odchylenia od projektu.
• I (Informed): inwestor i wykonawca główny otrzymują powiadomienie o wyniku inspekcji.

Odbiór częściowy robót

• R: kierownik robót kompletuję dokumenty, zdjęcia, wypełnia checklistę w aplikacji.
• A: inspektor nadzoru inwestorskiego akceptuje odbiór w systemie.
• C: kierownik budowy, ewentualnie przedstawiciel inwestora.
• I: dział rozliczeń inwestora, aby na tej podstawie przygotować rozliczenie.

Zgłoszenie usterki

• R: wykonawca lub podwykonawca, który w aplikacji aktualizuje status i dodaje dowody usunięcia usterki.
• A: określony inspektor lub kierownik budowy, który zatwierdza usunięcie.
• C: projektant, gdy usterka dotyczy rozwiązań projektowych lub zamiennych materiałów.
• I: inwestor otrzymujący informację o zamknięciu usterki.

Takie rozpisanie pozwala skonfigurować przypisania ról w aplikacji: kto może zmieniać status, kto ma przycisk „zatwierdź”, a kto otrzymuje wyłącznie powiadomienie.

Granica między „robi” a „zatwierdza” w aplikacji

Na budowie często zaciera się różnica między tym, kto wykonuje zadanie w terenie, a tym, kto formalnie je zatwierdza. Aplikacja dodatkowo miesza te role, gdy każdy ma „nieskończone” uprawnienia. Dlatego przy wdrażaniu matrycy odpowiedzialności trzeba celowo oddzielić:

• Rola „robi” (R): w systemie może edytować formularz, wgrywać zdjęcia, aktualizować status na „w trakcie”, „wykonane”.
• Rola „zatwierdza” (A): ma przycisk „akceptuj / odrzuć”, zamyka zgłoszenie, może zmienić status na „zatwierdzone / odebrane”.

Typowy błąd to nadawanie kierownikowi budowy zarówno roli R, jak i A w każdym procesie. W efekcie kierownik robi wszystko, a zespół pasywnie obserwuje. Lepszym rozwiązaniem jest zdefiniowanie w aplikacji np. „prowadzącego usterki” (R) i „zatwierdzającego usunięcie” (A), przy jednoczesnym zachowaniu odpowiedzialności prawnej kierownika i inspektora.

Jak zapisywać matrycę: tabela, diagram, konfiguracja systemowa

Matrycę odpowiedzialności można przedstawić na kilka sposobów. Dobrą praktyką jest użycie prostych tabel oraz diagramu przepływu procesu, a następnie przeniesienie tego na konfigurację ról w aplikacji.

Taką tabelę warto mieć w formie roboczej (np. PDF) oraz przeniesioną bezpośrednio do konfiguracji aplikacji: szablony przepływów, przypisania ról, uprawnienia do zmiany statusów, widoczność danych.

Co sprawdzić: trzy kluczowe procesy i ich R/A

Dla praktycznej kontroli wystarczy przeanalizować trzy najważniejsze procesy:

• zgłaszanie i zamykanie usterek,
• odbiór częściowy / końcowy,
• przygotowanie i wysyłka raportów (dziennych, tygodniowych, miesięcznych).

Dla każdego z nich odpowiedz zespołowo na pytania:

• Kto jest R (Responsible) za wykonanie czynności w aplikacji?
• Kto jest A (Accountable) za ostateczną decyzję i zamknięcie kroku w systemie?

Jeżeli nie jesteś w stanie przypisać jednej roli A do każdego procesu, matryca odpowiedzialności w aplikacji wymaga dopracowania. W takim przypadku warto od razu zaktualizować zarówno tabelę RACI, jak i konfigurację ról w systemie.

Kluczowe role na budowie a role w aplikacji – odwzorowanie 1:1 czy inaczej?

Standardowe role na budowie i ich odpowiedniki cyfrowe

Na typowej budowie występują następujące role formalne:

• inwestor / przedstawiciel inwestora,
• inspektor nadzoru inwestorskiego,
• kierownik budowy,
• kierownik robót / brygadzista,
• wykonawca generalny,
• podwykonawcy branżowi,
• projektant, projektant branżowy,
• specjalista BHP / koordynator BHP.

W aplikacji nadzoru budowlanego te role są odwzorowywane jako konta użytkowników oraz grupy ról systemowych. Można podejść do tego na dwa sposoby:

• Odwzorowanie 1:1: rola systemowa „kierownik budowy” odpowiada dokładnie formalnej funkcji. To najprostszy model dla mniejszych projektów.
• Role techniczne: oprócz ról formalnych tworzy się role operacyjne, np. „Koordynator usterek”, „Twórca raportów”, „Osoba zatwierdzająca odbiory”. Jedna osoba może mieć kilka ról technicznych.

Kiedy nie robić odwzorowania 1:1 ról

Są sytuacje, w których proste przeniesienie ról formalnych do aplikacji wprowadza chaos zamiast porządku. Dzieje się tak najczęściej, gdy:

• jeden człowiek pełni kilka funkcji (np. kierownik budowy jest jednocześnie inspektorem w projekcie wewnętrznym),
• na budowie pracuje wielu podwykonawców o zmiennym składzie,
• część funkcji jest „czasowa” – np. inspektor branżowy pojawia się tylko na wybrane odbiory.

W takich przypadkach lepiej zdefiniować w aplikacji role operacyjne, a dopiero potem przypisywać do nich konkretne osoby. Dzięki temu matryca odpowiedzialności jest stabilna, nawet jeśli zespół osobowy się zmienia.

Przykład z praktyki: na dużej budowie instalacyjnej kierownik robót sanitarnych i elektryk mają wspólną formalną rolę „kierownik robót”. W aplikacji można rozdzielić ich odpowiedzialności przez role techniczne „Odpowiedzialny za usterki sanitarne” i „Odpowiedzialny za usterki elektryczne”, choć obaj formalnie pozostają kierownikami robót.

Łączenie ról formalnych i operacyjnych

Najbardziej przejrzysty model to połączenie dwóch warstw:

• warstwa formalna – kto pełni funkcję wynikającą z prawa budowlanego i umów,
• warstwa operacyjna – kto co robi w aplikacji (zgłasza, poprawia, zatwierdza, wysyła raport).

Krok 1: sporządź listę ról formalnych na projekcie (jak w dzienniku budowy).
Krok 2: do każdej formalnej roli dopisz, jakie zadania wykonuje w systemie – osobno „robi”, osobno „zatwierdza”.
Krok 3: na tej podstawie zbuduj role operacyjne w aplikacji, np. „Zgłaszający usterki”, „Zatwierdzający usterki”, „Autor raportu dziennego”, „Akceptujący raport dzienny”.

Jedna osoba może mieć kilka ról operacyjnych, ale istotne, aby dla każdego procesu dało się palcem wskazać jedną rolę „A” – nawet jeśli osoba fizycznie jest ta sama.

Co sprawdzić: przejdź proces „usterka → poprawa → akceptacja” i zapisz, czy w którymkolwiek kroku masz więcej niż jednego „A”. Jeśli tak – doprecyzuj role operacyjne.

Projektowanie matrycy odpowiedzialności krok po kroku – od procesów do ról

Krok 1: Zidentyfikuj kluczowe procesy na budowie

Zamiast zaczynać od listy stanowisk, zacznij od listy procesów. Dla większości budów wystarczy kilkanaście procesów, żeby pokryć 80–90% pracy w aplikacji. Typowe przykłady:

• zgłoszenie usterki,
• usunięcie usterki,
• akceptacja usunięcia usterki,
• odbiór robót zanikających,
• odbiór częściowy / końcowy,
• inspekcja BHP i niezgodności,
• raport dzienny / tygodniowy,
• zgłoszenie zmiany projektowej,
• zgłoszenie kolizji / problemu technicznego (issue).

Dla każdego procesu spisz krótko, co jest wynikiem końcowym: np. „usterka zamknięta”, „odbiór zatwierdzony”, „raport wysłany do inwestora”. Ten wynik będzie punktem odniesienia do roli „A”.

Co sprawdzić: czy na liście procesów masz wszystkie czynności, które kończą się formalnym „OK” lub „zatwierdzone” w aplikacji. Jeśli coś wymaga pieczątki w realu, najpewniej powinno mieć też jasne „A” w systemie.

Krok 2: Rozpisz procesy na kroki w aplikacji

Kolejny etap to rozbicie każdego procesu na proste kroki, jakie rzeczywiście wykonywane są w systemie. Dla zgłaszania usterek może to wyglądać tak:

1. utworzenie zgłoszenia z opisem i zdjęciem,
2. przypisanie do wykonawcy,
3. aktualizacja statusu na „do poprawy / w toku”,
4. dodanie informacji o usunięciu usterki (zdjęcia, komentarz),
5. weryfikacja przez stronę nadzorującą,
6. zatwierdzenie usunięcia usterki lub odesłanie do poprawy.

Nie chodzi o tworzenie naukowych diagramów, tylko o spisanie sekwencji czynności, które potem odwzorujesz w aplikacji jako statusy, przyciski, uprawnienia.

Typowy błąd: projektowanie matrycy tylko „głowami” (kierownik, inspektor, wykonawca), bez rozpisania kroków. W efekcie wszyscy mają dostęp do wszystkiego i trudno powiedzieć, kto miał co zrobić w konkretnym momencie.

Co sprawdzić: czy dla każdego procesu masz opisane minimum: „kto tworzy”, „kto aktualizuje”, „kto zamyka” w kontekście aplikacji.

Krok 3: Przypisz R oraz A do każdego kroku

Gdy kroki są jasne, można zacząć przypisania R i A. Dobrze sprawdza się prosty arkusz:

Rolę „C” i „I” dodaj dopiero wtedy, gdy R i A są jasne. To kluczowy warunek czytelnej matrycy.

Co sprawdzić: przy każdym kroku zaznacz, czy udało się przypisać dokładnie jedno „A”. Jeśli w komórce pojawiają się dwa stanowiska rozdzielone przecinkiem – wróć do dyskusji w zespole.

Krok 4: Dodaj konsultowanych (C) i informowanych (I)

Gdy fundament (R i A) jest gotowy, można dopisać rolę konsultowanych i informowanych. Robisz to w dwóch perspektywach:

• konsultowani (C) – kto musi mieć możliwość dodania komentarza, opinii, warunku w aplikacji, zanim zadanie zostanie zamknięte,
• informowani (I) – kto ma dostać powiadomienie lub dostęp „tylko do odczytu” po wykonaniu kroku.

Przykład: dla procesu „odbiór częściowy” rolą C może być projektant, który w aplikacji zostawia warunek „pod warunkiem zastosowania materiału X”, a rolą I – dział rozliczeń, który otrzymuje automatyczny e‑mail z raportem z odbioru.

Typowy błąd: „przestrzelone” powiadomienia. Jeśli do każdego zamknięcia usterki powiadamiany jest cały projekt, nikt nie będzie czytał komunikatów. Lepiej mieć krótką, przemyślaną listę „I”.

Co sprawdzić: zlicz, ile osób w twoim projekcie dostaje powiadomienie o zamknięciu usterki. Jeśli powyżej kilku, rozważ ograniczenie listy „I” i pozostawienie reszcie tylko dostępu do przeglądania danych w systemie.

Krok 5: Przenieś matrycę do konfiguracji aplikacji

Ostatni krok to przełożenie tabeli na konkretne ustawienia systemu. W praktyce oznacza to:

• utworzenie ról systemowych (grup uprawnień) zgodnie z matrycą RACI,
• zdefiniowanie, kto może tworzyć daną jednostkę (usterkę, raport, zgłoszenie),
• określenie, kto może zmieniać status na każdy z kolejnych poziomów,
• ustalenie, kto ma przycisk „zatwierdź / odrzuć”, a kto widzi dane tylko do odczytu,
• skonfigurowanie powiadomień dla ról C i I.

Tu dobrze działa podejście małych kroków: najpierw konfiguracja dla jednego procesu (np. usterki), test w realnej pracy przez tydzień, drobne korekty, a dopiero potem przeniesienie wzorca na kolejne procesy.

Co sprawdzić: przećwicz z zespołem scenariusz „na sucho”: zakładacie testową usterkę i krok po kroku sprawdzacie, kto co widzi, kto ma jakie przyciski. Jeśli ktoś mówi „nie mogę zatwierdzić, choć powinienem” albo „mam przycisk, którego nie chcę”, popraw matrycę i konfigurację.

Matryca w praktyce: zgłaszanie, poprawa i zatwierdzanie usterek w aplikacji

Scenariusz podstawowy: od zgłoszenia do zamknięcia

Najczęściej używanym procesem w aplikacjach nadzoru jest obieg usterek. Dobrze zaprojektowana matryca odpowiedzialności powinna obsłużyć scenariusz podstawowy bez konieczności „dzwonienia do kierownika”. Przykładowa sekwencja:

1. Zgłoszenie usterki – inspektor lub kierownik robót (R) tworzy zgłoszenie w aplikacji, dodaje opis, lokalizację, zdjęcia, priorytet. Na tym etapie zwykle nie ma roli A.
2. Przypisanie do wykonawcy – kierownik robót (R) przypisuje usterkę do konkretnego wykonawcy, a kierownik budowy (A) w razie potrzeby zatwierdza taki przydział.
3. Usunięcie usterki – wykonawca (R) usuwa wadę w terenie, dokumentuje to w aplikacji, zmienia status na „do odbioru” i dodaje zdjęcia.
4. Weryfikacja – inspektor lub kierownik robót (R) ogląda efekt i w aplikacji podejmuje decyzję.
5. Zatwierdzenie / odrzucenie – inspektor nadzoru lub kierownik budowy (A) zmienia status na „zatwierdzone” lub „do poprawy” i tym samym zamyka lub ponownie otwiera zgłoszenie.

Rola C pojawia się zwykle w szczególnych przypadkach (np. konsultacja z projektantem), a I – gdy trzeba poinformować inwestora o zamknięciu ważnych usterek.

Co sprawdzić: czy w twojej aplikacji każda usterka ma jasno widocznego „właściciela” (R) i „zatwierdzającego” (A) w każdym etapie. Jeśli nie – brakuje elementów matrycy.

Obsługa sporów i odrzuceń: kto decyduje o „do poprawy”

Drugim kluczowym scenariuszem jest sytuacja, gdy usterka nie zostaje zaakceptowana. Tu matryca odpowiedzialności powinna jasno określać:

• kto może zmienić status z „do odbioru” na „do poprawy”,
• kto jest informowany o odrzuceniu (wykonawca, kierownik robót, inwestor),
• kto może „przebić” tę decyzję (np. inspektor główny, inwestor).

Praktyczny model:

• R: inspektor / kierownik robót – wykonuje oględziny, wpisuje uzasadnienie „do poprawy”,
• A: kierownik budowy lub inspektor nadzoru – zatwierdza status „do poprawy”, a w spornej sytuacji może zmienić na „zatwierdzone pod warunkiem…”.

W aplikacji powinno to oznaczać, że osoba R ma prawo zasugerować zmianę statusu, ale dopiero A ostatecznie go zatwierdza. W mniejszych projektach te role bywają połączone w jednej osobie, lecz w matrycy i tak należy je rozróżnić.

Co sprawdzić: przejrzyj kilka zamkniętych usterek – czy widać, kto realnie „odbił” usterkę, a kto tylko ją oglądał. Jeśli w historii nie ma takiego rozróżnienia, doprecyzuj role i uprawnienia.

Usterki BHP a usterki jakościowe – dwie matryce zamiast jednej

Z punktu widzenia odpowiedzialności prawnej inne są konsekwencje usterki jakościowej (np. krzywa ściana), a inne BHP (np. brak zabezpieczenia otworu). Często sensowne jest zbudowanie dwóch osobnych matryc:

• matryca usterek jakościowych – koncentruje się na relacji wykonawca–nadzór–inwestor,
• matryca niezgodności BHP – akcentuje rolę koordynatora BHP i natychmiastowe działania zabezpieczające.

Przykład dla BHP:

• R: specjalista BHP – zgłasza niezgodność w aplikacji, dokumentuje zdjęciami, proponuje działanie zabezpieczające,
• A: kierownik budowy – podejmuje decyzję o wstrzymaniu robót lub dopuszczeniu do kontynuacji po zabezpieczeniu,
• C: koordynator BHP ze strony inwestora,
• I: wykonawca, podwykonawca odpowiedzialny za dane stanowisko.

Gdy próbuje się „upchnąć” BHP i jakość w jedną matrycę, zwykle albo BHP jest spychane na margines, albo każda niezgodność jakościowa podlega przesadnie rozbudowanej ścieżce zatwierdzania.

Integracja matrycy z harmonogramem i kamieniami milowymi

Matryca odpowiedzialności żyje nie tylko w obiegu usterek. Dobrze zintegrowana z harmonogramem i kamieniami milowymi staje się praktycznym narzędziem zarządzania całym kontraktem, a nie tylko „listą błędów”.

Krok 1: przyporządkuj kluczowe procesy do kamieni milowych. Dla każdego etapu robót (fundamenty, stan surowy, wykończeniówka, rozruchy) określ, które procesy w aplikacji są wtedy krytyczne: odbiory częściowe, przeglądy BHP, testy instalacji, rozruchy. Następnie dopisz, kto jest A dla każdego z nich w tym etapie. Często okazuje się, że np. w fazie rozruchów faktycznym „A” jest kierownik rozruchu, a nie kierownik budowy.

Krok 2: ustaw powiązania statusów z harmonogramem. W wielu systemach można powiązać statusy w aplikacji z kamieniami milowymi (np. „odbiór stanu surowego – zatwierdzony”). To pozwala z automatu:

• odblokować kolejne zadania w harmonogramie,
• przekazać informację do działu rozliczeń,
• uruchomić dodatkowe checklisty (np. dla BHP lub jakości).

Jeśli matryca jasno definiuje, kto zatwierdza dany etap (A), ryzyko „utknięcia” kamienia milowego z powodu braku decyzji jest mniejsze.

Krok 3: dopisz „A rezerwowego” na krytycznych ścieżkach. Przy kamieniach milowych, od których zależy płynność finansowa projektu, dobrze działa zasada: zawsze dwóch możliwych „A” w aplikacji (np. kierownik budowy lub jego zastępca). Dzięki temu decyzja nie wisi w powietrzu tylko dlatego, że jedna osoba jest na urlopie.

Typowy błąd: matryca jest budowana tylko „pod odbiory końcowe”, podczas gdy największy chaos decyzyjny pojawia się w środku kontraktu – przy zmianach zakresu, kolizjach i poprawkach projektowych.

Co sprawdzić: weź aktualny harmonogram i dla 3–5 najbliższych kamieni milowych dopisz w tabeli, kto jest A w aplikacji dla każdego z nich oraz czy ma realnie przypisane odpowiednie uprawnienia.

Powiązanie matrycy z roszczeniami i zmianami

Roszczenia i zmiany zakresu to obszar, gdzie brak precyzyjnego „kto zatwierdza” potrafi zaboleć najbardziej. W aplikacji warto wprost odwzorować matrycę odpowiedzialności dla ścieżki roszczeń i zmian.

Krok 1: rozbij proces roszczenia na kroki. Przykładowo:

1. zgłoszenie zdarzenia (opóźnienie, kolizja, dodatkowe roboty),
2. wstępna ocena techniczna,
3. kalkulacja kosztów / czasu,
4. negocjacje z inwestorem,
5. zatwierdzenie zmiany / roszczenia,
6. wprowadzenie zmiany do kontraktu i harmonogramu.

Dla każdego z tych kroków przypisz R i A – osobno dla części technicznej i kontraktowej.

Krok 2: ustaw role w aplikacji rozdzielając technikę i kontrakt. W praktyce może to wyglądać tak:

• R (techniczny): kierownik robót / projektant – opisuje zdarzenie, zakres dodatkowych robót, wpływ na jakość,
• R (kontraktowy): inżynier kontraktu / dział roszczeń – przygotowuje kalkulację kosztów i czasu,
• A: kierownik projektu lub dyrektor kontraktu – zatwierdza treść roszczenia lub propozycję zmiany przed wysłaniem do inwestora.

W aplikacji odpowiadają za to różne zestawy uprawnień i różne typy formularzy (techniczny opis zmiany vs. formularz roszczeniowy).

Krok 3: zapisz w matrycy, kto ma prawo „zamknąć temat bez roszczenia”. Częsty problem: ktoś na budowie dogaduje się „po cichu”, robi dodatkową robotę bez formalnej zmiany, a dział kontraktowy dowiaduje się o tym po fakcie. W matrycy jasno wskaż osobę (A), która może zatwierdzić rezygnację z roszczenia i wymuś w aplikacji krótkie uzasadnienie decyzji.

Co sprawdzić: otwórz w systemie 2–3 ostatnie zmiany/roszczenia i odpowiedz, czy z historii jasno wynika: kto zgłosił, kto skalkulował, kto zatwierdził. Jeżeli te role „zlewają się” w jedną osobę, rozbij proces i uprawnienia na etapy.

Rola inwestora i inspektora nadzoru w matrycy aplikacji

Obecność inwestora i inspektora nadzoru w systemie zmienia układ sił. Matryca powinna wtedy precyzyjnie rozdzielać: co jest decyzją wewnętrzną wykonawcy, a co decyzją „kontraktową”, formalnie wiążącą.

Krok 1: zdefiniuj przestrzeń „tylko wykonawca”. To obszary, w których inwestor/inspektor widzi tylko efekt, a nie bierze udziału w wewnętrznej dyskusji. Przykłady:

• przypisanie usterek do konkretnych podwykonawców,
• wewnętrzne przeglądy jakości,
• koordynacja międzybranżowa.

Dla tych procesów inwestor nie jest ani R, ani A, często nawet nie I – wystarcza zbiorczy raport okresowy.

Krok 2: oddziel obszar „decyzji kontraktowych”. Tu inwestor lub inspektor pełni rolę A, a wykonawca – R. Dotyczy to zwłaszcza:

• odbiorów częściowych i końcowych,
• akceptacji materiałów zamiennych,
• zatwierdzania zmian projektowych.

W aplikacji przełóż to na osobne statusy: np. „odebrane wewnętrznie” (A po stronie wykonawcy) i „odebrane przez inwestora” (A po stronie inwestora/inspektora). Dzięki temu nie ma mylenia wewnętrznego odbioru z formalnym podpisem.

Krok 3: określ, czy inwestor jest „C” czy „I” w ścieżce usterek. Część inwestorów chce obserwować pojedyncze usterki, inni – tylko raporty zbiorcze. Zamiast wysyłać wszystko do wszystkich, ustal to na początku kontraktu i zapisz w matrycy oraz konfiguracji aplikacji. W praktyce często wystarcza rola I przy wybranych statusach, np. „usterka krytyczna zamknięta”.

Typowy błąd: nadanie inwestorowi zbyt szerokich uprawnień (np. możliwość edycji usterek wykonawców), co prowadzi do chaosu i sporów, kto faktycznie zmienił dane.

Co sprawdzić: zaloguj się do systemu jako użytkownik z profilu inwestora/inspektora (lub poproś o zrzuty ekranu) i sprawdź, czy zakres widoku i przycisków odpowiada roli R/C/I/A z matrycy. Jeśli widać „za dużo” – zawęź dostęp.

Matryca a podwykonawcy i dostawcy – minimalny niezbędny dostęp

Podwykonawcy i dostawcy coraz częściej pracują bezpośrednio w aplikacji wykonawcy. Kluczowe jest takie ustawienie matrycy, by umożliwić im działanie, ale nie oddać im kontroli nad procesem.

Krok 1: określ, co podwykonawca może tworzyć. Zazwyczaj:

• może dodawać komentarze i załączać dokumenty/zdjęcia do zgłoszonych usterek,
• może zmieniać status na „wykonano / do odbioru” w swoim zakresie,
• nie może samodzielnie zamykać usterki ani zmieniać terminów odbioru bez zatwierdzenia.

W matrycy zapisujesz podwykonawcę jako R dla „usunięcia usterki” i ewentualnie C dla szacowania terminów, ale nigdy jako A.

Krok 2: ustal, jak szeroko podwykonawca widzi projekt. Minimum: tylko te usterki, zadania i odbiory, które są przypisane do jego firmy lub zakresu asortymentu. Dodatkowo można dopuścić widok usterek powiązanych z jego frontami robót, ale bez prawa edycji. W matrycy warto rozdzielić role:

• „podwykonawca – edycja swojego zakresu”,
• „podwykonawca – tylko podgląd sąsiednich branż”.

Krok 3: zdefiniuj, kto po stronie wykonawcy jest A dla działań podwykonawcy. Najczęściej to kierownik robót lub brygadzista, który formalnie akceptuje, że dana usterka jest usunięta i można wezwać inspektora do odbioru. Tę osobę trzeba wyposażyć w przyciski „zatwierdź do odbioru” i „odrzuć – wymagane poprawki”, widoczne tylko w jej profilu.

Typowy błąd: tworzenie jednego wspólnego konta „Podwykonawca” zamiast osobnych kont dla każdej firmy. W efekcie nie da się później odtworzyć, która ekipa realnie odpowiadała za konkretną usterkę.

Co sprawdzić: wybierz jednego podwykonawcę i przejdź jego ścieżkę: od otrzymania zgłoszenia do zamknięcia usterki. Sprawdź, czy w jakimkolwiek miejscu może on „przeskoczyć” rolę wykonawcy lub inspektora i sam zamknąć temat.

Bezpieczeństwo zmian w matrycy: kto może edytować zasady

Matryca odpowiedzialności sama w sobie jest krytyczną strukturą. Jeśli każdy administrator techniczny może ją dowolnie zmieniać, system przestaje być wiarygodny. Dlatego warto podejść do tego jak do zmian w kontrakcie.

Krok 1: wyznacz właściciela matrycy. To osoba (lub funkcja), która odpowiada za spójność ról i uprawnień – często kierownik projektu lub pełnomocnik ds. systemu jakości. W matrycy ustaw ją jako A dla wszelkich zmian ról i uprawnień.

Krok 2: rozdziel rolę administratora technicznego od roli decyzyjnej. Administrator systemu (IT) powinien mieć uprawnienia wykonawcze (R) wprowadzania zmian technicznych, ale nie decyzyjne w sensie biznesowym. Decyzja o tym, że np. kierownik robót dostaje prawo zatwierdzania odbiorów, powinna wyjść z zespołu projektowego, nie z działu IT.

Krok 3: włącz audyt zmian matrycy. Większość aplikacji pozwala śledzić, kto i kiedy zmienił uprawnienia. Upewnij się, że:

• logujesz zmiany ról i dostępów,
• masz możliwość przywrócenia poprzedniej konfiguracji,
• większe zmiany (np. dodanie nowej roli A) są zatwierdzane przynajmniej przez dwie osoby (np. kierownik projektu + przedstawiciel wykonawcy lub inwestora).

Typowy błąd: „tymczasowe” nadanie komuś pełnych praw administratora, aby coś „szybko kliknął”, bez późniejszego cofnięcia uprawnień. Po kilku miesiącach nikt już nie kontroluje, kto ma jakie przyciski.

Co sprawdzić: poproś administratora aplikacji o listę osób, które mogą zmieniać role i uprawnienia. Sprawdź, czy ta lista jest krótsza niż lista kierowników robót. Jeżeli jest dłuższa lub porównywalna – uszczelnij zasady.

Przeglądy matrycy w trakcie trwania kontraktu

Projekt budowlany się zmienia: pojawiają się nowi podwykonawcy, odchodzi kierownik robót, inwestor zatrudnia dodatkowego inspektora. Matryca i konfiguracja aplikacji musi za tym nadążać, inaczej prędzej czy później ktoś „z ulicy” zacznie zatwierdzać kluczowe decyzje.

Krok 1: wprowadź cykliczny przegląd ról. Dobrym rytmem jest raz na miesiąc lub raz na kwartał, powiązany z radą budowy. W czasie takiego przeglądu:

• porównujesz aktualną listę użytkowników z rzeczywistą strukturą organizacyjną,
• usuwasz konta nieaktywnych osób (np. byłych pracowników, podwykonawców, którzy zeszli z budowy),
• aktualizujesz przypisania R i A dla kluczowych procesów (usterek, odbiorów, zmian).

Krok 2: rejestruj decyzje o zmianach matrycy w protokołach. Krótka adnotacja w protokole rady budowy typu „od dnia X kierownik robót Y pełni funkcję A dla odbiorów branży Z” znacznie ułatwia później obronę decyzji, gdy pojawi się spór.

Krok 3: uruchom „checklistę wdrożeniową” dla nowych osób funkcyjnych. Przy zmianie kierownika budowy, inspektora nadzoru czy głównego projektanta zrób mini procedurę:

1. aktualizacja matrycy RACI (excel/diagram),
2. aktualizacja ról w aplikacji,
3. test jednej ścieżki: zgłoszenie usterki → zatwierdzenie przez nową osobę A.

Typowy błąd: skupienie się tylko na przekazaniu papierowej dokumentacji przy zmianie osób funkcyjnych, bez przełożenia zmian na system. W efekcie nowy kierownik budowy nadal nie ma przycisku „zatwierdź”, a stary – który jest już na innym projekcie – wciąż go ma.

Co sprawdzić: przy najbliższej zmianie osobowej (np. nowy kierownik robót) sprawdź, w ile dni od jego pojawienia się na projekcie dostał odpowiednie uprawnienia w aplikacji. Jeśli trwało to dłużej niż 1–2 dni, usprawnij procedurę.

Najczęściej zadawane pytania (FAQ)

Co to jest matryca odpowiedzialności w aplikacji nadzoru budowlanego?

Matryca odpowiedzialności w aplikacji to przejrzyste przypisanie ról do konkretnych kroków procesu: kto zgłasza, kto poprawia, kto zatwierdza i kto finalnie odpowiada za zamknięcie sprawy. Najczęściej opiera się na modelu RACI, ale przełożonym na realne zadania na budowie.

W praktyce oznacza to, że dla każdego typu zadania (np. zgłoszenie usterki, odbiór częściowy, inspekcja BHP) w systemie jest jasno ustawione: kto może zmienić status, kto ma przycisk „zatwierdź”, kto dostaje powiadomienia i kto jest właścicielem sprawy do samego końca.

Co sprawdzić: wybierz jeden typowy proces (np. zgłoszenie usterki) i sprawdź, czy jesteś w stanie jednym zdaniem odpowiedzieć: „ta rola w systemie musi doprowadzić sprawę do zamknięcia”. Jeśli nie – matryca jest niepełna.

Po co mi matryca odpowiedzialności, skoro wszyscy mają dostęp do aplikacji?

Sam dostęp do aplikacji nie rozwiązuje problemu „nikt się nie czuje odpowiedzialny”. Bez matrycy odpowiedzialności zgłoszenia krążą „do wszystkich”, zadania się dublują, a decyzje się rozmywają. Efekt: rośnie liczba komentarzy, a nie liczba zamkniętych usterek.

Matryca sprawia, że każde zgłoszenie ma swojego właściciela, a aplikacja pilnuje ścieżki: zgłoszenie → przypisanie → poprawka → weryfikacja → zatwierdzenie. Dzięki temu inspektor, kierownik budowy, wykonawca i inwestor widzą nie tylko, co się dzieje, ale też kto odpowiada za następny krok.

Co sprawdzić: weź losową usterkę z aplikacji i odpowiedz: „kto jest w systemie odpowiedzialny za doprowadzenie jej do zamknięcia?”. Jeśli odpowiedź brzmi „to zależy” albo „wszyscy”, matryca nie działa.

Jak krok po kroku wdrożyć matrycę RACI w aplikacji na budowie?

Krok 1: wybierz 3–5 kluczowych procesów, np. zgłoszenie usterki, odbiór częściowy, inspekcja zbrojenia, niezgodność BHP, raport dzienny. Krok 2: dla każdego procesu rozpisz po kolei kroki na kartce lub tablicy – od momentu zgłoszenia do zamknięcia w systemie.

Krok 3: do każdego kroku przypisz role R, A, C, I:

• R – kto realnie wykonuje czynność (w aplikacji lub w terenie),
• A – kto ostatecznie zatwierdza wynik dla tego kroku,
• C – z kim trzeba się skonsultować,
• I – kto ma być tylko poinformowany.

Następnie przełóż to na uprawnienia w aplikacji: kto może zmieniać status, kto widzi przycisk „zatwierdź”, kto ma tylko podgląd i powiadomienia.

Co sprawdzić: upewnij się, że dla każdego kroku masz tylko jedną rolę „A”. Dwie osoby „A” w jednym kroku to najkrótsza droga do blokady decyzji.

Jaka jest różnica między odpowiedzialnością prawną a operacyjną w aplikacji?

Odpowiedzialność prawna wynika z Prawa budowlanego, umów i uprawnień. Tego nie zmieni żadne ustawienie w systemie – kierownik budowy nadal odpowiada za prowadzenie budowy, inspektor nadzoru za kontrolę robót, a projektant za rozwiązania projektowe.

Odpowiedzialność operacyjna to to, co faktycznie robisz w aplikacji: kto zakłada zgłoszenie, kto zmienia status, kto wysyła raport, kto klika „zatwierdź zdjęcia”. Tu można delegować zadania (np. na koordynatora usterek), ale nie da się „przeklikać” na niego odpowiedzialności ustawowej kierownika budowy lub inspektora.

Co sprawdzić: dla każdej roli, którą tworzysz w aplikacji, zadaj pytanie: „czy to jest tylko wsparcie operacyjne, czy próba przeniesienia odpowiedzialności prawnej?” Jeżeli to drugie – konfiguracja wymaga korekty.

Jak sprawdzić, czy matryca odpowiedzialności w naszej aplikacji naprawdę działa?

Prosty test można zrobić w formie krótkiego warsztatu. Krok 1: na tablicy narysuj proces „od zgłoszenia usterki do jej zatwierdzenia w aplikacji”. Krok 2: poproś zespół (kierownik, inspektor, wykonawca), żeby nad strzałkami dopisał: kto w systemie wykonuje dany krok.

Krok 3: zaznacz różnymi kolorami: kto zgłasza, kto przekazuje, kto poprawia, kto zatwierdza, kto zamyka w systemie. Jeśli pojawiają się odpowiedzi „różnie bywa”, „wszyscy”, „to zależy od budowy”, to znak, że matryca nie jest ani pełna, ani dobrze zakomunikowana.

Co sprawdzić: po warsztacie od razu zaktualizuj role i uprawnienia w aplikacji i wyślij zespołowi prostą, 1‑stronicową ściągę „kto co robi w systemie” dla 2–3 głównych procesów.

Jak uniknąć sytuacji, że usterki „wiszą” tygodniami w aplikacji?

Klucz to jednoznaczne przypisanie właściciela sprawy i jasne reguły eskalacji. Krok 1: ustaw, aby każda nowa usterka automatycznie dostawała rolę „właściciel” (np. kierownik robót danego zakresu), a nie ogólne przypisanie „do wszystkich wykonawców”. Krok 2: zdefiniuj terminy realizacji i powiązane z nimi powiadomienia oraz eskalacje.

Dobry schemat to: po X dniach bez reakcji – automatyczne przypomnienie do właściciela, po Y dniach – eskalacja do kierownika budowy lub inspektora, po Z dniach – informacja do inwestora. Każdy wie, że usterka nie „zniknie” w systemie, bo aplikacja pilnuje jej cyklu życia.

Co sprawdzić: przeanalizuj kilka najstarszych otwartych usterek w systemie i odpowiedz: „czy w aplikacji jest jasno wskazany właściciel oraz termin realizacji?”. Jeśli brakuje choć jednego z tych elementów, konfiguracja wymaga poprawy.

Jak rozdzielić w aplikacji rolę „robi” od roli „zatwierdza” na budowie?

Na etapie konfiguracji ról w systemie przyjmij prostą zasadę: osoba „R” (robi) ma prawo edytować i aktualizować zadanie, ale nie ma przycisku ostatecznego zatwierdzenia; osoba „A” (zatwierdza) ma ograniczone możliwości edycji, za to decyduje o akceptacji lub odrzuceniu wyniku.

Przykład: wykonawca jako R dodaje zdjęcia z poprawki i zmienia status na „do odbioru”, a kierownik budowy lub inspektor jako A ma przycisk „zatwierdź / odrzuć”. Dzięki temu nie ma sytuacji, że ta sama osoba poprawia i sama siebie zatwierdza w systemie.

Najważniejsze punkty

• Matryca odpowiedzialności w aplikacji to klucz do uniknięcia „cyfrowego chaosu” – bez jasno wskazanego właściciela zgłoszenia usterki zadania się dublują, wiszą tygodniami i nikt nie czuje się zobowiązany do ich domknięcia.
• Trzeba wyraźnie rozdzielić odpowiedzialność prawną (wynikającą z Prawa budowlanego i funkcji na budowie) od operacyjnej w aplikacji; konfiguracja ról w systemie nie może sugerować, że ktoś jest zwolniony z ustawowych obowiązków tylko dlatego, że „nie klika” danego kroku.
• Każde zgłoszenie w systemie musi mieć jednoznacznego właściciela: krok 1 – ktoś zgłasza, krok 2 – ktoś poprawia, krok 3 – ktoś zatwierdza, krok 4 – ktoś zamyka w systemie; brak roli „A” (ostatecznie odpowiedzialnej) tworzy czarną dziurę w nadzorze.
• Przykład z nieszczelnym dachem pokazuje typowy błąd: zadanie wysłane „do wszystkich” oznacza w praktyce „do nikogo”, co kończy się realnymi szkodami na budowie, mimo że z technicznego punktu widzenia aplikacja działa bez zarzutu.
• Model RACI porządkuje role w aplikacji: krok 1 – określ, kto realnie wykonuje zadanie (R), krok 2 – przypisz jedną osobę lub rolę, która finalnie za to odpowiada (A), krok 3 – wskaż, z kim trzeba się konsultować (C) i kto ma być tylko informowany (I).