Рецепт приготовления СЦ

Границы проекта должны быть формализованы в виде высокоуровневых ТЗ по разделам:

• программное обеспечение;
• информационная безопасность;
• вычислительный комплекс;
• мультимедиа;
• инженерная инфраструктура;
• строительно-монтажные работы.

На требования к СЦ существенно влияют уже функционирующие в организации информационные системы, эксплуатируемое оборудование и помещения. Поэтому до начала формирования ТЗ нужно провести комплексное обследование инфраструктуры. Его результаты позволят не только оптимизировать проект за счет использования уже имеющейся инфраструктуры, но и снизить риск возникновения нереализуемых требований.

Кроме того, результатами первого этапа должны стать согласованный календарный план реализации портфеля проектов по созданию СЦ и его бюджетная оценка.

Шаг второй

Этот этап можно охарактеризовать как самый сложный и трудоемкий с точки зрения сбора и анализа требований. Ошибки, совершенные на этом этапе, могут иметь плачевные последствия, обнаружить которые зачастую можно только на поздних этапах. Именно на втором шаге вовлеченность экспертов заказчика и подрядчиков должна быть максимальной.Этот этап является также самым напряженным с точки зрения коммуникаций и всевозможных «трудностей перевода», поскольку происходит погружение команды в бизнес-процессы, нередко специфичные и уникальные.

Условием успешного завершения данной фазы является включение в состав проектной команды как бизнес-аналитиков, обладающих глубокой предметной экспертизой, так и технических специалистов по каждому направлению — от программной архитектуры до строительно-монтажных работ и инженерных систем. В противном случае есть риск сформировать требования, которые окажутся либо недостаточно полными и потребуют дополнительного анализа (с сопутствующим срывом сроков), либо вовсе нереализуемыми.

Возглавлять команду в техническом и методологическом плане должен сильный эксперт, обладающий стратегическим системным мышлением, способный удерживать в голове картину целиком, выступать единой точкой контакта при взаимодействии с заказчиком и управляющим комитетом. Называться он может по-разному: главный конструктор, архитектор проекта, методолог и т.д.; главное — он должен принимать решения, понимая все аспекты СЦ, но при этом не теряя леса за деревьями, т.е. без погружения в детали.

Теперь необходимо формализовать ранее сформированные требования в разбивке по всем разделам и создать частные технические задания на подсистемы в соответствии с очередями создания СЦ. Предметно-функциональные матрицы объектов управления уточняются и детализируются до конкретных показателей, алгоритмов и методик их сбора, расчета и обработки. Формируются детальные требования к автоматизации деятельности СЦ и инструментам поддержки принятия решений.

Вслед за этим нужно приступать к эскизному проектированию, включая описание процессов и основных технических решений. На этом этапе выбираются конкретные программные и аппаратные решения, определяются целевая архитектура СЦ и технологический стек.

Шаг третий

Цель третьего этапа — подготовка технической документации, необходимой и достаточной для реализации всех компонентов СЦ и ввода его в эксплуатацию. Ключевой документ, создаваемый на этом этапе, — технический проект и пояснительная записка к нему.

Довольно распространенная проблема — вынужденное перепроектирование вследствие того, что предложенные решения существенно превышают возможности бюджета. Поскольку на этом этапе велико количество вовлеченных сторон (это и специалисты заказчика, и многочисленные подрядчики, причем каждый отвечает за свою, довольно узкую область), возникают случаи искажения информации при коммуникациях. И когда вводные размыты, а риски при этом высоки, в проект начинают закладываться решения с запасом, которые гарантированно удовлетворят требованиям, но будут неоправданно дорогими.

Выход — сохранить вовлеченность экспертов по предметным областям. Именно они в состоянии сформировать оптимальные решения с точки зрения соответствия требованиям и бюджетным ограничениям. Несмотря на то что глубина участия экспертов, особенно стратегического уровня, на этапе детального проектирования существенно ниже, чем на более ранних стадиях, их присутствие в проекте, а также архитектурный и технический надзор жизненно необходимы.

Одним из очевидных результатов проектирования будет набор детальных спецификаций на поставку программно-технических средств для комплектования СЦ. Не следует также упускать из виду важнейший элемент, без которого ввод СЦ в эксплуатацию станет напоминать лотерею — проекты нормативных документов, регламентирующих как работу персонала самого СЦ, так и подразделений вокруг него (непосредственно субъектов управления). Практика показывает, что без регламентов, введенных в эксплуатацию на момент запуска СЦ, заказчик получает отрицательный эффект вместо ожидаемой выгоды.

Шаг четвертый и дальнейшие (очереди, или итерации)

