Скачать статью в формате Word
Сразу оговоримся – эта статья не предназначена для людей, свободно оперирующих понятиями ЕСКД и ГОСТами 34.ХХХХ и 19.ХХХХ серий. Статья ориентирована на людей, не умеющих писать ТЗ (Техническое Задание).
Для чего нужно ТЗ.
Рассмотрим примитивную ситуацию: вы купили дом и собаку для охраны… собаке надо где-то жить, а значит, нужна конура. Казалось бы, все просто. Пришел профессиональный строитель собачьих домиков дядя Вася, за пару дней соорудил будку с цепью и приглашает вас принять работу. Вы приходите, и что вы обнаруживаете? Будка построена «летняя», а собака должна жить круглый год, вход в конуру расположен со стороны двора, а вам бы хотелось, чтобы собака смотрела на ворота, цепь не дотягивается до сарайчика, а там хранятся ваши ценные садовые инструменты и техника. В общем, деньги потрачены зря, вы недовольны, дядя Вася не понимает, в чем он виноват, так как сделал все по его разумению отлично. А проблема была в отсутствии Технического Задания…
Системы безопасности, о которых пойдет речь, во много раз сложнее конуры для собаки, и, тем не менее, процессы написания ТЗ будет похожи. В ТЗ должны быть однозначно определены такие моменты, как
- цель создания системы (назначение системы);
- технический объем работ;
- требования к системе в целом;
- требования к отдельным подсистемам;
- прочие требования.
Данное разбиение носит условный, хотя и проверенный временем порядок.
Рассмотрим подробнее каждый из разделов ТЗ.
Цель создания системы.
В данном разделе обозначается, собственно, основная причина для создания системы, например: предотвращение воровства имущества, в том числе, инструментов и урожая, находящегося на территории частной собственности заказчика. Или: повышение защищенности объекта путем создания интегрированной технической системы безопасности. Цель может быть изложена и более развернуто, однако, чаще всего, для этого используются последующие разделы ТЗ.
Далее, имеет смысл описать, собственно, ваш объект и те участки объекта, которые вы хотите защищать (так называемые локальные зоны).
К примеру: Объект представляет собой участок в городской застройке, огороженный по периметру бетонным забором с воротами и калиткой. На участке расположен одноэтажный жилой дом и хозяйственные постройки.
Или: Объект состоит из следующих зданий и сооружений: офисное здание №1, 3 этажа, кирпичная постройка, имеет центральный вход и пожарный эвакуационный выход. Соединено с офисным зданием №2 закрытой галереей на уровне 2-го этажа. Офисное здание №2 8 этажей, имеет 4 пожарных эвакуационных выхода. Пятый и шестой этажи – ВИП, доступ ограничен.
Как показывает опыт, любой объект может быть описан таким образом, чтобы в дальнейшем не возникало разногласий по поводу обозначения того или иного строения или значимой его части (цеха, отдела, этажа, помещения и т.п.). Объект стоит разделять на локальные зоны охраны, особенно, если они будут оснащаться различными системами, или должны иметь различные степени защиты.
Например, при описании объекта «банк» имеет смысл заострять внимание на таких помещениях, как «касса», «хранилище», «операционный зал», «банкомат» и т.п. так как подобные помещения будут существенно отличаться по степени защиты от всех остальных. При наличии на объекте периметра большого размера, имеет смысл выделить в отдельные зоны все имеющиеся ворота и калитки, так как их оснащение будет существенно отличаться от оснащения забора (разумеется в случае, если вы ими пользуетесь), а также разбить периметр на рубежи, если предусмотрены различные способы охраны различных участков. А вот разделять на отдельные зоны 6 этажей офисного здания, оснащаемых по одному принципу, смысла не имеет.
В этом же разделе целесообразно указать, из каких конкретно подсистем будет состоять ваша система безопасности.
Технический объем работ.
В данном разделе описывается, что же конкретно нужно сделать в рамках создания системы. А именно: примерно описать, какую локальную зону (обозначенную в предыдущем разделе) какими средствами каких подсистем надо защитить. При этом не обязательно (и даже нежелательно) загромождать этот раздел сложными техническими описаниями устанавливаемых устройств или указывать количество видеокамер на периметре с точностью до единицы, или, тем паче, обозначать фокусное расстояние объектива, или высоту размещения считывателя. В ТЗ вообще, по возможности, не должны фигурировать конкретные марки оборудования и жесткие параметры (кроме случаев, вызванных необходимостью соблюдения, например, климатических требований, но об этом чуть позже). В данном разделе максимально описываются ваши «хотелки» – то самое, на основании чего грамотный исполнитель и составит вам спецификацию и/или изготовит проектную документацию.
В качестве примера: допустимо писать, что «установленные на периметре видеокамеры должны обеспечивать распознавание лица нарушителя, пересекающего забор на любом участке периметра» Или: «размещение телевизионных камер должно обеспечивать сплошную полосу наблюдения и исключать «мертвые» зоны на этой полосе». Или: «на въезде/входе на территории локальных зон оборудовать проходные шлюзового типа для прохода персонала. Проходные должна быть оборудованы элементами СКУД (магнитоконтактными датчиками положения дверей, считывателями магнитных карт, электромагнитными замками) и элементами СВН, позволяющими однозначно идентифицировать проходящий персонал». И такие формулировки будет правильнее, чем, «установить на всей протяженности периметра 29 видеокамер с фокусным расстоянием 6мм» или «установить поясной турникет марки ХХХ, с двумя считывателями YYY, на высоте 1,2 м, а также две видеокамеры на вход и на выход на расстоянии 6 м от прохода, на высоте 3 м». Вы можете, конечно, выполнить львиную долю работы исполнителя, продумав за него, какое оборудование и в каких конкретно конфигурациях вы собираетесь использовать, но при этом:
- будьте готовы, что ваши ошибки по подбору оборудования будут исправляться за ваш счет или не будут исправляться вовсе;
- вполне возможно, что, используя подобранное вами оборудование, целей создания системы вы так и не достигнете.
Задача заказчика определить «что», а задача исполнителя предложить «как».
Требования к системе в целом.
Если обратиться к нормативной документации, то в данном разделе вы найдете массу требований, таких как:
- требования к безопасности эксплуатации технических средств;
- требования по эксплуатации, удобству технического обслуживания, ремонта и хранения;
- требования по транспортабельности;
- требования к возможности модернизации;
- требования по эргономике к рабочим местам;
- требования к надежности;
- требования по стандартизации и унификации;
- требования к сырью, материалам и комплектующим изделиям и так далее, вплоть до требований по обеспечению сохранения государственной и военной тайны при выполнении работ по созданию системы безопасности и требования по обеспечению режима секретности.
Если вдумчиво подойти к данному разделу, то, скорее всего, большую часть требований вы сочтете излишними, особенно если исполнитель отличается банальным здравым смыслом, а ваш объект не является предметом государственной тайны или объектом повышенной опасности (химические и прочие производства, электростанции, объекты министерства обороны и т.п.). Тем не менее, требования по климатическим условиям системы, по эргономике, надежности и расширяемости (возможности модернизации), так или иначе, советуем в ТЗ изложить.
Иначе говоря, самое время для написания «хотелок», касающихся условий и режима работы системы (круглосуточно, при любых погодных условиях от -35 до +40, или же внутри помещения, только в дневное/ночное время, не более 8 часов в сутки, при стабильном освещении и температуре +22°С), возможности и необходимости расширения системы (будет ли в дальнейшем наращиваться система), удобства работы с системой (в большей степени это может коснуться центрального оборудования и мест его размещения), обеспечения непрерывности работы системы (это требование определяет параметры системы бесперебойного питания необходимой мощности) и т.п.
При этом, будьте готовы к тому, что от ваших требования будет напрямую зависеть:
- цена вопроса;
- требования к предоставляемым помещениям и персоналу.
Поясняю: если вы требуете обеспечение электропитания в течение 24 часов при отсутствии основного источника, т.е. работу на аккумуляторах, то готовьте помещение, квадратов этак 40-60, для размещения стеллажей с аккумуляторами, а также не забудьте, что аккумуляторы тепла не любят, а любят кондиционеры, так что разоритесь еще на установку кондиционирования воздуха. Опять же: обслуживать это электрохозяйство кто-то должен, так что предусмотрите в штатном расписании должность техника-электрика. Примерно такой ход рассуждения справедлив для всех «хотелок». С другой стороны, упустив в ТЗ какую-нибудь, даже маловажную деталь, вы можете здорово попасть, и хорошо, если это выяснится в процессе, например, монтажа – это повлечет относительно небольшие затраты на «дозакупку» чего-либо, а вот если система уже будет сдана, и окажется, что половина оборудования не соответствует реально существующим условиям, вот это будет уже сложновато исправить.
Требования к отдельным подсистемам.
В данном разделе рассматриваются требования к составляющим системы, к ее подразделам-подсистемам. В общем и целом, данные раздел включает те аспекты, которые слишком «мелковаты» для раздела «Технический объем работ» и слишком частные для «Требований к системе в целом». Здесь можно рассмотреть как раз такие подробности, как, например, цветные или ч/б видеокамеры вы хотите использовать (хотя пример не слишком удачен, наличие ч/б или цветного изображения зависит в большей степени от целей системы, чем от хотения заказчика), наличие у видеокамер трансфокаторов с управлением, цвет считывателей СКУД, наличие извещателей ОПС с радиоканалом, чтобы не тянуть кабель. Тут же можно уточнить места и правила прокладки кабельных трасс (особенно это имеет значение в офисных помещениях с дорогим ремонтом) и т.п. В этом же разделе оговариваются и такие важные части системы, как система сетевого компьютерного управления (ССКУ, она же специализированная локальная компьютерная сеть) и требования к ПО. Чаще всего, в качестве обязательных требований возникают такие, как: наличие базы данных сотрудников (редактор пропусков), учет рабочего времени сотрудников, наличие подсистемы «Столовая» для фиксации количества обедающих, возможность интеграции с 1С для выдачи табелей и т.п., всяческие подробности по ведению архива данных, и даже интерфейс основного окна дежурного, для, скажем, оператора на проходной, и администратора системы. В качестве необязательных – требования к интерфейсу, требования по защите ПО и т.п. Подробнее о ПО мы поговорим отдельно, в следующей статье.
В качестве прочих требований могут выступать любые, являющиеся важными и критичными с точки зрения заказчика, который, как известно, всегда прав.
Как правило, грамотный исполнитель только порадуется наличию подробного и толкового ТЗ, особенно, если за каждый из пунктов ТЗ заказчик сможет «ответить» – почему именно так он считает нужным сделать. В свою очередь, заказчику стоит прислушаться и к советам исполнителя, если советы выглядят компетентными и логичными. Частенько, это позволяет сэкономить и время, и деньги, и добиться результата – создания системы, отвечающей всем требованиям заказчика с минимальными затратами.
Подходя к написанию ТЗ на систему, ответьте себе на такие вопросы, как:
- Для чего вам система (что и от кого защищаем)?
- Какие вопросы решит создание системы? (т.е. каков ожидаемый эффект?)
- Какие части объекта вы хотите защитить? (выделяем локальные зоны)
- Как хотим защищать? (Хочу видеть, знать, иметь систему оповещения и т.п.)
Примечание: на самом деле, в этот вопрос включается львиная доля конкретных требований как к системе в целом так и к ее составляющим.
- В каких помещениях будет располагаться центральное оборудование и сопутствующие устройства? (серверная, аппаратная, операторская, диспетчерская и т.п.)
- Каким персоналом вы собираетесь обслуживать систему (операторы, диспетчеры, техники и пр.)
И, наконец,
- Сколько денег вы готовы потратить?
