Megrendelő és kivitelező egy terven: jogosultság multi-party projekten

Miért két Excel és három PDF verzió

Egy tipikus multi-party projekt 3–5 szereplőt érint: megrendelő (üzemeltető), fővállalkozó, 1–3 szakági alvállalkozó, esetenként külső service. A terv PDF e-mailben megy, a punch list WhatsApp-on, a zárási lista Excelben — és 2–3 napon belül senki nem tudja, melyik a „legfrissebb”.

A verziókaosz nem IT-probléma: ha a telepen a B-revíziós rajz van, az irodában pedig a C, a pinelt hibák és a fotók a rossz vonalhoz kötődnek. Egy 40–80 pontos punch listnál ez 15–30% újraellenőrzést jelent, mert a felek nem ugyanazt a forrást nézik.

A megoldás nem „még egy közös mappa”, hanem egy telephelyhez kötött, multi-tenant terv: a megrendelő a tulajdonos, a kivitelező meghívott fél. Egy aktív tervverzió, közös feladatlista, közös fotók — és mindenki csak annyit lát, amennyit a szerződés és a szerepkör megenged.

Ki mit láthat: megrendelő / fővállalkozó / alvállalkozó

A multi-party modell lényege: a telephely a megrendelő szervezeti terében él, a kivitelező nem kap „második fiókot” a teljes adatállományra. Meghívás után a rendszer telephely-szintű hozzáférést ad (can_access_site jellegű szabály): a meghívott csak az adott site-on dolgozhat, más telephelyeket nem lát.

A szerepkörök tipikusan három szintre esnek. Megrendelő / tulajdonos: teljes terv, eszközpark, munkalap-előzmény, meghívások és jogosultságok kezelése, audit log. Fővállalkozó: tervverzió feltöltés, feladatok pinelése és kiosztása, fotó, zárási lista — de a megrendelő más telephelyei és a pénzügyi/üzemeltetési belső adatok nem. Alvállalkozó: csak a rákiosztott feladatok, a saját pinjei és a szükséges tervréteg; teljes eszközleltár és idegen brigádok naplója nem.

Az eszközláthatóság külön szabály: a kivitelező gyakran csak a projekthez tartozó berendezéseket (pl. telepített tűzjelző zónák, új gépcsoport) láthatja, nem a megrendelő teljes 2000+ eszközös parkját. Ha ezt nem szűrik, a leggyakoribb panasz nem a „lassú app”, hanem a „túl sok idegen adat”.

• →Megrendelő: telephely tulajdonos, meghívás, teljes audit, eszközpark
• →Fővállalkozó: tervverzió, pin/feladat, fotó, zárás — csak a meghívott site-on
• →Alvállalkozó: kiosztott feladatok + szükséges tervnézet, szűk eszközkör
• →Service / meghívott karbantartó: munkalap a ráruházott eszközökön, nem teljes CMMS admin

Terv + feladat + fotó egy forrásból

A multi-party projekt akkor működik, ha a terv PDF, a pinelt feladat és a helyszíni fotó ugyanarra a telephely-terv objektumra hivatkozik. A kivitelező a megrendelő tervén helyezi el a feladatot — nem külön „saját” projektklónban, ahonnan később exportálni kell.

A tervverzió feltöltés is jogosultsághoz kötött: csak az a fél tölthet fel új revíziót, akinek van telephely-hozzáférése és megfelelő szerepe. A régi verzió nem törlődik el: a pin-ek verzióhoz vagy aktív tervhez igazodnak, így visszakereshető, melyik rajzon rögzült a hiba. Offline terepen a tablet a legutóbb letöltött verzióval dolgozik; szinkron után a frissebb revízió felülírja a cache-t.

Gyakorlati számok: ha 1 aktív tervverzió van a 3 helyett, a „küldd a legfrissebbet” e-mailek 70–90%-a eltűnik. Ha a punch list pin a rajzon él (nem Excel-sor), a lezárási kör 1–2 nappal rövidül 20–50 tételes listánál, mert a megrendelő és a kivitelező ugyanazt a státuszt látja.

Audit: ki mit módosított

