 Внедряя на объекте систему контроля и правления доступом ( то есть СКУД ), мы с вами всегда проходим один и тот же путь, причем зачастую не задумываясь о составляющих этого пути.
Составляющие эти таковы: постановка задачи, поиск технического решения (проектирование), подбор оборудования и компонентов, поставка, монтаж, пусконаладка, сдача в эксплуатацию, гарантийное и послегарантийное сопровождение. Мы проходим весь этот путь независимо от того, насколько мал или велик объект. Для малых объектов и маленьких систем, например, управляемый замок на одной двери, некоторые из указанных составляющих выполняются практически незаметно – задачу поставили на словах за две минуты, техническое решение продумали без привычных атрибутов проектирования, монтаж и пусконаладку выполнил один человек, показал заказчику и получил расчет. Просто, быстро, но тем не менее все атрибуты внедрения были пройдены.
Малые системы просты, они дешевы, при их создании риски минимальны и ошибки не бывают большими. Поэтому поговорим про большие системы, тут есть о чем поговорить.
Часть 1. Пишем техническое задание
Любое решение должно начинаться с постановки задачи. От того, насколько точно поставлена задача, зависит и правильность решения. Если задача поставлена неверно или не полностью, то ошибок не избежать. Для того чтобы результатом неточной или неполной постановки задачи не стал большой конфликт заказчика и исполнителя к моменту сдачи системы в эксплуатацию, уделим постановке задачи как можно больше внимания.
Обязательным атрибутом постановки задачи является «Техническое задание» – документ, имеющий именно такое название. Он очень важен и нужен обеим сторонам процесса. Исполнителю – для того, чтобы понимать, что он должен сделать. Заказчику – для того, чтобы понимать, что он хочет получить. Я не оговорился. Именно заказчик в процессе постановки задачи должен понять, что именно он все-таки получит.
Заказчик – это та сторона, которая будет эксплуатировать созданную вами систему. При этом сама СКУД – это не только набор технических средств. В первую очередь это система. Это комплекс, состоящий из организационных мероприятий и технических средств. Организационные мероприятия на первом месте. И задача технических средств заключается в обеспечении этих самых организационных мероприятий. Я уже многократно говорил об этом и не устану повторять, это принципиально важно. Без необходимых организационных мероприятий ваша система окажется грудой железа, которая не будет эксплуатироваться, «как планировалось», и скоро окажется заброшенной. И виноватым в этом в глазах заказчика окажется тот, кто эту систему внедрял.
Вы должны понимать и всегда помнить, что заказчик не является специалистом в области систем обеспечения безопасности. Иначе бы он создавал себе систему самостоятельно. А раз заказчик, в частности, в системах контроля доступа специалистом не является, он гарантированно не сможет достаточно полно поставить задачу. Это не секрет, вы все с этим сталкиваетесь чуть ли не на каждом объекте. Многие инсталляторы СКУД сами воспринимают свои произведения только как наборы технических средств. В результате очень часто встречается ситуация, в которой исполнитель сдает в эксплуатацию систему, а заказчик не знает, что с ней делать. Причина одна – некачественная постановка задачи.
Из этого следует, что исполнитель сам должен брать на себя обязанность по качественной подготовке технического задания, основываясь на требованиях заказчика, своем опыте и понимании подобных систем. Исключение может быть одно – заказчику не нужна система и он намерен приобрести набор технических средств СКУД. Согласитесь, редкая ситуация. В остальных случаях заказчик нанимает вас для того, чтобы получить полноценную систему.
Самостоятельно, без участия заказчика техническое задание у вас тоже подготовить не получится. Все замыкается на организационные мероприятия, которые должна обеспечивать система. Разработка и внедрение организационных мероприятий – это задача заказчика. Сами на чужом предприятии вы этого сделать не сможете.
Это означает, что вы должны вовлечь заказчика в активную работу по подготовке технического задания. Я повторюсь: техническое задание важно для обеих сторон. И в первую очередь для заказчика. Он, не будучи специалистом, смутно представляет себе результат, который может получить, и какие организационные затраты с его стороны потребуются для получения ожидаемого результата. Он заказывает сложную систему не понимая, а только предполагая и догадываясь о том, что он получит. Думаю, мало кто оспорит утверждение, что на суждения заказчика о таких системах очень большое влияние оказывает Голливуд. И с последствиями такого влияния, в частности, я сталкиваюсь практически ежедневно.
Идеально написанное техническое задание – это когда с обеих сторон все абсолютно всё поняли и не оставили ни одной недомолвки, которые в процессе сдачи системы в эксплуатацию приводят к фразам «А мы думали, что это само собой разумеется…»
Хватит вас готовить, перейдем к сути.
Я призываю всех категорически отказаться от устной постановки задачи. Техническое задание должно быть написано. Всегда заставляйте заказчика написать его требования. Иногда это бывает сложно, заказчик может говорить о задаче часами, а написать – ничего или меньше страницы. Напишите за него, пусть ознакомится и подпишет. Это важно хотя бы потому, что человек в процессе переноса мыслей на бумагу начинает лучше видеть связи и явные недостатки.
Писать техническое задание следует простым языком. Простота – залог понимания. Для обеспечения понимания и однозначности трактовки специальных терминов начните техническое задание с определения этих терминов. Рекомендую зафиксировать даже абсолютно понятные и однозначно трактуемые термины – всегда найдется человек, который поймет что-то не так.
Форма написания технического задания может быть произвольной. Существуют нормативные документы, которые предписывают, каким должно быть техническое задание для систем, автоматизированного управления (АСУ), СКУД, – это частный случай таких систем. Но эти документы более ориентированы на систему разрабатываемую. Рекомендую начинать писать в свободной форме. Со временем вы сами придете к структурированию технического задания, очень близкому к нормативной форме. Я считаю, что слишком строгое соблюдение формы на раннем этапе отвлечет вас от содержания.
Опишите характеристики объекта. Именно объекта, а не требуемой системы.
В техническом задании не стоит уделять внимание подробным техническим характеристикам каких-то блоков оборудования или перечислению функциональных возможностей программного обеспечения. Во-первых, у инженеров-проектировщиков должна быть свобода выбора технического решения исходя из задачи и конкретных условий объекта. Во-вторых, не стоит тратить время и место на указание характеристик, реальное значение которых ни вы, ни заказчик проверить не сможете. Возьмем пример из смежной темы – системы видеонаблюдения. Огромное число технических заданий на такие системы содержит требования к размерам матриц камер (ненужная характеристика, она должна быть следствием условий задачи) и их чувствительности (непроверяемая в условиях объекта характеристика). И при этом в них нет требований к условиям обнаружения и реагирования.
Технические характеристики конкретного оборудования и ПО – это уже результат проработки технического решения. Им место в проекте, но никак не в техническом задании.
В техническом задании необходимо описать условия эксплуатации. Эта информация важна проектировщику для поиска технического решения.
Особое, даже основное внимание в техническом задании следует уделить описанию требуемых алгоритмов работы системы. Для чего используется система? Для контроля людей? Значит, проанализировать все возможные модели, разбить всех, кто будет пользоваться системой, на группы, для каждой группы прописать модель поведения, требуемый алгоритм поведения персонала охраны на проходных по отношению к каждому из типов людей, прописать требуемые алгоритмы получения, замены, сдачи пропуска, алгоритмы работы и взаимодействия соответствующих служб заказчика. Прописать алгоритмы поведения при нарушениях режима (тревожная ситуация в системе), при аварийных ситуациях снаружи и внутри системы.
Система используется для автомобилей? Точно так же выполнить классификацию автомобилей и прописать все требуемые для них алгоритмы.
Это описание требуемых алгоритмов принципиально важно – оно и является описанием организационных мероприятий при эксплуатации системы. Из этого описания заказчик увидит требуемый от него объем работы для получения ожидаемого результата.
Опишите зоны ответственности при эксплуатации системы. Кто за что отвечает, кто определяет доступ, кто контролирует работу персонала, кто и кому должен какую информацию предоставлять, чтобы все это работало. Не забудьте про зоны ответственности при обслуживании и реагировании на отказы. Системы контроля доступа, как правило, сложны, работают в информационных сетях предприятия, используют существующую компьютерную технику. Опишите, какая служба заказчика должна отвечать за работоспособность какого элемента системы.
Далее необходимо прописать требуемые результаты работы системы, включая формы отчетов, условия получения этих отчетов.
Предостерегаю вас от использования формулировок «и так далее». Никаких неоднозначностей, которые заставят вас делать работу по внедрению системы бесконечно. Особо требовательного заказчика при таких формулировках вы не удовлетворите никогда.
Сложно? Только первый раз. Много? Да, много, но и система непростая. И все перечисленные мероприятия существуют в любой СКУД. Когда вы начнете рассказывать обо всем этом заказчику в процессе сдачи системы в эксплуатацию, будет уже поздно. И вам повезет, если заказчик поймет вас правильно и конструктивно отреагирует. В любом случае вы не сможете сдать систему вовремя – на внедрение всех организационных мероприятий нужно гораздо больше времени, чем на монтаж и наладку набора технических средств. И вообще, стоит ли полагаться на везение?
Если все указанные организационные и эксплуатационные алгоритмы подробно и однозначно прописать в техническом задании, вы получите следующее: включите заказчика в процесс на ранней стадии, поможете ему понять те процессы, которые понадобятся для обеспечения работы системы. Заказчик станет понимать, чем и как достигаются его требования, заранее подготовит необходимые для этого силы и средства. Заказчик увидит достоинства и недостатки режимных правил и организационных мероприятий по их обеспечению на своем предприятии. И самое главное – заказчик сможет подробно и точно уточнить задачу до того, как вы попытаетесь сдать ему систему в эксплуатацию, и вдруг окажется «а я думал, что это само собой разумеется…».
Не бойтесь писать много, подойдите к написанию технического задания как к написанию договора – чем больше условий будет согласовано, чем больше вариантов однозначно прописано, тем понятнее будет задача и тем проще будет ее решить. И вы не окажетесь в ситуации, когда вместо подписания акта приемки-сдачи выполненных работ заказчик сформулирует уточнение, которое он считал «само собой разумеющимся» и которое не может быть решено внедренной системой.
Кроме всего перечисленного, подобный подход к подготовке технического задания очень важен новичкам – он позволяет как можно раньше понять, во что исполнитель ввязывается и какой объем работы от него потребуется.
Подведу итоги.
Заставьте заказчика написать задачу. В любой форме, своими словами, чем проще для понимания, тем лучше.
Опишите термины и определения.
Опишите характеристики объекта.
Изучите существующие режимные правила предприятия, опишите их, постарайтесь вписать планируемую систему в них.
Опишите все возможные алгоритмы использования системы, алгоритмические модели всех, кто эксплуатирует систему и кто должен системой учитываться.
Опишите зоны ответственности эксплуатирующего персонала.
Опишите условия эксплуатации системы и ее задачи.
Опишите требуемые результаты работы системы, включая требуемые формы отчетов.
Оформите это в виде документа, именуемого «Техническое задание», согласуйте его с заказчиком.
Техническое задание должно стать неотъемлемым приложением к договору с заказчиком.
Все. Теперь можно приступать к проектированию.
Заключение
Я не планирую детально разбирать каждый этап создания СКУД, в основном они достаточно хорошо проработаны и широко известны. Я намерен заострить внимание читателей на особо сложных и важных элементах. В следующей части предлагаю рассмотреть вопросы организации СКУД автотранспорта в различных условиях и вариантах применения. И не ждите от меня ссылок на конкретные системы, их не будет. Систем множество, а принципы их построения и применения одинаковы. Давайте учиться строить и применять их правильно.
|
