Digitális terv a telepen: PDF-től a friss verzióig (WhatsApp nélkül)

Miért bukik a WhatsApp-PDF a telepen

Az építésvezető és a tűzjelző / gyengeáram install PM ismeri a mintát: reggel jön a „küldd a legfrissebb tervet” üzenet, délután kiderül, hogy a brigád a tegnapi PDF-re fúrt, este pedig a megrendelő kérdezi, miért nem a C verzió szerint ment a kábelezés. A WhatsApp nem tervkezelő — chat, fájldoboz és emlékezet keveréke.

Egy 15–40 fős install projekt tipikusan 8–20 tervlapot mozgat (alaprajz, szinti elrendezés, kábelnyomvonal, eszközlista). Ha ezek chatben mennek, 1–2 hét alatt 3–5 párhuzamos „igazság” keletkezik: a projektvezető laptopján, a brigádvezető telefonján, az alvállalkozó e-mail mellékletében. A punch list fotók és a „itt legyen a jelző” megjegyzések elválnak a rajztól — nem pin, hanem chat-lánc.

A költség nem csak a javítás: 1 rossz verzióra telepített detektor-sor átmozgatása 4–12 munkaórát, plusz anyag- és belépési kört vihet el. A rejtett veszteség a bizalom: a megrendelő azt látja, hogy „a csapat nem a terv szerint dolgozik”, pedig a terv forrása volt a gyenge láncszem. A WhatsApp-PDF akkor bukik, amikor a döntés a telepen kell, és a forrás nem egyértelmű.

• →Több fájlnév = több „igazság” (final, final2, asbuilt_jav, PDF a chatből)
• →Nincs kötelező verziószám, időbélyeg és felelős a feltöltésnél
• →A punch / hibajegy nem a terven van, hanem a chatben — nem kereshető a pin
• →Alvállalkozó később kapja a frissítést, mint a saját brigád

Verziókezelés és as-built: egy forrás, nem 3 PDF

A digitális terv alapja a számozott verzió: V1 (tervezői kiadás), V2 (műszaki egyeztetés után), V3 (telepi változások), majd as-built zárás. Minden feltöltésnek van időbélyege, feltöltője és — ha kell — megjegyzése („szinti elrendezés, 2. emelet, megrendelői módosítás”). A brigád a „aktuális” jelölésű lapot látja alapértelmezetten; a régi verzió archiválva marad, nem törlődik.

A verzió-összehasonlítás (overlay) az a funkció, ami a telefonos „melyik a frissebb?” vitát 30 másodpercre csökkenti: a két PDF/kép egymásra vetítve mutatja, hol mozdult fal, ajtó, tűzjelző pont vagy oltóberendezés. Install PM-ként ez a nap 3–5 alkalommal jön elő — különösen, ha a generálkivitelező közben építészeti változtatást kapott.

Az as-built nem „majd a végén beszkenneljük a piros ceruzás rajzot”. A telepi pin, a rétegek (feladatok, rajzjelölés, szöveg) és a fotógaléria folyamatosan építik a valós állapotot. Tűzjelző / oltás szimbólumokkal a terven rögzíthető, hol lett ténylegesen a detektor, a kézi jelzésadó, a hang-fény jelző vagy a sprinkler / gázzal oltó elem — és ez a záráskor a megrendelőnek is átadható forrás, nem chat-export.

Gyakorlati szám: ha egy projekt 12 tervlapot és átlag 4 verziót mozgat, az 48 „fájl-állapot”. Chatben ez káosz; verziókezelt rendszerben 12 lap × 1 aktuális + történet. A különbség a punch list zárásánál és a hatósági / megrendelői átadásnál jön vissza: 1 forrás, nem mappa-vadászat.

