Контакты
Подписка
МЕНЮ
Контакты
Подписка

ТЗ на гостиничную СКУД, или Снова о наболевшем

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

ТЗ на гостиничную СКУД, или Снова о наболевшем

Вначале хотел бы сделать важное замечание: не стоит воспринимать эту статью как критику редакции или автора опубликованного несколькими страницами ранее ТЗ на гостиничную СКУД. Я знаком и с изданиями компании "Гротек", и с редактором раздела СКУД (который и является автором этого ТЗ) не один год, и их профессионализм не может ставиться под сомнение. Но вот как раз в этом случае опыт в тематике систем доступа сыграл с редакторами злую шутку... Почему? Попробую объяснить далее
Андрей Катренко
Коммерческий директор Группы компаний "СМАРТ СЕКЬЮРИТИ"

Получив от редакции "Гротек" предложение поучаствовать в обзоре гостиничных СКУД, мы восприняли его с большим оптимизмом.

К тематике гостиничных систем я имею непосредственное отношение ввиду специфики работы. На своем личном опыте я прошел путь от механических карточных гостиничных замков и замков на магнитной карте до полноценных гостиничных СКУД, поэтому когда в названии обзора прозвучало не "гостиничные замки" – а именно "гостиничная СКУД" (что далеко не одно и то же) – это вселило оптимизм. Но потом мы получили "ТЗ на гостиничную СКУД", и оптимизма как-то сразу не осталось...

Фраза "снова о наболевшем" сразу же определила тему редакционной статьи, которую мы и так планировали совместить с нашим участием в обзоре.

Идеальное "зеркало действительности"

Такая реакция на упомянутое выше ТЗ стала такой как раз по той причине, что оно (ТЗ) просто таки идеально иллюстрирует менталитет (и практику подхода к гостиничным проектам) очень многих безопасников у нас в стране: "Ну подумаешь, какая разница – офис, бизнес-центр, завод, гостиница... СКУД – и в Африке СКУД. А значит, как работали с госзаказчиками, так и с гостиничниками будем. Сами для себя напишем ТЗ (чтобы под него подпадала только нужная нам архитектура или система нужного производителя). Вставим в поясниловку словосочетание "гостевой номер" и упомянем "энергосбережение по карте"... Потом сделаем копию прошлого проекта СКУД офисного центра и по нему выполним монтаж и пусконаладку. И всего делов-то".

Вы бы знали, сколько таких ТЗ мы получаем ежегодно... Трактовка задач, полностью оторванная от реалий гостиничного бизнеса, ссылки на ГОСТ и протоколы, упоминание карт-идентификаторов, биометрии и систем постановки номеров под охрану, непонимание роли электронного замка в единой СКУД гостиничного объекта и другие не менее показательные нестыковки всегда с головой выдают авторов этих ТЗ: интеграторов или инсталляторов систем безопасности. Тех, кому не нужно созданную систему эксплуатировать, но нужно ее "правильно" спроектировать, смонтировать и сдать.

Давайте признаем: практика создания подобных ТЗ давно укоренилась в нашей сфере (СКУД – да и остальные системы безопасности за компанию...), и во многом она такова не из-за "поголовной порочности" нашего брата-безопасника.

Один из самых крупных заказчиков в нашей сфере – это государственные объекты. С общеизвестной системой госзакупок, аттракционов "кто дешевле" и т.п. такие заказчики мигом учат тебя писать ТЗ таким образом, чтобы отвечать его требованиям могли только нужные системы и нужные бренды. Иначе просто не выживешь...

А потом, по накатанной, эта практика переехала и в другие сферы – вот и до гостиничного сектора добралась.

Редакция "Гротек" в этом смысле идеально выполнила задачу специализированного издания, освещающего нашу специфичную сферу деятельности: опубликованное ТЗ – просто таки идеальное "зеркало действительности".


Еще раз повторю – не стоит понимать мои слова как критику редакции или кого бы то ни было: такова реальность, я лишь констатирую этот грустный факт. Готов признаться: в подобной ситуации я и сам бывал неоднократно и тоже писал "ТЗ под себя", так что ангелом прикидываться не буду.

Но поскольку мы сейчас не за реальный объект сражаемся в конкурентной борьбе, а на страницах каталога стараемся повысить осведомленность коллег, давайте забудем о правилах игры в реальной жизни и представим "идеальный отель сферической формы в вакууме", для которого нужно создать гостиничную СКУД. Представим, что существует отель на 50 номеров – и заказчик, который прислал нам опубликованное несколькими страницами ранее ТЗ.

