Разбор шести этапов проекта на основе практики Polymedia – для ИТ-директоров, АХО и инфраструктурных команд
Объект сдан, видеостена работает, ВКС подключается, колонки и микрофоны в порядке, а на пульте оператора горят все индикаторы. В итоге акты подписаны, эксплуатация принимает комплекс на баланс.
Через 5-7 месяцев от службы поддержки приходят первые обращения. На совещании сорвался звонок, удалённая сторона жалуется на эхо. Через неделю оператор ситуационного центра нажимает кнопку перевода контента на главный экран, а она срабатывает не с первого раза, а ещё через месяц видеостена теряет одну из секций – помогает только перезагрузка контроллера.
Каждый эпизод сам по себе мелкий: его легко списать на «технику». Но если собрать такие симптомы из разных проектов, видна общая логика: они приходят оттуда, где на одном из этапов проекта что-то было сокращено или пропущено. Разница между AV-проектом «под ключ» и поставкой оборудования не в том, как сдан комплекс, а в том, как вся система ведёт себя под нагрузкой через полгода после сдачи.
В практике департамента системной интеграции Polymedia путь любого AV-проекта складывается из шести этапов. Дальше – коротко по каждому: что входит в этап и какие симптомы могут появиться через несколько месяцев после сдачи, если этап был скомкан.
1. Обследование и сценарии
Первый этап начинается до того, как кто-либо обсуждает оборудование. Команда проектировщиков проводит интервью с пользователями – операторами, руководителями совещаний, секретарями, дежурными сменами; параллельно ведёт аудит текущей инфраструктуры (что есть на объекте, какая сеть, какие смежные системы заказчика придётся учитывать) и фиксирует управленческие сценарии: кто, что и в какой последовательности делает в типовой рабочий день. Отдельный блок – требования к сети передачи данных и информационной безопасности.
На этом же этапе определяется граница между «как должно быть в идеале» и «как реально будет работать с учётом ИТ-ландшафта заказчика».
Если этап скомкан, в эксплуатации это всплывает так:
- операторы находят свои воркэраунды – заходят в обход системы, ведут совещания на личных устройствах, дублируют функции;
- часть закупленного оборудования не используется;
- эксплуатация жалуется на «неудобство», хотя формально система работает по ТЗ.
Поэтому, по мнению нашей команды, без этого этапа проект превращается в набор устройств.
2. Функциональный дизайн
После обследования собирается архитектура системы: какие подсистемы войдут в контур и как они будут связаны между собой. Прорабатываются интеграции с внешними системами заказчика – корпоративной ВКС, СКУД, контент-серверами, BI-платформами, телеметрией. Описываются роли и доступы пользователей, требования к нагрузке, логика управления.
По концентрации отложенных проблем этот этап самый «производительный». Сюда уходят корни большинства симптомов, которые позже воспринимаются как «глюки техники».
Эхо и плохое качество звука на ВКС чаще всего приходят оттуда, где акустика помещения и маршрутизация аудиосигнала не были смоделированы на бумаге. Потери видеосигнала между источниками возникают там, где в архитектуре пропустили полосу пропускания, протокол передачи или совместимость кодеков. А кнопка управления, которая «не реагирует с первого раза», обычно указывает на то, что логику управления собирали под оборудование, а не под пользовательский сценарий.
3. Пилот
Если объект сложный (крупный, многоплощадочный, с нетиповой комбинацией подсистем), перед основной реализацией собирается пилотный контур. На нём проверяют:
• нагрузку и производительность под реальным трафиком;
• удобство сценариев использования для операторов;
• совместимость компонентов в сборке;
• устойчивость к отказам и потере связи.
Только после пилота принимается решение о тиражировании на остальные точки или о масштабе основной инсталляции.
Когда пилот пропускают, заказчик получает скрытые риски, которые проявляются уже в эксплуатации. Часть оборудования может «почти работать»: функционировать в штатном режиме, но раз в неделю давать сбой совместимости, который в большом объекте локально уже не отловить. Конфликты между подсистемами, которые на пилоте увидели бы за неделю, на объекте растягиваются на месяцы и собирают жалобы от каждой команды, работающей с комплексом.
4. Реализация
Здесь начинается то, что внешне выглядит как «весь проект»: монтаж, прокладка трасс, пусконаладка. По сути же это середина проекта.
Реализация требует постоянной координации со стройкой и плотного взаимодействия с ИТ-службой заказчика. Если ИТ-службу подключить поздно, AV-оборудование часто оказывается «в гостях» у сети, которая не готова его принять. Перед сдачей проводится тестирование по сценариям, а не только по списку оборудования. Приёмка идёт по критериям, согласованным заранее: не «всё включилось», а «выдержали нагрузку, отработали отказ канала, переключились на резервный источник за заданное время».
Если критерии приёмки сформулированы обще («оборудование работает, изображение есть, звук есть»), формально систему сдадут, но реальные нагрузочные и стресс-сценарии в чек-лист в итоге не войдут и начнут проявляться в процессе эксплуатации.
5. Ввод в эксплуатацию
Этот этап чаще всего недооценивают. Кажется, что после подписания актов остаётся «передать ключи». На самом деле, именно здесь решается, будет система жить как положено или начнёт медленно разваливаться.
В этап входят:
- обучение пользователей – операторов, технических администраторов, инженеров эксплуатации, дежурных смен;
- письменные инструкции и регламенты – что делать при штатной работе, что при сбое, кому звонить и каков порядок восстановления;
- SLA на поддержку с зафиксированным временем реакции и временем восстановления;
- порядок обновлений – кто и когда меняет прошивки, патчит ПО, обновляет драйверы, разворачивает релизы безопасности.
Если же этап прошёл формально, симптомы тоже типовые. Операторы не знают, как восстановить контент после сбоя, и ждут вызова инженера на каждую мелочь. ИТ-служба не понимает, где её зона ответственности заканчивается и начинается зона интегратора. Обновления накатываются хаотично или не накатываются вовсе. По нашей практике, без этого этапа система быстро теряет управляемость, и через год её состояние заметно отличается от того, в котором её сдавали.
6. Эксплуатация и развитие
AV-система живёт 3-5 лет и более. За это время меняется бизнес: появляются новые задачи, форматы совещаний, виды контента, новые подразделения. И меняются смежные системы: корпоративная ВКС переезжает на новую платформу, БД меняет схему, ИБ ужесточает требования.
Поэтому шестой этап – это не «обслуживание», а развитие. Сюда входят: план обновлений, масштабирование под новые подразделения и площадки, адаптация сценариев под изменившуюся работу, регулярный аудит и точечная модернизация.
Если этот этап отсутствует, система постепенно перестаёт соответствовать тому, как реально работает бизнес. Формально она стоит, индикаторы зелёные. Фактически – её обходят, потому что задачи уже не те, а оборудование под них не настроено. Это, пожалуй, самый дорогой сценарий потери инвестиций в AV-инфраструктуру: оборудование цело, а толку от него уже мало.
Симптомы в эксплуатации и где они закладываются
Если собрать некоторые типовые жалобы, которые приходят через несколько месяцев после сдачи AV-системы, и сопоставить их с этапами, на которых проблема обычно закладывается, получается такая таблица. Она же может работать как чек-лист при выборе подрядчика или при разборе своей действующей системы.
Главное наблюдение по этой таблице: ни один из перечисленных симптомов не закладывается на этапе монтажа. Все они уходят корнями в этапы 1, 2, 3 и 5 – те, которые в логике «поставки железа» обычно проходят формально или пропускаются. На самой реализации можно сделать всё аккуратно по чертежам и всё равно получить через полгода те же жалобы, если хотя бы один из остальных пяти этапов был срезан.
Почему мы об этом говорим
Канал ведёт Департамент системной интеграции Polymedia – команда, которая больше 27 лет проектирует и строит AV-системы для ситуационных центров, диспетчерских, конференц-залов, офисных и музейных пространств. Если в собственной практике сталкивались с похожими симптомами «после приёмки», приглашаем в наши демонстрационные залы в Москве – обсудить будущие задачи и проекты.
Подробнее о проектах – на сайте polymedia.ru.
Короткие разборы и кейсы – в Telegram-канале @POLYMEDIA_INTEGRATION. Там же работает чат-бот для быстрых вопросов.