Prieš pateikdami užklausą dėl išmaniojo užrakto su nuotoline prieiga, nuosavybės valdytojai turėtų priskirti atsakomybę už penkis veiksmus: atrakinimą, vartotojų patvirtinimą, administratorių nustatymą iš naujo, kredencialų atšaukimą ir prieigos įrašų peržiūrą. Kiekvienam veiksmui reikia įvardinto vaidmens, apibrėžtos apimties, patvirtinimo taisyklės ir perdavimo procedūros. RFQ taip pat turėtų reikalauti konkretaus modelio įrodymų, kad siūloma užrakto ir valdymo platforma gali palaikyti tuos valdiklius.
„Nuotolinė prieiga“ nėra išsami specifikacija. Vienas tiekėjas gali tai interpretuoti kaip programėlėmis pagrįstą vartotojų valdymą šalia durų, o kitas – atrakinimą ne svetainėje per prijungtą sistemą. Todėl citata gali atrodyti atitinkanti reikalavimus, net jei ji neatitinka nuosavybės darbo eigos. Pirkimo komandos pirmiausia turėtų apibrėžti leidimo modelį, tada paprašyti tiekėjų patvirtinti, kurios funkcijos yra pasiekiamos konkrečiame užrakte, programėlėje, šliuzuose arba valdymo konfigūracijoje.
Pradėkite nuo veiksmų, o ne nuo pareigų
Pavadinimas, pvz., „administratorius“, mažai pasako apie tai, ką tas asmuo iš tikrųjų gali daryti. Viešbučio vadovui gali reikėti leisti vienkartinį atrakinimą, tačiau jis nebūtinai turi turėti galimybę perduoti sistemos nuosavybės teisę. Buto nuomos komanda gali sukurti nuomininko prieigą, tačiau neturi priežasties keisti įrenginio nustatymų. Techninės priežiūros personalui gali prireikti ribotą laiką patekti į priskirtas patalpas be matomumo į kitus gyventojus ar nuosavybę.
Pirmasis RFQ priedas turėtų būti atsakomybės matrica. Toliau pateikta matrica yra planavimo modelis, o ne teiginys, kad kiekvienas su programa prijungtas užraktas apima visas išvardytas funkcijas. Pirkėjai turėtų ištrinti nesusijusias eilutes ir reikalauti, kad tiekėjas pažymėtų kiekvieną likusią funkciją kaip palaikomą, nepalaikomą arba priklausomą nuo papildomo komponento.
| Nuotolinės prieigos veiksmas | Sprendimas apibrėžti prieš RFQ | Tipiškas projekto valdymas | Įrodymai prašyti |
| Nuotolinis atrakinimas | Kokie vaidmenys gali atrakinti kokius kambarius ir kokiomis aplinkybėmis? | Apriboti prieigą pagal nuosavybę, pastatą, aukštą, kambarį, pamainą ar incidento tipą. | Vaidmenų leidimo ekranas, naudojimo instrukcijos ir pavyzdžio priėmimo testas. |
| Atrakinti patvirtinimą | Ar vienas asmuo gali veikti vienas, ar kitas vaidmuo turi patvirtinti prašymą? | Naudokite antrąjį patvirtinimą jautrioms patalpoms arba po darbo valandų išimtims, kai to reikia projektui. | Tiekėjo patvirtinimas dėl nurodytos konfigūracijos galimos patvirtinimo darbo eigos. |
| Vartotojo arba kredencialų kūrimas | Kas gali pridėti darbuotojų, svečių, nuomininkų, rangovų ar laikinų naudotojų? | Atskirkite įprastą prieigą prie kambario nuo administratoriaus kūrimo. | Naudotojų vaidmenų, galiojimo laikotarpių ir patalpų priskyrimo valdiklių demonstravimas. |
| Kredito atšaukimas | Kas pašalina prieigą po apmokėjimo, nuomos sutarties nutraukimo, darbuotojų išvykimo ar pamesto telefono? | Kiekvienam įvykiui priskirkite atsakymo savininką ir reikiamą užbaigimo tašką. | Atšaukimo procedūra ir įrodymas, kad prieigos pašalinimas gali būti patikrintas prie paveikto užrakto. |
| Administratoriaus nustatymas iš naujo | Kas gali iš naujo nustatyti užraktą arba paskyrą ir kas leidžia atlikti šį veiksmą? | Iš naujo nustatyti įgaliojimus laikykite siauresnius nei įprastinės vartotojo valdymo teisės. | Konkrečiam modeliui skirtos atstatymo instrukcijos ir pakartotinio eksploatavimo kontrolinis sąrašas po nustatymo. |
| Prieiga prie įrašo peržiūros | Kurie vaidmenys gali peržiūrėti ar eksportuoti įrašus, kurioms durims ir kokiu tikslu? | Apribokite matomumą iki mažiausio projekto reikalaujamo veikimo. | Tiekėjo patvirtinimas apie įrašų laukus, prieinamumą, saugojimo valdiklius ir eksportavimo parinktis. |
| Sistemos nuosavybės perdavimas | Kas valdo po įdiegimo ir kaip pašalinamos montuotojo teisės? | Padarykite galutinį nuosavybės perdavimą dokumentais patvirtintu priėmimo etapu. | Perdavimo procedūra, rodanti paskyros perkėlimą, kredencialų pašalinimą ir pirkėjo patvirtinimą. |
Apibrėžkite leidimo apimtį durų ir portfelio lygiu
Leidimas naudingas tik tada, kai jo taikymo sritis yra aiški. „Turto valdytojas gali atrakinti duris“ gali reikšti vieną priskirtą butą, kiekvieną vieno pastato kambarį arba visą portfelį. Šis skirtumas turi įtakos eksploatavimo rizikai ir neturėtų būti paliktas montuotojui nuspręsti pradedant eksploatuoti.
Kiekvienam vaidmeniui nurodykite leistinas savybes, pastatus, aukštus, patalpas ir laiko langus. Taip pat nurodykite, ar vaidmuo gali perduoti prieigą kitam asmeniui. Jei delegavimas leidžiamas, nurodykite, kas gali jį patvirtinti ir kada jis baigiasi. Regioniniam administratoriui gali prireikti matomumo keliose svetainėse, o vietos valdytojui gali prireikti įgaliojimų tik vienoje vietoje. Kiekvieno leidimo centralizavimas gali supaprastinti priežiūrą, bet taip pat sukuria didesnį poveikį, jei viena paskyra tvarkoma netinkamai. Vietinė kontrolė susiaurina tą poveikį, bet gali sulėtinti palaikymą, kai vietoje nėra įgalioto asmens.
Ta pati apimties logika turėtų būti taikoma ir nuosavybės pakeitimams. Kai kambarys pakeičiamas iš ilgalaikės nuomos į trumpalaikį naudojimą, reikalinga kredencialų darbo eiga gali pasikeisti, net jei fizinis užraktas išlieka. Pirkėjai peržiūri valdomų nuosavybių išmaniojo užrakto parinktys todėl veikimo modelį reikėtų palyginti taip pat atidžiai, kaip rankeną, apdailą ar atrakinimo būdą.
Atskirkite įprastinę prieigą nuo išskirtinės prieigos
Įprastinė prieiga apima suplanuotus įvykius, tokius kaip svečių atvykimas, nuomininko persikėlimas, namų tvarkymas, apžiūra ar suplanuota priežiūra. Išskirtinė prieiga apima blokavimą, gerovės patikrinimus, sugadintus telefonus, tinklo pertrūkius, darbuotojų nebuvimą ir kitus incidentus, dėl kurių reikia kontroliuojamo nukrypimo nuo įprastos darbo eigos.
Projekto specifikacijoje turėtų būti nurodytas išimties savininkas, įrodymai, kurių reikia prieš atrakinant, ir po to sukurtas įrašas. Taip pat turėtų būti nurodyta, kas atsitiks, jei nuotolinė funkcija nepasiekiama. Priklausomai nuo pasirinkto modelio, atsarginis gali būti slaptažodis, piršto atspaudas, kortelė, mechaninis raktas, vietinis administratorius arba kitas patikrintas metodas. Visame gaminių asortimente neturėtų būti laikomasi atsarginių priemonių; „Haolock“ produktų sistemoje yra keletas atrakinimo ir valdymo parinkčių, tačiau galimas derinys turi būti patvirtintas pagal modelį.
Šis skirtumas neleidžia kasdienei patogumo funkcijai tapti nekontroliuojamu pagrindinės prieigos keliu. Taip pat tiekėjui pateikiamas išbandomas reikalavimas: pademonstruoti įprastą darbo eigą, pademonstruoti išimties darbo eigą ir parodyti, kaip po incidento sistema grįžta į įprastą valdymą.
Patvirtinkite tikslią produkto ir valdymo konfigūraciją
Fizinis užraktas ir nuotolinio valdymo įrenginys turėtų būti patvirtinti kaip viena konfigūracija. The 1023 juodas slaptažodžio ir pirštų atspaudų užraktas, pvz., pateikiama butų, namų, nuomojamų kambarių, nakvynės namuose ir valdomos prieigos projektų sąraše. Jo dokumentuoti gaminio duomenys patvirtina juodo nerūdijančio plieno korpusą, šlifuotą apdailą, 330 × 42 × 22 mm matmenis ir slaptažodžio bei pirštų atspaudų identifikavimą.
Šie faktai savaime nenustato nuotolinio atrakinimo, paskyros hierarchijos, šliuzo reikalavimų, įrašų pasiekiamumo ar programos veikimo. Jei pirkėjas nori šio modelio arba bet kokios pasirinkimo iš pirštų atspaudų išmaniųjų užraktų diapazonas— naudojant nuotolinį valdymą, tiekėjas pasiūlyme turėtų nurodyti tikslų variantą ir kiekvieną pagalbinį komponentą. Ta pati taisyklė galioja ir vertinant slaptažodžio išmaniųjų užraktų diapazonas: klaviatūra arba laikino slaptažodžio funkcija neturėtų būti traktuojami kaip administravimo už svetainės ribų įrodymas.
Paprašykite tiekėjo nurodyti, ar kiekviena pageidaujama funkcija atliekama prie užrakto, per telefoną prie užrakto, per šliuzą ar per kitą valdymo sąsają. Šis vienintelis paaiškinimas gali atskleisti paslėptus kainų skirtumus tarp citatų ir neleisti patvirtinti pavyzdinės konfigūracijos pagal prielaidas, kurios neįtraukiamos į masinį užsakymą.
Perdavimas ir atšaukimas yra priėmimo dalis
Nuotolinės prieigos valdymas dažnai nepavyksta perėjimo metu, o ne įprasto naudojimo metu. Montuotojai išeina, darbuotojai keičia vaidmenis, nuomininkai išsikrausto, keičiasi nekilnojamojo turto operatoriai arba prarandamas su administratoriaus paskyra susietas telefonas. Prieš pradedant diegimą, projektui reikia apibrėžto atsakymo kiekvienam įvykiui.
Galutinis priėmimas turėtų patvirtinti, kad pirkėjas valdo numatytą administratoriaus paskyrą, pašalintos neteisėtos sąrankos paskyros, kiekvienas vaidmuo turi patvirtintą durų apimtį ir gali būti sukurtas bei atšauktas bandomasis kredencialas. Jei projektui reikalingi prieigos įrašai, priėmimo komanda taip pat turėtų patikrinti, ar numatytas tikrintojas gali gauti reikiamą informaciją, o nesusiję vartotojai negali. Įrašų saugojimas ir eksporto elgsena turėtų būti patvirtinta atsižvelgiant į paties projekto veiklos ir teisinius reikalavimus, o ne prielaidą.
Kelių svetainių projektams paskirkite paskyros savininką ir atkūrimo kontaktinį asmenį. Tai neturėtų būti laikinieji montuotojai ar pavieniai darbuotojai, kuriems išvykus turtas liktų be administracinės kontrolės. Taip pat reikalingas dokumentuotas pakeitimo procesas: bet koks vėlesnis leidimo išplėtimas turėtų identifikuoti, kas to paprašė, kas jį patvirtino, kurios durys buvo paveiktos ir kada pakeitimas buvo išbandytas.
Ką tiekėjas turėtų patvirtinti dėl RFQ?
| RFQ įvestis | Informacija, kurią turi pateikti Pirkėjas | Reikalingas tiekėjo atsakymas |
| Turto ir durų grafikas | Aikštelių skaičius, pastatai, kambariai, durų tipai, durų storiai ir reikalingi spynų kiekiai. | Suderinamas spynos modelis, spynos korpuso išdėstymas ir visa reikalinga informacija apie duris. |
| Leidimų matrica | Vaidmenys, leidžiami veiksmai, durų apimtis, laiko apimtis, patvirtinimo taisyklės ir delegavimo ribos. | Palaikomos funkcijos, apribojimai ir visos funkcijos, kurioms reikalingas kitas modelis ar komponentas. |
| Ryšio planas | Kur reikalingas nuotolinis valdymas ir koks ryšys yra kiekvienoje nuosavybėje. | Kaip perduodama nurodyta konfigūracija ir kokio papildomo įrenginio ar sąrankos reikia. |
| Atsarginė procedūra | Kam reikalinga skubi prieiga ir kokius neprisijungus ar vietinius metodus projektas priims. | Galimi atsarginiai tikslaus modelio metodai ir normalaus valdymo atkūrimo procedūra. |
| Perdavimo paketas | Pavadintas administratoriaus savininkas, atkūrimo kontaktas, darbuotojų vaidmenys, mokymo auditorija ir reikalingi dokumentai. | Sąrankos instrukcijos, nustatymo iš naujo procedūra, nuosavybės perdavimo veiksmai ir vaidmens konfigūracijos įrašai. |
| Priėmimo testas | Durų, vartotojų vaidmenų, leidžiamų, draudžiamų veiksmų ir patvirtinimo/nepatikimo kriterijų pavyzdžiai. | Mėginio tyrimo metodas ir sutartas pristatytos partijos patikros metodas. |
Tiekėjo atsakyme turėtų būti atskirtos standartinės funkcijos nuo pasirenkamų funkcijų ir nustatomos priklausomybės. „Palaikoma programa“ nepakanka, jei užklausa klausia, kas gali nuotoliniu būdu atrakinti, ar yra patvirtinimo veiksmas, kaip atšaukiama prieiga arba kaip perduodama nuosavybės teisė po paleidimo. Citata turėtų atsakyti į šiuos klausimus, palyginti su nurodytu modeliu ir konfigūracija.
Klausimai, kuriuos dažnai užduoda nekilnojamojo turto valdytojai
Ar kiekvienas nekilnojamojo turto valdytojas turėtų gauti nuotolinio atrakinimo leidimą?
Ne. Leidimas turi atitikti veiklos atsakomybę, durų apimtį ir incidentų procedūras. Kai kuriems valdytojams gali tekti tik išduoti arba atšaukti kredencialus, o mažesnė grupė tvarko išskirtinius nuotolinio atrakinimo veiksmus.
Ar programų valdymas visada reiškia nuotolinį atrakinimą ne svetainėje?
Ne. „Programų valdymas“ gali apibūdinti skirtingas ryšio ir valdymo priemones. Pirkėjai turėtų paprašyti tiekėjo nurodyti, kur turi būti vartotojas, kaip užraktas bendrauja ir kokių papildomų komponentų reikia.
Ar produkto puslapis gali įrodyti, kad užraktas palaiko reikiamą leidimų hierarchiją?
Nebent puslapyje arba patvirtinamuosiuose dokumentuose aiškiai aprašyta konkretaus modelio hierarchija. Produkto tapatybė, medžiaga, matmenys ir atrakinimo metodai automatiškai nepatvirtina paskyros vaidmenų, patvirtinimo taisyklių ar įrašų valdiklių.
Koks yra naudingiausias nuotolinės prieigos testas prieš atliekant masinį užsakymą?
Naudokite pavyzdines duris ir nekilnojamojo turto vaidmenų matricą. Išbandykite vieną leidžiamą veiksmą, vieną draudžiamą veiksmą, kredencialų atšaukimą, administratoriaus perdavimą ir sutartą atsarginį metodą. Užrašykite priimtą konfigūraciją, kad galėtumėte ją palyginti su pristatyta partija.
Prieš pateikdami užklausą, paruoškite leidimų tvarkaraštį
Veiksmingas RFQ sujungia durų tvarkaraštį su atsakomybės matrica. Įtraukite nuosavybės tipą, patalpų skaičių, durų ir spynos korpuso informaciją, pageidaujamus atrakinimo būdus, nuotolinius veiksmus, administratoriaus nuosavybės teisę, atsarginį metodą, perdavimo dokumentus ir priėmimo kriterijus. Tai suteikia tiekėjui pakankamai konteksto, kad jis atitiktų modelį ir nustatytų nepagrįstas prielaidas prieš nustatant kainą.
„Haolock“ gali palaikyti modelio ir konfigūracijos diskusijas dėl slaptažodžio, pirštų atspaudų, kortelės, mechaninio rakto, laikinojo slaptažodžio, „Bluetooth“, programos ir kompiuterio valdomų parinkčių, atsižvelgiant į konkretų modelį. Nekilnojamojo turto komandos gali pateikti užpildytą tvarkaraštį per išmaniųjų užraktų projekto užklausos puslapis todėl pasiūlyme gali būti aptariamas durų suderinamumas ir reikalinga prieigos valdymo darbo eiga.