• →PDF vagy kép feltöltés (asztali és mobil) — a terv ott keletkezik, ahol a fájl van
• →Verziók: aktuális + archív, feltöltővel és dátummal
• →Verzió-összehasonlítás overlay-jel a változások gyors ellenőrzéséhez
• →Rétegek: feladatok, rajzjelölés, szöveg; szimbólumok tűzjelző / oltáshoz
• →Pin a terven + eszköz elhelyezés + fotógaléria = élő as-built alap

Offline és terepi elérés: a pince nem zárhatja le a tervet

A telep realitása: gyenge térerő a mélygarázsban, a szerverszobában, a csarnok közepén, a felújítás alatti épületben. Ha a terv csak online PDF-link, a brigád visszaesik a lementett fájlra — és a verziókezelés ott el is veszett. Az offline elérés azt jelenti, hogy a letöltött aktuális terv, a pin-ek és a saját feladatok a tableten / telefonon elérhetők hálózat nélkül is.

A terepi munkafolyamat: megnyitod a lapot → ránagyítasz a zónára → pin a feladathoz (felelős, státusz, határidő) → fotó a hibáról vagy a kész állapotról. Amint van hálózat, a szinkron feltolja a változásokat. Az építésvezető az irodában vagy a másik szárnyban ugyanazt a forrást látja — nem vár 2 óráig egy „elküldtem a képet a csoportra” üzenetre.

Célidők, amiket a jó terepi rendszernek ki kell bírnia: 10 másodperc alatt a saját feladatlista, 30 másodperc alatt a friss tervlap a tableten (ha már szinkronban volt), és 1 koppintás a pin részleteire. Ha a brigád 3 percet küzd a fájlkereséssel, vissza fog térni a WhatsApphoz — a digitális terv nem „szép demó”, hanem gyorsabb, mint a chat.

Mappa struktúra multi-site projekteknél

Egy install cég nem egy telepet futtat: 5–30 párhuzamos helyszín, eltérő megrendelők, eltérő tervkészletek. Ha minden PDF egy „Tervek 2026” mappában van a meghajtón, a multi-site káosz elkerülhetetlen. A mappa / projekt struktúra legyen a valós hierarchia: megrendelő → telephely / épület → szint / zóna → tervlap típus (építészet, gyengeáram, tűzjelzés, gépészet).

Ajánlott elnevezési minta (egyszerű, de konzisztens): `MEGRENDELO_TELEPHELY_SZint_TIPUS_V0x` — pl. `ACME_HQ_2E_TUZJELZO_V03`. A digitális rendszerben a verziószám a metaadat, nem a fájlnév vége; a fájlnév stabil lehet, a „aktuális” státusz a rendszeré. Multi-site-nál a jogosultság is a struktúrához kötődik: a brigád csak a rá bízott telephelyeket látja, a regionális PM többet, a központ mindent.

Heti ritmus, ami működik 10+ helyszínnél: hétfő reggel 15 perc — melyik telephelyen van új tervkiadás, hol van open punch >X, hol kell as-built zárás a héten. Ha ez a lista chatből jön, 40 perc; ha a projektek listájából, 10. A mappa struktúra nem bürokrácia — ez a skála feltétele.

• →Hierarchia: megrendelő → telephely → szint/zóna → tervlap
• →Stabil fájlnév + rendszerbeli verzió (ne „final_final2”)
• →Telephelyenkénti hozzáférés: brigád ≠ minden projekt
• →Heti 15 perces multi-site áttekintés: új verzió, open pin, zárás

Megrendelő vs kivitelező jogosultság: egy terv, két szerep

A megrendelő (építtető, FM, generál) gyakran adja a „hivatalos” alaprajzot; a kivitelező / alvállalkozó azon dolgozik, pinel, fotóz, as-builtot épít. A hiba akkor jön, ha mindkét oldal ugyanazzal a szerkesztő joggal rendelkezik, vagy fordítva: a kivitelező nem tud pinelni, mert „csak PDF-et kapott”. A helyes modell: a megrendelő a terv tulajdonosa (feltöltés, verzió jóváhagyás, olvasás), a kivitelező a telepi munkavégző (pin, fotó, réteg-jelölés, saját feladatok) — szabályozott hozzáféréssel.

