Перш ніж подати запит на інтелектуальний замок із віддаленим доступом, менеджери мають призначити відповідальність за п’ять дій: розблокування, затвердження користувачів, скидання адміністраторів, відкликання облікових даних і перегляд записів доступу. Для кожної дії потрібна названа роль, визначена область, правило затвердження та процедура передачі. Запит на пропозицію також повинен вимагати підтвердження конкретної моделі того, що запропонована платформа блокування та керування може підтримувати ці елементи керування.
«Віддалений доступ» не є повною специфікацією. Один постачальник може інтерпретувати це як керування користувачами на основі програми біля дверей, тоді як інший може означати розблокування за межами сайту через підключену систему. Таким чином, пропозиція може виглядати сумісною, навіть якщо вона не відповідає робочому процесу власності. Команди із закупівель повинні спочатку визначити модель дозволу, а потім попросити постачальників підтвердити, які функції доступні для конкретного блокування, програми, шлюзу чи конфігурації керування, що цитується.
Почніть із дій, а не з посад
Такий титул, як «адміністратор», мало що говорить про те, що ця особа насправді може робити. Черговому менеджеру готелю може знадобитися авторизувати одноразове розблокування, але він не обов’язково може передавати право власності на систему. Команда з оренди квартир може створити доступ орендаря, але не матиме причин змінювати налаштування пристрою. Обслуговуючому персоналу може знадобитися обмежений за часом вхід до призначених кімнат без видимості інших мешканців або власності.
Перший додаток до запиту пропозицій має бути матрицею відповідальності. Наведена нижче матриця є моделлю планування, а не твердженням, що кожне блокування, пов’язане з програмою, включає всі перелічені функції. Покупці повинні видалити невідповідні рядки та вимагати від постачальника позначити кожну функцію, що залишилася, як підтримувану, непідтримувану або залежну від додаткового компонента.
| Дія віддаленого доступу | Рішення, яке необхідно визначити перед запитом пропозицій | Типовий контроль проекту | Докази для запиту |
| Дистанційне розблокування | Які ролі можуть розблокувати кімнати та за яких обставин? | Обмежте доступ за власністю, будівлею, поверхом, кімнатою, зміною чи типом події. | Екран дозволу на роль, інструкції з експлуатації та зразок приймального випробування. |
| Розблокувати схвалення | Чи може одна особа діяти самостійно, чи інша роль має схвалити запит? | Використовуйте друге схвалення для чутливих приміщень або винятків у неробочий час, якщо цього вимагає проект. | Підтвердження постачальником доступного робочого процесу затвердження для вказаної конфігурації. |
| Створення користувача або облікових даних | Хто може додавати персонал, гостей, орендарів, підрядників або тимчасових користувачів? | Окремий доступ до рутинної кімнати від створення адміністратора. | Демонстрація ролей користувачів, термінів дії та елементів керування призначенням кімнат. |
| Відкликання облікових даних | Хто позбавляє доступу після виписки, розірвання договору оренди, відходу персоналу або втрати телефону? | Призначте власника відповіді та необхідну точку завершення для кожної події. | Процедура відкликання та підтвердження того, що видалення доступу можна перевірити на ураженому замку. |
| Скидання адміністратора | Хто може скинути блокування або обліковий запис і хто санкціонує цю дію? | Зберігайте повноваження скидання вужчими, ніж звичайні повноваження керування користувачами. | Інструкції зі скидання для конкретної моделі та контрольний список повторного введення в експлуатацію після скидання. |
| Доступ до перегляду записів | Які ролі можуть переглядати або експортувати записи, для яких дверей і для яких операційних цілей? | Обмежте видимість найменшим робочим обсягом, необхідним для проекту. | Підтвердження постачальником полів запису, доступності, контролю збереження та параметрів експорту. |
| Передача права власності на систему | Хто отримує контроль після інсталяції та як позбавляються прав інсталятора? | Зробіть остаточну передачу права власності документально підтвердженою віхою прийняття. | Процедура передачі, яка показує перенесення облікового запису, видалення облікових даних і підтвердження покупця. |
Визначте область дозволу на рівні дверей і портфоліо
Дозвіл корисний лише тоді, коли його область чітка. «Менеджер нерухомості може відчинити двері» може означати одну призначену квартиру, кожну кімнату в одній будівлі або ціле портфоліо. Ця різниця впливає на експлуатаційний ризик і не повинна залишатися на вибір установника під час введення в експлуатацію.
Для кожної ролі вкажіть дозволені властивості, будівлі, поверхи, кімнати та часові вікна. Також вкажіть, чи ця роль може делегувати доступ іншій особі. Якщо делегування дозволено, визначте, хто може його схвалити та коли закінчується термін його дії. Регіональному адміністратору може знадобитися видимість кількох сайтів, тоді як локальному менеджеру можуть знадобитися повноваження лише для одного місця. Централізація кожного дозволу може спростити нагляд, але це також створює більший вплив, якщо один обліковий запис неправильно оброблено. Суто локальний контроль звужує цей вплив, але може уповільнити підтримку, якщо на місці немає уповноваженої особи.
Така сама логіка має застосовуватися до змін властивості. Коли кімната змінюється з довгострокової оренди на короткострокову, необхідний робочий процес облікових даних може змінитися, навіть якщо фізичний замок залишається на місці. Перегляд покупців параметри розумного блокування для керованих властивостей тому слід порівняти робочу модель так само ретельно, як ручку, оздоблення чи спосіб розблокування.
Відокремте регулярний доступ від виняткового
Звичайний доступ охоплює заплановані події, такі як приїзд гостей, заїзд орендарів, прибирання, перевірка або планове технічне обслуговування. Винятковий доступ охоплює блокування, перевірки соціального забезпечення, пошкодження телефонів, перебої в мережі, відсутність персоналу та інші інциденти, які вимагають контрольованого відхилення від нормального робочого процесу.
Специфікація проекту повинна ідентифікувати власника винятку, докази, необхідні перед розблокуванням, і запис, створений після цього. У ньому також має бути вказано, що станеться, якщо віддалена функція недоступна. Залежно від вибраної моделі резервний варіант може включати пароль, відбиток пальця, картку, механічний ключ, локального адміністратора або інший перевірений метод. Не слід припускати резервного варіанту для всього асортименту продукції; Система продуктів Haolock включає кілька варіантів розблокування та керування, але доступна комбінація має бути підтверджена моделлю.
Ця різниця запобігає тому, що повсякденна функція зручності стане неконтрольованим маршрутом доступу до голови. Це також дає постачальнику вимогу, яку можна перевірити: продемонструвати звичайний робочий процес, продемонструвати робочий процес із винятками та показати, як система повертається до нормального контролю після інциденту.
Підтвердьте точну конфігурацію продукту та керування
Фізичний замок і механізм дистанційного керування повинні бути затверджені як одна конфігурація. The 1023 чорний пароль і замок відбитків пальців, наприклад, вказано для квартир, будинків, кімнат для оренди, проживання в сім’ї та проектів із керованим доступом. Задокументовані дані про продукт підтверджують чорний корпус із нержавіючої сталі, матове покриття, розміри 330 × 42 × 22 мм, а також пароль і ідентифікацію за відбитками пальців.
Ці факти самі по собі не встановлюють віддалене розблокування, ієрархію облікових записів, вимоги до шлюзу, доступність записів або поведінку програми. Якщо покупець хоче цю модель або будь-який варіант із Діапазон розумного замка відбитків пальців— при віддаленому управлінні постачальник повинен визначити точний варіант і кожен допоміжний компонент у пропозиції. Це ж правило застосовується при оцінці діапазон розумного блокування пароля: клавіатура або функція тимчасового пароля не повинні розглядатися як доказ зовнішнього адміністрування.
Попросіть постачальника вказати, чи кожна запитана функція виконується на замку, через телефон біля замку, через шлюз чи через інший інтерфейс керування. Це єдине уточнення може виявити приховані відмінності обсягу між пропозиціями та запобігти затвердженню зразка конфігурації за припущеннями, які не враховуються в масовому порядку.
Зробіть передачу та відкликання частиною прийняття
Управління віддаленим доступом часто дає збій під час переходів, а не під час звичайного використання. Інсталятори залишають, працівники змінюють ролі, орендарі виїжджають, змінюються оператори нерухомості або втрачається телефон, пов’язаний з обліковим записом адміністратора. Перед початком інсталяції проекту потрібна певна відповідь для кожної події.
Остаточне прийняття має підтвердити, що покупець контролює запланований обліковий запис адміністратора, облікові записи неавторизованого налаштування видалено, кожна роль має схвалену область дії дверей, а тестові облікові дані можна створити та відкликати. Якщо проект потребує записів доступу, група приймання також повинна переконатися, що призначений рецензент може отримати необхідну інформацію, тоді як інші користувачі не можуть. Зберігання записів і поведінка експорту повинні бути підтверджені відповідно до власних операційних і правових вимог проекту, а не припущеннями.
Для проектів із кількома сайтами призначте як власника облікового запису, так і контактну особу для відновлення. Це не повинні бути тимчасові монтажники чи окремі працівники, від’їзд яких залишить майно без адміністративного контролю. Також потрібен задокументований процес зміни: будь-яке подальше розширення дозволу має визначати, хто його запитував, хто його схвалив, які двері вплинуло та коли було перевірено зміну.
Що має вимагати від постачальника підтвердити запит на пропозицію?
| Вхід RFQ | Інформація, яку має надати покупець | Потрібна відповідь постачальника |
| Розклад власності та дверей | Кількість ділянок, будівель, кімнат, типи дверей, товщина дверей і необхідна кількість замків. | Сумісна модель замка, розташування корпусу замка та будь-яка інформація про двері, яка ще потрібна. |
| Матриця дозволів | Ролі, дозволені дії, діапазон дверей, часовий діапазон, правила затвердження та обмеження делегування. | Підтримувані функції, обмеження та будь-які функції, які потребують іншої моделі чи компонента. |
| План підключення | Де потрібне дистанційне керування та які підключення доступні в кожному об’єкті. | Як зазначена конфігурація обмінюється даними та який додатковий пристрій чи налаштування потрібні. |
| Резервна процедура | Кому потрібен екстрений доступ і які офлайн чи локальні методи прийнятні для проекту. | Доступні резервні методи на точній моделі та процедура відновлення нормального керування. |
| Пакет передачі | Названий власник адміністратора, контакт для відновлення, ролі персоналу, навчальна аудиторія та необхідні документи. | Інструкції з налаштування, процедура скидання, етапи передачі права власності та записи конфігурації ролі. |
| Приймальні випробування | Зразки дверей, ролей користувачів, дозволених дій, заборонених дій і критеріїв проходження/непроходження. | Метод випробування зразка та узгоджений підхід перевірки доставленої партії. |
Відповідь постачальника повинна відрізняти стандартні функції від додаткових функцій і визначати залежності. «Програма підтримується» недостатньо, якщо в запиті пропозицій запитується, хто може віддалено розблокувати, чи існує етап затвердження, як відкликається доступ або як передається право власності після введення в експлуатацію. Цінова пропозиція повинна відповідати на ці запитання щодо названої моделі та конфігурації.
Запитання, які зазвичай ставлять менеджери нерухомості
Чи повинен кожен менеджер власності отримувати дозвіл на дистанційне розблокування?
Ні. Дозвіл має відповідати операційній відповідальності, обсягу дверей і процедурам інциденту. Деяким менеджерам може знадобитися лише видати або відкликати облікові дані, тоді як менша група обробляє виняткові віддалені розблокування.
Чи завжди керування додатком означає віддалене розблокування за межами сайту?
Ні. «Контроль програми» може описувати різні механізми підключення та керування. Покупці повинні попросити постачальника вказати, де повинен знаходитися користувач, як замок спілкується та які додаткові компоненти потрібні.
Чи може сторінка продукту підтвердити, що блокування підтримує необхідну ієрархію дозволів?
Ні, якщо на сторінці чи супровідних документах чітко не описано цю ієрархію для точної моделі. Ідентифікація продукту, матеріал, розміри та методи розблокування не підтверджують автоматично ролі облікових записів, правила затвердження чи елементи керування записами.
Який найкорисніший тест віддаленого доступу перед масовим замовленням?
Використовуйте зразок дверей і реальну рольову матрицю власності. Перевірте одну дозволену дію, одну заборонену дію, відкликання облікових даних, передачу адміністратора та узгоджений резервний метод. Запишіть прийняту конфігурацію для порівняння з доставленою партією.
Підготуйте графік отримання дозволів, перш ніж запитувати пропозицію
Працездатний запит пропозицій поєднує графік дверей із матрицею відповідальності. Включіть тип власності, кількість кімнат, інформацію про двері та корпус замка, бажані методи розблокування, віддалені дії, право власності адміністратора, резервний метод, документи про передачу та критерії прийняття. Це дає постачальнику достатньо контексту, щоб зіставити модель і визначити непідтверджені припущення перед встановленням ціни.
Haolock може підтримувати обговорення моделі та конфігурації для пароля, відбитка пальця, картки, механічного ключа, тимчасового пароля, Bluetooth, програми та параметрів, керованих комп’ютером, залежно від конкретної моделі. Команди власності можуть подати заповнений графік через сторінка запиту проекту Smart Lock тому пропозиція може стосуватися сумісності дверей і необхідного робочого процесу керування доступом.