Я же попытаюсь проанализировать это ТЗ и показать, что с ним на самом деле не так (не забывая о чистом субъективизме всего, что будет сказано далее).

СКУД в отеле – это не "система безопасности"

Вначале об "идеальном отеле на 50 номеров"... Для тех, кому пока не приходилось сталкиваться с гостиничной тематикой, скажу, возможно, удивительную вещь: отель на 50 номеров – это малая гостиница, которая достаточно редко является серьезным бизнес-проектом крупного инвестора или девелопера. Куда чаще – это карманные гостевые дома крупных предприятий или дополнительная игрушка владельца, который решил дать "поиграть в бизнес" своей супруге/родственнику/другу. Это также отличный бизнес для выхода на пенсию – спокойный и благодарный, ведь не зря же эту сферу бизнеса называют "индустрией гостеприимства". За редкими исключениями такие отели крупных игроков рынка (управляющие гостиничные компании – российские и международные) не интересуют, так как не могут обеспечить нужный уровень доходности – исключительно из-за специфики гостиничного бизнеса.

Другое дело, если бы это был многофункциональный гостинично-офисно-деловой комплекс ("чистые отели" в данной весовой категории сейчас встречаются редко, как минимум в крупных городах), но в ТЗ об этом ни слова.

Это я все к чему?

К тому, что "ТЗ на гостиничную СКУД" подобных объектов пишут не специалисты-безопасники девелопера, реализующего проект, а скорее сам собственник или люди, к нему близкие. И теперь представьте в устах этого человека фразу "По способу управления (в соответствии с ГОСТ Р 51241-2008) система должна быть универсальной (сетевой) – включать в себя функции как автономных, так и сетевых систем...".

Да он никогда не поймет разницы между ГОСТ и ПТУРС (кто помнит армию), а вы о "функциях сетевых систем"! Не потому, что он глуп, а потому, что он и не должен знать всех этих технических деталей.

Когда мы пытались использовать такие же "умные" фразы в разговоре с заказчиками подобных объектов, нас спросили: "Вы сейчас на каком языке говорили?" – и мигом вернули нас на землю.

А там, "на земле", заказчика интересуют куда более прозаические вещи:

  1. Как система будет помогать ему зарабатывать?
  2. Где она может помочь ему сэкономить?
  3. Чем она может быть интересна с точки зрения увеличения престижа, поддержки репутации или утверждения положительного имиджа отеля?
  4. Ну и, само собой, сколько будет стоить система в целом или та или иная ее функция (как с точки зрения покупки, так и владения)?

Все это нужно заказчику, чтобы понять – когда система (функция) сможет окупиться (и сможет ли вообще...).

Вы, коллеги-безопасники, не учитываете очевидную вещь: СКУД в отеле – это не "система безопасности", как ни странно это покажется. Это такое же средство производства, как станок на заводе! Отели "производят" продукт под названием "комфорт и гостеприимство" – и СКУД участвует в его создании. "Безопасность" в данном случае становится всего лишь дополнительной характеристикой этого продукта, а не самоцелью, что в корне отличает гостиничные СКУД от обычных (офисных).

Любая система, установленная в отеле, должна помогать либо зарабатывать, либо экономить, то есть тратить меньше. При этом заказчику глубоко фиолетово, онлайн-замки у него на дверях или нет, если только вы не сможете доказать ему экономическую эффективность именно онлайна. А уж про соответствие требованиям некоего ГОСТа (в котором, кстати, отсутствует сам термин "электронный замок"), он не будет думать по определению.

Точки доступа

Вернемся к отелю. Согласно ТЗ, необходимо оборудовать 50 номеров и 10 служебных точек доступа...

С номерами все понятно: "номер – он и в Африке номер" (правда, в ТЗ почему-то ни слова про "Антипанику", "Не беспокоить" и еще пару непреложных функций, без которых СКУД – или, если уж хотите, замок – вообще не может быть "гостиничной").

Но что такое "10 служебных точек доступа"? Они-то все разные! Как можно их под одну гребенку мерить?

Напомню: мы говорим о малом отеле. Работать там будет человек 20–25 (что, вообще говоря, просто катастрофа – и основная причина нерентабельности малых отелей). Значит, у нас 1 служебный вход (и то если повезет – чаще вход один для всех, хоть это и неправильно), пара кабинетов, комната горничных и их склад, возможно, серверная и... все. В отеле должны быть, по логике, конференц-комнаты и сауна, но они не относятся к служебным и упоминания о них в ТЗ нет.

