Алена Швецова, 30/01/20
Принятый в наших странах термин "пилотный проект" (сокращенно – "пилот") является эквивалентом международного понятия Proof of Concept (PoC), что переводится с английского как "доказательство осуществимости концепции". Термин PoC появился в 1967 г. в США в авиационной индустрии и подразумевал описание методики проверки новых технологий. В настоящее время без PoC не обходится практически ни одна индустрия, ни авиация, ни патентоведение, ни программирование.
Именно PoC позволяет при минимальных затратах проверить работоспособность и функциональность будущих технологий и решений. Индустрия систем безопасности и ИТ-решений также очень активно использует PoC в процессе создания новых продуктов и их продаж. Данная статья посвящена применению PoC в продажах систем безопасности.
"Корпоративный" и "личный" выбор
Представьте себя на месте заказчика, который собирается приобрести систему видеонаблюдения для решения корпоративных задач.
Вы сформулировали цели системы, определили модель угроз, поняли, кто и как будет взаимодействовать с системой в качестве администратора и операторов, решили, какая видеоинформация будет нужна в режиме реального времени, а что важно зафиксировать и сохранить.
Вы хотели бы, чтобы система действительно являлась инструментом предотвращения нежелательных ситуаций, а записанное видео – надежной доказательной базой для возможных расследований. Вы хотите, чтобы все было функционально, современно, надежно и недорого. Для решения вашей задачи требуется порядка 1 тыс. новых IP-камер, у вас 20 различных существующих объектов и уже работают 400 IP-камер. Все это нужно объединить в единую централизованную систему, интегрированную с вашей существующей СКУД, и в некоторых точках добавить модули распознавания автомобильных номеров и лиц. Вы также хотели бы, чтобы система была умной и поддерживала различную видеоаналитику. Типичная задача, не правда ли?
Заказчик объявил конкурс (возможно, даже до конкурса заказал и получил проектную документацию), получил N технико-коммерческих предложений от различных интеграторов, тендерный комитет рассмотрел их и выбрал… самый дешевый вариант. Конкурс состоялся, отдел закупок заказчика счастлив, что они отлично выполнили свою работу и сэкономили бюджет.
Решает ли поданное коммерческое предложение все задачи заказчика? Соответствует ли техническому заданию и/или проекту? Как функционирует система? Интегрированы ли части решения между собой? Как именно будет выглядеть на практике единое централизованное решение? Как себя будет вести вся система и ее отдельные компоненты через пять лет непрерывной эксплуатации? На все эти вопросы заказчик получит ответ лишь после монтажа и запуска системы в работу. С реальностью столкнется только служба эксплуатации, возможно именно служба безопасности, которая изначально готовила техническое задание на конкурс и хотела получить умное и функциональное решение. Но акты уже подписаны и деньги потрачены… Поэтому было бы хорошо сделать так, чтобы заказчик до проведения конкурса и покупки системы увидел на своем объекте, как работает решение, мог оценить все плюсы и найти минусы.
А теперь представьте себя в преддверии покупки нового (не первого вашего) личного автомобиля. У вас есть планируемый бюджет и четкие критерии выбора машины вашей мечты. Вы ходите по автомобильным салонам, читаете форумы автолюбителей, записываетесь на тестдрайв, спрашиваете отзывы друзей. Часто то, что нравится на тест-драйвах, стоит дороже, чем мы планируем, и нужно сделать непростой выбор, что важнее – удовольствие от нахождения за рулем машины несколько следующих лет или стоимость прямо сейчас. Если бюджет приоритетнее, нам придется отказаться от некоторых функций или выбрать другую марку автомобиля. А если важнее комфорт, то следует пересмотреть сумму на покупку будущего автомобиля.
Как связаны эти два совершенно разных выбора, вы узнаете дальше.
Пилотный проект СВН. Цели и критерии
Цель пилотного проекта в СВН (системе видеонаблюдения) – проверить/выбрать на практике решение, которое отвечает функциональным требованиям заказчика. Пилот может проводиться для проверки функционала одного решения (тест-драйв на одной машине) или для сравнения функционала нескольких различных решений (тест-драйв на нескольких машинах). Пилотному проекту СВН всегда предшествует теоретическое изучение предложений по технической документации.
Важно определить, как именно будет проходить сам пилот: либо один интегратор будет показывать предлагаемый вариант/варианты решений одновременно, либо в пилоте будут участвовать несколько интеграторов с конкурентными решениями.
Исходным документом для качественного пилотного проекта СВН должно являться задание на пилотный проект, а результатом – протокол пилотного проекта.
Самый оптимальный период проведения пилота СВН – до момента окончательного формирования бюджета на будущий период. Самый главный бизнес-результат пилотного проекта для заказчика – объективное понимание, сколько стоит то, что работает так, как он хочет.
Качественное проведение пилотного проекта позволит сформировать заявку на бюджет и провести объективный конкурс. Если заявка будет одобрена руководством, то по итогам конкурса заказчик получит полностью предсказуемый результат. А если бюджет по ряду причин уменьшат, то заказчик сможет либо сократить требования к функционалу системы, чтобы вписаться в требуемый бюджет, либо разбить проект на этапы, но при этом не потерять в качестве и функционале будущего решения.
Проведение пилотного проекта на объекте заказчика имеет смысл только в одном случае – когда у него действительно есть бюджет и потребность в выборе решения. Для пилотного проекта потребуется оборудование, материалы и программное обеспечение, ресурсы и время заказчика, ресурсы и время интегратора. Индикативный срок проведения качественного пилота – от 1 до 2 месяцев, чтобы персонал заказчика мог полностью освоить новое решение и отработать на практике реальные задачи.
Если заказчик хочет познакомиться с новым оборудованием и технологиями, это можно эффективно и оперативно сделать с помощью технической презентации и документации, демонстрационных видеороликов, демонстрации возможностей решения на территории интегратора, визита в офис к вендору, посещения выставки и т.д.
Роль концепции Try&Buy
Возможность проведения пилотного проекта напрямую зависит от бизнес-процессов, по которым работают вендоры и их дистрибьюторы по системам видеонаблюдения (см. статью "Вендор. Интегратор. Дистрибьютор. Третий лишний?" в журнале "Системы безопасности" № 5/2019, стр. 52–53). Концепция Try&Buy или Try Before Buy ("попробуй и купи" или "попробуй перед тем, как купить") предполагает для системных интеграторов возможность бесплатного получения оборудования и программного обеспечения на тест.
Для контроля рисков повреждения оборудования между дистрибьютором и интегратором подписываются соответствующие документы. В упрощенном варианте это гарантийное письмо, где указывается стоимость, срок выдачи на тест и фиксируется факт, что в случае потери товарного вида или повреждения оборудования интегратор обязан его полностью оплатить. С программным обеспечением все проще: вендор по запросу дистрибьютора/интегратора может сгенерировать временный ключ, ограниченный сроком проведения пилотного проекта. А вот расходные материалы (кабели, крепеж и т.д.), которые потребуются для пилота, придется приобрести. Благодаря концепции Try&Buy у заказчика также есть возможность получить от интегратора оборудование и программное обеспечение на тест с минимальными затратами или даже бесплатно.
Задание и подготовка к пилоту
Рассмотрим организацию пилотного проекта на нашем "корпоративном" примере. Исходя из первичных требований, заказчику необходимо создать полноценную ИБС и выбрать ее компоненты: IP-видеокамеры, централизованное решение по СВН, интегрированное со СКУД, модули распознавания автомобильных номеров и лиц и другую видеоаналитику.
Предположим, что наш заказчик поручил пилотный проект одному-единственному интегратору, но поставил задачу показать в пилоте и сделать сравнение минимум двух (а лучше трех) ИБС, чтобы обосновать выделение бюджета под проект.
Чтобы проверить все функции будущей системы, необходимо показать ее на пилоте в миниатюре. Учитывая требования к объединению распределенных объектов, пилотный проект должен состоять минимум из двух объектов заказчика, например центрального офиса и одного из удаленных филиалов.
В главном офисе заказчик хотел бы протестировать новые и существующие IP-камеры, модуль распознавания лиц, интеграцию со СКУД, а в удаленном филиале – подключение в систему существующих IP-камер и модуль распознавания автомобильных номеров, поэтому он определил следующие параметры для пилотного проекта:
- 1 точка для типичных зон видеонаблюдения;
- 1 точка для ответственных зон (со сложными параметрами сцены);
- 2 точки для распознавания лиц;
- 10 существующих IP-камер заказчика в главном офисе;
- 2 турникета и 18 точек доступа в главном офисе;
- 1 оператор в главном офисе;
- 1 руководитель в главном офисе;
- 6 существующих IP-камер заказчика в филиале, 2 из которых для распознавания автомобильных номеров;
- 1 оператор в филиале;
- глубина хранения видеоархива в филиале – 7 суток с последующим перемещением в центр и хранением там в течение 30 суток;
- глубина хранения видеоархива в главном офисе – 30 суток;
- демонстрация другой полезной для бизнеса видеоаналитики, контроля транзакций и длины очередей.
Таким образом, для пилота потребуется 4 новых IP-камеры, лицензия на распределенную систему видеонаблюдения для 20 камер, 2 лицензии для распознавания лиц, 2 лицензии для распознавания автомобильных номеров, лицензия на интеграцию со СКУД для 20 точек доступа, 2 лицензии для серверной части двух объектов, 2 лицензии для рабочих мест операторов и 1 лицензия для мобильного доступа для руководителя, минимум 2 лицензии для указанной видеоаналитики и, в зависимости от брендов ИСБ, могут потребоваться лицензии для многоуровневой записи и хранения данных.
В самом задании на пилотный проект заказчик детально описал требования к функционалу будущей системы и требования к тому, что должны получить на своих рабочих местах операторы системы. Детализация задания позволяет по итогам проведения пилота в протоколе по каждому пункту однозначно ответить "требование выполняется" или "требование не выполняется".
Интегратор проанализировал требования задания, выполнил расчет для серверной части, включая хранение данных, и согласовал, что заказчик предоставит серверы, активное сетевое оборудование, а также выполнит настройку ИТ-инфраструктуры для пилота. Подготовка к такому пилоту со стороны заказчика и интегратора может занять от одной до трех и более недель.
Пилотный проект СВН. Процесс
Разобьем пилотный проект на несколько этапов:
- тестирование СВН и IP-камер;
- тестирование интеграции СВН со СКУД;
- тестирование ИСБ;
- тестирование модулей распознавания лиц и автомобильных номеров;
- тестирование другой видеоаналитики.
В процессе проведения этого пилота у нашего интегратора есть отличный шанс развенчать на практике несколько популярных заблуждений, которыми часто оперируют заказчики:
- конфигурация серверов и рабочих станций операторов подойдет для любых ИСБ;
- интеграция СВН и СКУД – это же стандартный функционал;
- распознавание номеров и лиц должно работать на любых камерах;
- видеоаналитика – это базовый функционал даже для камер, который легко можно добавить в любую систему в любой момент;
- все камеры показывают одинаково, просто какие-то вендоры берут больше денег за имя, а так их делают на одних и тех же заводах;
- для работы СВН в филиале нужно использовать канал 2 Мбит/с и т.д.
Инсталляция и настройка ПО
Наш пилот следует начать с инсталляции программного обеспечения СВН (ИСБ), подключения к нему существующих и новых IP-камер и настройки базового функционала системы.
Серверные мощности заказчика и рабочие места операторов СВН должны учитывать возможность работы одновременно минимум двух ИСБ. Только в этом случае интегратор сможет на практике показать эффективность работы каждой ИБС с серверами и системой хранения данных (с железом). В процессе работы операторов с СВН/ИБС заказчик обязательно откроет для себя новые и полезные функции и с большой вероятностью скорректирует свои функциональные требования, учитывая появившийся новый практический опыт. Часть требований заказчика к ИСБ может также исчезнуть, поскольку функционал каждой ИСБ имеет свои отличия, часто один и тот же функционал реализован по-разному (например, резервирование, запись и хранение данных в распределенной СВН).
Интеграция СВН и СКУД: да или нет?
На этапе выбора ИСБ интегратор обязан проанализировать существование интеграции между СКУД заказчика и предлагаемой СВН. Если интеграция существует, то следующим этапом может быть настройка этой интеграции.
Если интеграции не существует и заказчик готов к замене своей СКУД на более современную, то интегратор может в некоторых точках поставить новые контроллеры и показать преимущества предлагаемой ИСБ с новым СКУД. Если заказчик не готов на замену существующей СКУД, то либо придется отказаться от требования об интеграции СВН и СКУД, либо можно попросить интегратора оценить сроки и стоимость создания такой интеграции. До проведения пилотного проекта все эти вопросы должны быть проработаны и согласованы сторонами.
Настройка модуля распознавания автомобильных номеров
На следующем шаге можно выполнить настройку модуля распознавания автомобильных номеров в составе СВН и ИСБ. Поскольку заказчик для пилота уже предоставил существующие IPкамеры, важным критерием успеха этой части пилота будет пригодность картинки с этих камер. Чтобы исключить конфликт с заказчиком в процессе пилота, следует заранее предоставить ему техническую литературу с описанием минимальных требований к IP-камерам для распознавания номеров (разрешение, углы отклонения, WDR, скорость затвора и т.д.), а на момент подключения существующих IP-камер продемонстрировать на практике пригодность/непригодность картинки для распознавания номеров.
Тестирование модуля распознавания лиц
Есть смысл совместить тестирование IP-камер с тестированием модуля распознавания лиц, так как для качественной работы последнего могут потребоваться более профессиональные модели IP-камер. В процессе подготовки к пилоту рекомендуется предоставить заказчику техническую литературу по тематике распознавания лиц для изучения, а также согласовать с ним детально, как именно должен работать модуль распознавания лиц и какие функции выполнять (заведение картотеки, поиск и сравнение лиц в базе, отображение тревог, максимальное количество лиц в базе, способность отличить живого человека от картинки, 2D- или 3D-распознавание и т.д.).
Требования к результатам работы распознавания лиц могут в корне поменять принцип выбора СВН/ИСБ. Нужно быть готовым к тому, что если модуль распознавания лиц от производителя СВН/ИСБ не даст нужных результатов, то придется менять саму платформу СВН и взять VMS от одного производителя, а модуль распознавания лиц от другого, и они должны быть интегрированы, если заказчик хочет получить ИСБ.
Множество мифов о распознавании лиц проводит к тому, что интеграторы продают только 10–15% от количества просчитанных проектов, а 85% – это работа "в корзину". Именно такие мифы позволяют недобросовестным интеграторам манипулировать в тендерах, давая заниженную стоимость на заведомо неработающие решения. Интегратор должен заблаговременно уведомить заказчика о требованиях к серверной части для качественного распознавания лиц, чтобы в процессе пилота они не стали неприятным сюрпризом.
Чем больше информации и практических результатов по распознаванию лиц будет предоставлено заказчику на пилоте, тем больше шанс, что данный модуль будет одобрен, правильно забюджетирован и в последующем продан в проекте. Поэтому пилот по распознаванию лиц – ключевая возможность для заказчика досконально разобраться в вопросе и либо осознанно добавить этот раздел в бюджет будущего проекта, либо вычеркнуть его из бюджета и забыть про него.
Другая видеоаналитика
Демонстрация различной видеоаналитики в пилоте – всегда "вишенка на торте". При предоставлении расчетов с требованиями к железу для такой видеоаналитики часто выясняется, что заказчик не готов к приобретению еще какого-то количества серверов и был уверен, что это просто "дополнительная галочка в интерфейсе СВН". Если требуемый функционал видеоаналитики доступен на IP-камерах, то по-настоящему интегрированным можно назвать только такое решение, где в интерфейс СВН/ИСБ попадают все тревоги по этой видеоаналитике с этих IP–камер, например подсчет людей или тревога о длине очереди. В большинстве случаев выясняется, что встроенная в камеры видеоаналитика не может выполнить все требования или делает это только с "родным" софтом, и заказчику приходится возвращаться к видеоаналитике на серверах (что потребует увеличения бюджета) либо полностью отказаться от видеоаналитики в проекте.
Выбор вендора и бренда IP-камер
Тестирование IP-камер различных вендоров в зонах со сложными условиями освещения (где есть встречная засветка, пересвет сцены, тень в кадре, цветные объекты, плохая освещенность и т.д.) позволяет на практике объективно показать заказчику, на что реально способны IP–камеры разных брендов и почему те или иные модели стоят разных денег. По результатам тестирований сразу видно лицо бренда (качество картинки, отсутствие шумов и размер потока). Если принять во внимание гарантийную политику вендоров и параметр MTBF (Mean Time Between Failures) наработки на отказ, который для круглосуточной эксплуатации IP-камер для объектов корпоративного уровня должен быть не менее 100 тыс. часов, то результаты тестирования позволят заказчику совершенно по-новому взглянуть на вопрос выбора модельного ряда и стоимости IP-камер, потому что они являются глазами будущей системы и основой для доказательной базы.
Пилотный проект СВН. Результат
Качественным итогом пилотного проекта СВН является протокол с результатами. Для IP-камер это сравнительные таблицы с детальными параметрами тестирования:
- в различных условиях (день/сумерки/ночь);
- в статике (картинка без людей);
- при движении людей в кадре.
Тестирование IP-камер и СВН должно доказать возможность получения качественных скриншотов и видеороликов, являющихся доказательной базой при расследовании инцидентов. Для распознавания номеров и лиц критерием качества является полное соответствие заявленным вендором характеристикам как по функционалу, так и по успешности распознавания согласно действующим нормам и региональным стандартам.
Практическая работа операторов с реальными СВН/ИСБ в реальных условиях часто меняет мнение заказчика по поводу стоимости будущего решения. То, что казалось дешевым и приемлемым, может оказаться неудобным и нефункциональным, и наоборот: те СВН/ИСБ, которые изначально виделись очень дорогими и неприемлемыми, могут позволить заказчику сэкономить на смежных частях проекта (например, на серверном оборудовании или системе хранения данных) или эффективнее работать с существующими сетями.
Преимущества для заказчика
Пилотный проект СВН для заказчика – это объективный способ проверки ожидаемого от системы функционала и формирования бюджета.
Качественный пилотный проект позволит достаточно точно оценить CapEx (CAPital EXpenditure – первичная стоимость решения), грамотно спланировать технические и финансовые этапы реализации и более точно оценить OpEx (OPerating EXpense – операционные затраты), что в конечном итоге гарантированно приведет к снижению общей совокупной стоимости владения СВН, поскольку процесс на любом этапе технически предсказуем и финансово управляем.
За пределами стран СНГ проведение пилотных проектов на площадках заказчиков силами системных интеграторов является платным, это общепринятая практика. В наших странах она также показала свою эффективность и активно набирает популярность, а проведение пилотных проектов регулируется договоренностями между заказчиком и интегратором.
Выгоды для интегратора
Участие в пилотных проектах СВН дают интегратору ряд уникальных преимуществ, в числе которых:
- возможность досконально изучить на практике различные бренды СВН и СКУД в составе сложных решений ИСБ и значительно повысить компетенцию своих специалистов;
- демонстрация всех уникальных возможностей предлагаемых брендов и решений;
- конкуренция фактами и реальными результатами, а не маркетингом;
- использование опыта на пилоте в работе с подобными заказчиками;
- статус эксперта на рынке;
- возможность остаться в проекте, предлагая обоснованную альтернативу;
- способность влиять на компетенции и бюджет заказчика несколькими альтернативными вариантами решения и развенчанием существующих на рынке мифов.
За последние шесть лет у автора был опыт участия в более чем 40 пилотных проектах на стороне дистрибьютора, поддерживающего интеграторов. По опросам, проведенным среди интеграторов, успешный пилотный проект увеличивает вероятность продажи решения минимум в два раза и позволяет использовать этот уникальный опыт для эффективной коммуникации с другими заказчиками и победы в новых проектах.