Enterprise multi-party környezetben az audit nem „extra”: ha vita van egy zárási tételről, a kérdés nem az, hogy „ki emlékszik”, hanem hogy a napló mit mutat. Ki töltötte fel a C-revíziót, ki pinelte a 14-es hibát, ki zárta le fotóval, ki módosította a határidőt.

A activity log multi-tenant szűrése kulcs: a megrendelő a saját telephelyén látja az összes meghívott fél eseményeit; a meghívott kivitelező csak a saját (és a ráruházott) műveleteit a meghívott site-on — nem a megrendelő más projektjeinek naplóját. Így a napló nem válik adatszivárgássá, de a projekt auditálható marad.

Minimális naplózandó események: meghívás és jogosultságváltozás, tervverzió feltöltés/aktiválás, feladat létrehozás–módosítás–lezárás, fotó/csatolmány, státuszváltás. Időbélyeg + felhasználó + telephely nélkül a „bizonyíték” nem áll meg egy szerződéses vitában vagy belső ellenőrzésen.

Szolgáltatói szerződés ↔ szoftver jogok

A szoftverjogok nem élhetnek a szerződés mellett — a szerződésből kell következniük. Ha a szolgáltatói megállapodás azt mondja: „a kivitelező a 3. emeleti géptermi zónában dolgozik, 90 napig, zárási listával”, akkor a meghívás, a telephely-hatókör, az eszközszűrés és a lejárat ugyanezt kell tükrözze.

Gyakorlati leképezés: szerződéses hatókör → meghívott telephely(ek); felelősségi kör → szerepkör (fővállalkozó vs. alvállalkozó vs. service); időtartam → meghívás lejárata vagy projektlezárás utáni csak-olvasható mód; adathozzáférés → eszközláthatóság és naplószűrés. Ha a szerződés 12 eszközt nevez meg, a szoftverben ne legyen „teljes telephely szerkesztő” jog.

A SafetyPro multi-tenant modellje erre épül: a megrendelő telephelyére meghívott kivitelező a tulajdonos tervén helyezhet el feladatot, verziót tölthet fel a telephely-hozzáférés (can_access_site) szabályai szerint, és az eszközök láthatósága a ráruházott hatókörre szűkül — nem kell külön, párhuzamos adatbázis. A platform célja a közös munka szűk jogokkal, nem a „mindenki mindent lát” kényelem.

Gyakori hibák + jogosultsági checklist

A leggyakoribb multi-party hiba a túl tág jogosultság: a kivitelezőt „adminnak” veszik fel a megrendelő szervezetébe, hogy „gyorsan menjen”. Eredmény: látja a többi telephelyet, más szolgáltatók naplóit, esetleg a teljes eszközparkot. A második hiba a meghívás lejáratának hiánya — a projekt lezárult, a hozzáférés él. A harmadik: nincs szerepkör-szétválasztás fővállalkozó és alvállalkozó között, így mindenki pinel és zár, de senki nem felelős.

Az alábbi checklist a szerződés → szoftver leképezés minimuma. Ha egy sor üres, a multi-party projekt adatkockázatot visz, nem csak koordinációs előnyt.

• →Megrendelő = telephely tulajdonos; kivitelező = meghívott, nem org-admin
• →Hozzáférés telephely-szintű (can_access_site), nem szervezet-szintű „minden site”
• →Szerepkör: megrendelő / fővállalkozó / alvállalkozó / service — külön jogmátrix
• →Tervverzió feltöltés: csak kijelölt szerep; régi verzió auditálhatóan megmarad
• →Feladat pin a megrendelő tervén; alvállalkozó csak kiosztott tételeket zár
• →Eszközláthatóság: csak projekthez / szerződéshez tartozó berendezések
• →Activity log: megrendelő látja a site összes eseményét; meghívott csak a saját hatókörét
• →Meghívás lejárata vagy projektzárás utáni csak-olvasható / visszavonás
• →Nincs megosztott jelszó / közös fiók — minden személy külön user
• →Negyedéves jogosultság-review: ki van még meghívva, miért, milyen szereppel

Ö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.