Значит, оставшиеся 4 точки доступа – это служебная лестница (что логично, ведь персонал и гости не должны пересекаться, служебная лестница должна быть отделена от гостевой зоны). Однако такие лестницы по определению еще и эвакуационные, а значит требования к СКУД для них в корне отличаются от серверной или офиса, что не может не отразиться на составе и стоимости оборудования.

Но где указания на эти критически важные факторы в ТЗ?

Далее, в ТЗ упомянута функция Antipassback. Которая, напомню, адекватно работает только при наличии устройства, способного обеспечить контроль прохода по одному (турникета), и вахтера рядом с ним (стоимость и того и другого, как принято, "забудем упомянуть" и оставим на потом – будет сюрпризом для инвестора). И это для коллектива на 20–25 человек, включая директора...

Сама по себе функция просто замечательна – благодаря ей можно спокойно вычеркнуть из тендера большинство поставщиков гостиничных замков (но не гостиничных СКУД!). Она также отлично оправдает применение электронных замков для номеров – и классической проводной СКУД для служебных помещений. Это, кстати, самая распространенная у нас практика: поставить 2 системы и пусть эксплуатанты возятся с ними по отдельности.

Вопрос идентификаторов, софта и интеграций

Контроль электропотребителей в номере (управление розетками, кондиционером, телевизором и мини-баром) пока опустим – тема эта слишком объемная, и полноценно обсудить ее не позволит доступный печатный объем.

Лучше копнем тему идентификаторов, софта и интеграций.

Карты – носители, а не идентификаторы

При работе с гостиничными системами вам, коллеги, придется переступить через себя и хотя бы на время забыть термин "идентификатор". Со времен перехода от механических карточных замков к замкам на магнитной полосе карта в отеле перестала быть идентификатором, она – "носитель данных"! Только благодаря записи прав доступа непосредственно на карту гостиничные замки несколько десятилетий успешно существовали в условиях отсутствия проводной связи с базой данных.

Благодаря развитию беспроводных технологий замки научились работать в реальном времени (и все также без проводов). Не без помощи этих технологий системы "замков", кстати, эволюционировали в полноценную СКУД – но карты в них все равно работают как носители, а не идентификаторы. Причин тому много, самая явная – надежность. В случае проблем с сетью система должна продолжать работать (именно система, а не просто замок. Процедуры поселения, выезда и т.п. никак не должны зависеть от состояния сети).


Исключение составляют только идентификационные онлайн-СКУД (в основном проводные, редко – беспроводные): при потере связи с БД СКУД они теряют важные части функционала, такие как возможность регистрации гостевой карты и выезд гостя, а потому приходится предусматривать варианты аварийного поселения/выезда гостей по другому алгоритму. Вообще, проводных гостиничных СКУД в мире на сегодня практически не осталось. Попытки создания, конечно, были, но их заоблачная для отеля стоимость привела к отсутствию реального спроса, и они потихоньку вымерли. В России, как и положено, мы предпочитаем использовать велосипед исключительно собственного изобретения – благо у нас при "правильном" расчете проводная система легко может оказаться дешевле беспроводной (как минимум на бумаге).

Требования к софту

Софт и АРМы в гостиничных системах – тоже специфичный продукт. Вместо термина "Программное обеспечение" корректнее использовать "Комплекс управления". В зависимости от архитектуры системы и поставленных задач он должен включать ПО, энкодер (средство чтения-записи карт) или контрольный считыватель (если СКУД проводная и в ней используются идентификаторы), а также носимый программатор для обслуживания электронных замков (если система на замках).

Правильное ТЗ должно содержать развернутый список требований к ПО гостиничной СКУД – софт этот должен быть весьма специфичным. Простой адаптации ПО "под отель" недостаточно, иначе намучаетесь вы (то есть заказчик)...

Из предложенных вариантов установки АРМов СКУД в кабинете охраны, бухгалтерии и на стойке размещения, в реальности будет нужен только АРМ на Reception. Еще 2 АРМа имеет смысл установить в кабинете администрации (дабы контролировать карты персонала, состояние номерного фонда и трудовую дисциплину сотрудников) и у системщика (в отеле на 50 номеров это скорее будет приходящий, а не штатный сотрудник – ибо дорого).

АРМ СКУД в бухгалтерии отеля – звучит странно. Потому как упомянутая в ТЗ система учета рабочего времени в небольшом отеле – такой же нонсенс, как и система постановки номеров под охрану (зачем она круглосуточно работающему предприятию?). Для контроля трудовой дисциплины директору куда важнее знать не о фактах опоздания на работу, а о попытках (не дай бог фактах) "левого поселения".