Gyakorlati szabályok: (1) terv feltöltés / új verzió = megrendelő vagy megbízott PM; (2) pin és punch = kivitelező brigád + építésvezető; (3) as-built zárás = közös, de a megrendelő fogadja el; (4) alvállalkozó csak a rábízott zónákat és rétegeket látja. Így a generál nem fél megosztani a tervet, a szakági install pedig nem WhatsAppból kéri a friss lapot.

Tűzjelző / oltás installnál ez különösen fontos: a megrendelői alaprajzra kerülnek a szimbólumok és az eszköz pozíciók, a szerviz később ugyanezt a forrást használhatja (eszközkezelés / CMMS irányba). A jogosultság tehát nem IT-dísz — hanem a szerződéses felelősség leképezése a telepi appban.

12 pontos bevezetési checklist (PDF-től a friss verzióig)

Ne „majd digizáljuk a terveket” — futtasd le ezt a 12 pontot egy élő projekten 5–10 munkanap alatt. Ha a 12-ből 10 megvan, a WhatsApp-PDF már nem a fő forrás.

• →1. Válassz 1 pilot projektet (1 telephely, 1–2 szint, max 15 tervlap) — ne az egész cég portfólióját.
• →2. Gyűjtsd össze az „igaz” tervforrást: megrendelői kiadás + utolsó ismert módosítás; a chatből jött PDF-eket jelöld gyanúsnak.
• →3. Töltsd fel a lapokat (PDF/kép), nevezd el egységesen, állítsd be a V1-et és az „aktuális” jelölést.
• →4. Definiáld a szerepeket: ki tölthet fel új verziót, ki pinelhet, ki csak olvashat (megrendelő / PM / brigád / alvállalkozó).
• →5. Hívd meg a brigádot és az alvállalkozót a telephelyhez — ne küldj többé tervet chatben „csatolmányként”.
• →6. Telepítsd a mobil/tablet appot; töltsd le a terveket offline-hoz a telepi nap előtt.
• →7. Pineld az első 10–20 feladatot a tervre (punch, hiány, szerelési pont) — felelős + határidő kötelező.
• →8. Használj szimbólumokat tűzjelző / oltás / eszköz pozícióhoz, ahol a szakág ezt kéri; fotó a pinhez.
• →9. Az első tervmódosításnál tölts fel V2-t, futtass verzió-összehasonlítást a csapattal (5 perc standup a tabletnél).
• →10. Heti zárás: open pin-ek, elavult verzió tiltása, as-built réteg ellenőrzés — 20 perc, nem 2 óra chat.
• →11. Multi-site előtt: másold a mappa / elnevezési mintát a 2. telephelyre; jogosultság telephelyenként, ne globálisan.
• →12. Záráskor: as-built export / átadás a megrendelőnek egy forrásból; a WhatsApp-csoportot vedd le a „hivatalos terv” szerepről.

Összegzés és következő lépés

A cikkben összefoglalt gyakorlati lépések akkor működnek tartósan, ha egy központi rendszerben futnak a munkalapok, az eszköznyilvántartás, a preventív ütemezés és — ahol kell — a tűzvédelmi ellenőrzések is. A szétszórt Excel-fájlok és papír naplók hosszú távon nem adják az auditálhatóságot és a valós idejű átláthatóságot.

A SafetyPro CMMS ezeket egy platformon egyesíti: QR/NFC azonosítás, mobil app offline módban, riportok és emlékeztetők. A Basic csomag 24 900 Ft/hó-tól indul; 14 napos ingyenes próba egyeztethető személyesen, a bemutató után.

Ha a témában leírt folyamatokat szeretnéd élesben látni a saját telephelyed példáján, kérj bemutatót — az értékesítési csapat általában 1 munkanapon belül válaszol.