Asset registry jest kręgosłupem oprogramowania do przeglądów PPOŻ
Harmonogram działa dopiero wtedy, gdy system potrafi jednoznacznie określić, co jest przeglądane. Produkcyjna platforma PPOŻ potrzebuje więc canonical asset registry zanim dostanie kalendarze, dashboardy i templates PDF. Rejestr powinien łączyć organizację, obiekt, budynek/strefę, typ urządzenia, fizyczny identifier, dane producenta, wymagania serwisowe, historię przeglądów i dokumenty.
Polskie rozporządzenie PPOŻ, odczytywane łącznie ze zmianą z 2024 r., ustanawia dla urządzeń przeciwpożarowych i gaśnic ogólną regułę przeglądów i konserwacji zgodnie z właściwymi normami, dokumentacją techniczną i instrukcjami producenta, z ogólną minimalną częstotliwością raz w roku. Zmiana z 2024 r. wyłącza z ogólnej reguły §3 ust. 1–3 autonomiczne czujki dymu i tlenku węgla i odsyła ich utrzymanie do instrukcji producenta. System nie powinien więc sprowadzać polityki do jednej stałej „365 dni”: recurrence policy musi być wersjonowane według asset class i źródła reguły, wraz z wyjątkami, manufacturer instructions, kontraktem i właściwym standardem, a next due date powinien mieć provenance.
1. Każde fizyczne urządzenie potrzebuje stabilnego identity
Nie używaj etykiety „Hydrant 12” jako database key. Użyj immutable internal asset ID, a kod klienta, serial number, manufacturer reference, QR/barcode i visible label traktuj jako attributes. Zmiana naklejki nie może zerwać historycznych przeglądów.
2. Lokalizacja powinna być hierarchią, nie free text
Praktyczny model to customer → site → building → floor/zone → asset. GPS jest pomocniczym evidence, ale operational location musi być strukturalna, aby routować techników, grupować protokoły i zachować historię po zmianie nazwy obiektu.
3. QR otwiera kontekst assetu, ale nie omija authorization
QR/barcode jest identifierem i resolverem. Po skanie system znajduje canonical asset i dopiero potem stosuje permissions zalogowanego użytkownika. Sensitive state nie powinien być zakodowany bezpośrednio w QR.
4. Oddziel inspection requirement od work order
| Obiekt | Rola |
|---|---|
| Inspection policy | Dlaczego i kiedy asset wymaga konkretnego przeglądu |
| Due instance | Następne wymagane wystąpienie |
| Work order | Zadanie operacyjne dla technika |
| Inspection result | Checklist, pomiary, usterki i disposition |
| Protocol | Dokument wygenerowany z canonical result state |
Przesunięcie wizyty nie zmienia wtedy historii wymogu, a jedna wizyta może obejmować wiele assets bez łączenia ich identity.
5. Due dates potrzebują provenance
Zapisuj next-due date razem z policy version, inspection, które go wywołało, override reason i aktorem. Zmiana umowy lub interwału producenta może przeliczyć przyszłe zadania bez przepisywania historycznej podstawy.
6. Service history powinno być append-oriented
Korekta inspection tworzy wersję albo amendment. Zachowaj pierwotne measurements, defects, photos, technician identity, device identifiers, timestamps i document versions. Regenerowany protokół powinien wskazywać, którą wersję result reprezentuje.
7. Defects i remediation potrzebują własnego lifecycle
Nie chowaj usterek w PDF. Structured finding może mieć severity, evidence, recommendation, owner i stan open → quoted → approved → repaired → verified. Wtedy system staje się operating systemem, a nie archiwum.
8. Protokoły generuj z canonical state
PDF service powinien czytać finalized inspection result, a nie chwilowe wartości formularza. Dostaje versioned result i template version, generuje dokument, zapisuje hash/object ID i linkuje go do assetu i inspection.
9. First-party production pattern
W systemie TECHPRES łączymy asset registry, pracę techników, measurements, protocols i service history. Ten sam graph wspiera planowanie i późniejsze odtworzenie evidence. Wdrożenia: Fire Safety & Inspection Software Development.
Checklist asset registry
- Immutable internal asset ID.
- Strukturalna hierarchia site/building/zone.
- QR/barcode jako resolver z authorization.
- Versioned inspection policies i due-date provenance.
- Oddzielone work orders i inspection results.
- Structured findings/remediation.
- Append-oriented service history i protocol versions.