На данном этапе выполняются инженерно-строительные работы, монтаж аппаратного комплекса, реализация и тестирование функциональности ИАС соответственно своей очереди, разработка рабочей документации, а также ввод ИАС СЦ в эксплуатацию с подготовкой приемо-сдаточной документации.

Хотелось бы особо отметить вопросы создания «мозга» СЦ — информационно-аналитической системы. В отличие от остальных компонентов СЦ реализация программного обеспечения находится в зоне повышенных рисков срыва сроков и выхода за рамки бюджета. Причем эти риски сохраняются даже при качественно проработанном техническом проекте. Можно достаточно хорошо представить себе, как будет выглядеть ситуационная комната еще до того, как она будет оборудована фактически (используя 3D-моделирование при создании дизайн-проекта). И если, к примеру, вы заказываете видеокуб с диагональю 21", скорее всего вам привезут именно видеокуб с диагональю 21". Но в части ИАС ситуация куда менее определенная, а на этапе реализации зачастую возникают вынужденные или случайные отступления от проектных решений.

Снизить такие риски позволяют три метода: прототипирование, итеративность и пилотирование.

В первом случае макеты ИАС разрабатываются на ранних стадиях и демонстрируются пользователям. Часть функций может быть не реализована, некоторые могут работать на «заглушках», а если используются коробочные решения, возможна демонстрация их базовых версий.

Второй метод на первый взгляд связан с первым. В данном случае в рамках каждой итерации разрабатывается функциональность, направленная на полное решение определенной задачи, функциональной или предметной. Результатом итерации является законченный функциональный блок, который принимается (или не принимается) пользователями.

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

Как не обжечься

Имеет смысл указать несколько типичных проблем проекта внедрения ситуационного центра.

Зависимость от поставщика

Очень соблазнительно сократить бюджет проекта, отказавшись от инструментов самообслуживания и сопутствующей необходимости повышения квалификации персонала. Это кажется возможным, так как большую часть функциональных задач можно жестко определить, а модернизацию СЦ запланировать как отдельное мероприятие.

Однако структура аналитической отчетности меняется с изменением потребностей управления, а системы — источники данных интенсивно развиваются, подстегиваемые спросом ситуационного центра на данные. В итоге стоимость доработок «по рамке» значительно превышает затраты на внедрение средств самообслуживания.

Поэтому рекомендуем заранее предусмотреть:

• возможность самостоятельной настройки отчетности и управления НСИ;
• поддержку универсального открытого интерфейса обмена данными;
• расширяемую библиотеку стандартных средств инфографики;
• разделение инструментов графического представления по назначению: демонстрация, повседневная работа.

С учетом огромного пространства для развития комплекса СЦ избыточная зависимость создает проблемы как для заказчика, так и для поставщиков.

Недоступность информации

Если принять за аксиому, что ситуационный центр обеспечивает доступность полной, актуальной и достоверной информации о ситуации в организации, фактическая невозможность получить доступ ко всей необходимой информации после внедрения СЦ вызывает большое разочарование. Причины этого обсуждаются в статье «Ситуационный центр как инструмент управления». Здесь же отметим, что избежать подобных ситуаций позволят организационная подготовка, создание и внедрение в практику регламентов информационного взаимодействия, учитывающих все аспекты процессов в организации. Важно также обследовать источники и процессы обработки необходимых данных до момента фиксации технической архитектуры решения. По результатам этого обследования также можно адаптировать действующие процессы обработки информации.

Обманутые ожидания

Теоретически возможность принятия решений на основе фактов обеспечивает оперативность и повышение качества управления. На практике принятые решения не обязательно будут доставлены и приняты к исполнению своевременно и без искажений. Корень проблемы лежит в организационной неупорядоченности процесса управления и недостатке корпоративной дисциплины.

Поэтому очень важно провести организационную подготовку на объектах управления и, как минимум, регламентировать процессы управления. С технологической точки зрения необходимо обеспечить поддержку ситуационным центром всего контура управления, включая обратную связь, прямо влияющую на качество процесса управления (рис. 1).

Нарушение границ проекта

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

Однако несогласованность, а порой даже несовместимость интересов функциональных заказчиков приводит к образованию участков системы, работающих по своим правилам. Островки «своих данных» и «своих систем» вне интегрированного комплекса повышают стоимость и снижают эффективность ситуационного центра.

Поэтому мы рекомендуем следовать коммуникационному плану и управлять границами проекта максимально открыто, а на начальном этапе обеспечить независимый и комплексный аудит ИТ-ландшафта и источников данных (рис. 2).

Каждый проект внедрения ситуационного центра — уникальная история. Однако в опыте крупнейших поставщиков решений данного класса заключен большой пласт отраслевой и функциональной экспертизы, и им не стоит пренебрегать. Вовлекать в проект технологического партнера лучше в самом начале, когда СЦ существует еще на уровне хорошей идеи.