АРМ СКУД в кабинете охраны для описываемого нами отеля – еще большая экзотика. Потому как это наверняка будет ЧОП – и кто же им доверит такую конфиденциальную информацию, как история передвижения гостей и персонала?

Интерфейсы с PMS и POS

Остались только интерфейсы с PMS и POS (про СУРВ и охрану уже упоминал).

Вот по поводу чего не может быть сомнений – так это обязательность интерфейса с PMS.

А насчет POS-интерфейса можно поспорить (POS – это, напомню, система автоматизации ресторана).

Интерфейс СКУД с POS позволяет карту гостя использовать для безналичных расчетов внутри отеля. В общем-то, это выгодно – и гости тратят больше (известный психологический эффект), и персонал лишен возможностей для злоупотреблений с наличкой. Но отель-то малый... Здесь и так все на виду, и точек продаж одна-две от силы. (Вот если бы это был SPA-отель или санаторий с развитой системой медицинских услуг... Но это ведь не наш случай?)

Интерфейс СКУД с POS подразумевает не только программную стыковку, но еще и наличие возле каждого POS-терминала устройства, которое считывает и передает данные с карты в POS. Количество точек продаж в ТЗ не указано и определить стоимость этого оборудования не удастся.

По своему опыту могу сказать, что для небольших отелей полноценную систему безналичных платежей ставят редко – POS ведь тоже денег стоит, и немалых.

Что необходимо учесть в ТЗ?

А теперь о том, чего я в ТЗ не увидел и что, по моему мнению, можно считать ошибкой документа даже с учетом его виртуальности:

1. О каком объекте – вновь возводимом или существующем мы говорим? Одна только фраза в ТЗ – "СКУД должна быть развернута в существующем отеле, без проведения капитального или косметического ремонта, без замены дверей и без остановки его работы" – может в корне все изменить. Задача, кстати, вполне решаемая – только выбор архитектуры СКУД будет значительно уже.

2. Раз уж мы говорим об отеле (пусть даже виртуальном), вопрос внешнего вида и дизайна любого оборудования, в том числе СКУД и замков, будут иметь принципиально важное значение. Из своего опыта могу сказать, что все наши (то есть безопасников) доводы за или против того или иного решения могут быть запросто перечеркнуты одной фразой человека такой замечательной профессии, как дизайнер... И тут уж не поможет ни ГОСТ, ни Antipassback.

3. Нет в ТЗ также развернутых требований к картам (про биометрическую СКУД в отеле позвольте не упоминать), а зря. Мы, например, пришли к выводу, что работу с гостиничным заказчиком необходимо начинать именно с утверждения технологии карт (прежде всего гостевых).

Заключение

Несколько месяцев назад по просьбе одного интернет-портала мне уже приходилось писать "памятку проектировщикам гостиничной СКУД" как раз на тему написания технического задания – благо формат ресурса позволил спокойно опубликовать аж 4-серийную статью.

В этот раз я выбрал совсем иной способ высказать свое мнение – возможно, даже несколько рискованный.

И тем не менее задача передо мной была одна и та же: постараться помочь коллегам по цеху понять ту значительную разницу между гостиничной и обычной СКУД, из-за которой многие десятилетия эти две ветви эволюции были столь далеки друг от друга.

Софт и АРМы в гостиничных системах – тоже специфичный продукт. Вместо термина "Программное обеспечение" корректнее использовать "Комплекс управления". В зависимости от архитектуры системы и поставленных задач он должен включать ПО, энкодер (средство чтения-записи карт) или контрольный считыватель (если СКУД проводная и в ней используются идентификаторы), а также носимый программатор для обслуживания электронных замков (если система на замках)

Поэтому позволю себе процитировать заключение из первой статьи:

"Я искренне надеюсь, что после прочтения данной статьи вы как проектировщик систем безопасности сможете гораздо более осмысленно и профессионально пройти через все стадии работы над проектом гостиничной СКУД. И в результате не только корректно спроектируете систему, учитывающую все особенности гостиничного бизнеса, но главное – получите благодарного заказчика, довольного вашей работой. А это послужит залогом не только коммерческого успеха вашей компании, но и значительно повысит вашу репутацию в глазах других потенциальных заказчиков".

Опубликовано: Каталог "СКУД. Антитерроризм"-2014
Посещений: 12795

  Автор

Катренко А. В.

Катренко А. В.

Директор представительства компании Smart Security

Всего статей:  23

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций