Одним из ключевых моментов в больших инфраструктурных
проектах является необходимость оперативного обмена информацией
между различными подсистемами и службами. Или, проще говоря -
интеграция. И как уже неоднократно обсуждалось, понятие интеграции у
каждого свое. Кто-то подразумевает под этим термином возможность
обмена состояниями устройств между подсистемами, кто-то говорит о
возможности управления устройствами одной системы через интерфейс
другой, иногда речь идет о синхронизации различных баз данных.
И опять же важно понять, что действительно требуется заказчику и
как планируется использовать результат интеграции. И здесь, как и в
большинстве других случаев, интеграция должна стать инструментом,
обеспечивающим эффективное выполнение какого-либо процесса
(операционного или производственного). А если мы говорим о крупных
инфраструктурных объектах, количество процессов там очень
внушительное, охватывающее взаимодействие большого количества
служб. И в данной ситуации информация о ключевых событиях на одном
экране и возможность реализации межсистемных сценариев может
оказаться очень актуальной. Например, оператор ситуационного центра
на основе информации о несанкционированном доступе в помещение и
изменении информации из системы жизнеобеспечения данного
помещения может быстро определить взаимосвязь, построить сценарий
угроз и спланировать упреждающие действия
10
.
В настоящее время, пожалуй, ни один вендор на рынке не может
предложить решение, закрывающее все потребности заказчика в такого
рода проектах, даже в части систем безопасности, не говоря уж о
смежных системах. И в текущей ситуации крайне важным становится
открытость системы.
Ресина. Москва, 2019. - С. 54.
10
Горбачёва Д.Р.Управление стоимостью проекта//В сборнике: Экономика, управление,
финансы: теория и практика сборник материалов XI-ой международной очно-заочной
научно-практической конференции. В 2 т.. Москва, 2019. - С. 90.
1
Конечно же удобно, когда решение уже содержит
прединтегрированные ключевые элементы, такие как видеонаблюдение,
СКУД, охранная и пожарная сигнализация. Это позволяет
сфокусироваться на интеграции со сторонними системами. Довольно
часто возникает необходимость в интеграции с системами СМИС
(структурированная система мониторинга и управления инженерными
системами зданий и сооружений) и СМИК (система мониторинга
инженерных конструкций) или специализированными системами,
уникальными для каждого вертикального рынка, как, например,
интеграция видеонаблюдения с системой транспортировки багажа в
аэропорту или системой подсчета купюр в хранилище банка. И здесь
крайне важна не только поддержка от крытых интерфейсов и стандартных
протоколов, но и готовность производителей к интеграции своих систем.
Ведь зачастую даже поддержка одной и той же версии протокола
OPC (Open Platform Communications) или ONVIF(Open Network Video
Inter face Forum) не гарантирует успешную интеграцию. В таких
ситуациях важную роль играет позиция заказчика, который может
определить требования к интеграции и выступить «катализатором» во
взаимодействии различных вендоров. Таким образом, без тесного
взаимодействия заказчика и всех участников проекта опять никуда
11
.
В последнее время с развитием облачных технологий набирает
популярность такое направление как Video-asa-service и Security-as-a-
service, когда заказчик платит не за камеру, а за картинку, не за датчик, а
за сигнал тревоги. И многие начинают рассуждать о том, что данный
подход мог бы решить большую часть описанных выше проблем. Это и
понятно. В конечном итоге заказчик хочет получить предсказуемый
результат с заданной стоимостью капитальных вложений и стоимостью
владения. Т.е. безопасность как сервис, а может и анализ бизнес-
11
Гаврилов Д.А. Проектно–сметное дело: учеб. пособие / Д.А. Гаврилов. — М.: Альфа–М:
ИНФРА–М, 2018. – С.95.
1
процессов как сервис, когда заказчик оформляет абонентскую подписку и
получает инструмент, заточенный под решение своих бизнес-задач.
Рынок уже активно развивается в данном направлении, и вскоре мы
увидим множество интересных бизнес-моделей, ориентированных на
удовлетворение потребностей клиента здесь и сейчас. Однако, пока мы
все находимся на пути к светлому будущему, важно учитывать
особенности работы в крупных инфраструктурных проектах и
максимально вовлекать в работу над проектом всех участников на как
можно более ранних этапах.
1.2. Структура концепции проекта и требования к ее наполнению
Структура процесса «Инициация проекта» представлена на рисунке
1.
Рисунок 1 Структура процесса «Инициация проекта»
Концепция проекта «Название проекта, взятое из формулировки
цели». Текущая ситуация Раздел «Текущая ситуация» содержит описание
1
ситуации клиента (заказчика). Помните в формулировке цели было
написано «проект предназначен для». Описание ситуации выражается на
языке бизнеса - на языке понятном заказчику, а не на языке технических
терминов. Этот раздел должен продемонстрировать понимание командой
проекта текущих условий клиента (заказчика) и его желаемого будущего
состояния.
Информация из раздела «Текущая ситуация» создает общий
контекст для обсуждения проектного решения. Возможности решения
Раздел «Возможности решения» опирается на описание текущей ситуации
клиента и содержит обоснование необходимости реализации проекта
12
.
Помните при формулировке цели Вы писали «.. заинтересованной
в»?. В данном разделе это описание конкретизируется. В некоторых
случаях раздел может содержать заявление заказчика о необходимости
решения, если заказчик осознал такую необходимость.
В других случаях обоснование может заключаться в необходимости
создания инновационной продукции, повышения доходов, снижения
расходов, улучшения оперативного управления, эффективном
использовании знаний и т.д
13
.
Раздел может содержать постановку задачи заказчиком (если
заказчик ее поставил), и влияние проектного решения на проблемы
заказчика (защита доходов, сокращение расходов, соблюдение
нормативных требований, улучшение реализации стратегии или
используемых технологий). В итоге, раздел должен включать заявление о
клиента о наличии подходящей стратегии решения и технических
возможностях.
Раздел «Возможные решения» должен быть написан кратко, на
языке исполнителя. Назначение раздела Содержание раздела
12
Гаврилов Д.А. Проектно–сметное дело: учеб. пособие / Д.А. Гаврилов. — М.: Альфа–М:
ИНФРА–М, 2018. – С.103.
13
Виноградова, М.В. Бизнес-планирование в индустрии гостеприимства: Учебное пособие
/ М.В. Виноградова. – М.: Дашков и К, 2015. – С.99.
1
«Возможности решения» показывает, что команда проекта понимает
ситуацию клиента с деловой точки зрения и обеспечивает проектную
команду и других читателей стратегическим контекстом для остальных
разделов концепции.
Предлагаемое проектное решение.
Раздел «Предлагаемое проектное решение» четко и лаконично
описывает будущее желаемое положение дел у заказчика (клиента) после
того, как проект будет завершен.
Раздел пишется так, как если бы будущее состояние уже
достигнуто. Данный раздел обеспечивает контекст для принятия
решений.
Содержание раздела должно мотивировать команду проекта и
заказчика. Очень важно, чтобы видение проектного решения было
единым для всех членов команды. Раздел «Предлагаемое проектное
решение» помогает гарантировать, что проектное решение достигнет
намеченных целей
14
.
По сути, здесь Вы описываете образ желаемого будущего. Такое
«бинокулярное зрение» (когда видно исходное и конечное состояние)
укрепляет доверие и сплоченность между членами команды, уточняет
перспективу, улучшает внимание и облегчает процесс принятия решений.
Анализ выгод
Раздел «Анализ выгод» описывает, как клиент будет получать
выгоды от предлагаемого проектного решения.
Теперь конкретизируем это положение и содержание предыдущего
раздела, но в цифрах.
15
14
Герасимов К.Б., Клевцов Д.В.Развитие процесса управления производственной
стратегией предприятия// Экономика и бизнес: теория и практика. 2017. № 2. С 29.
15
Владимирова И.Л., Цыганкова А.А., Фатеев В.В.Анализзарубежных систем управления
стоиомстью строительных проектов при переходе к цифровой экономике//В сборнике:
Современные проблемы управления проектами в инвестиционно-строительной сфере и
природопользовании материалы IX Международной научно-практической конференции,
посвященной 112-летию РЭУ им. Г. В. Плеханова. Под редакцией д-ра экон. наук В. И.
Ресина. Москва, 2019. С. 60.
1
Содержание раздела должно соединить бизнес-цели и задачи с
конкретными ожидаемыми результатами от реализации проекта.
Ожидаемые результаты должны быть выражены в измеримых
показателях. В этом разделе могут быть представлены следующие
подразделы: Бизнес-цели и задачи Показатели в цифровой форме
Декларация выгод Раздел также конкретизирует бизнес-потребности
заказчика, которые могут дать важную информацию для принятия
решения по технологиям проектного решения или дать дальнейшие
рекомендации
16
.
Цели, задачи, предположения и ограничения Раздел содержит
следующие компоненты, которые определяют параметры конечного
продукта проекта:
Цель (конечная цель) - используется сформулированная ранее цель,
Задачи - подцели, которых необходимо достичь для выполнения цели (в
измеримой форме), Предположения - факторы, которые могут повлиять
на результат, но пока рассматриваются как данные или как ожидающие
проверки,
Ограничения - результат формализации нефункциональных
(неявных) требований, которые будут ограничивать конечный результат -
продукт проекта. Подраздел в целом изначально происходит из деловых и
технических целей и задач, которые были разработаны в разделе
«Возможности решения» и подтверждены в разделе «Предлагаемое
проектное решение».
Предположения и Ограничения могут быть получены из описания
функциональных возможностей продукта, а также изучения положения
дел у заказчика.
16
Воронцова Ю.В., Чиняева С.В.Теоретико – методические аспекты упрвления
стоимостью проекта//В сборнике: Шаг в будущее: искусственный интеллект и цифровая
экономика. Революция в управлении: новая цифровая экономика или новый мир машин
Материалы II Международного научного форума. 2018. С. 28.
2
Подраздел «Цель и задачи» должен быть сформулирован так, чтобы
преобразовать ожидания заказчика в измеримые показатели
производительности. Подраздел «Предположения» - попытка создать
увидеть неявные ограничения, которые всегда присутствуют, и на этой
основе указать границу, где фактические данные недоступны.
Например, когда разрабатывается учебный курс в оболочке Мудл,
то не думается о том, какое количество одновременно работающих
пользователей у него будет, а это важная техническая характеристика,
которая может повлиять на конечный продукт.
Поэтому если указывается в разделе «предположения», что
количество пользователей не повлияет на работоспособность проектного
решения, то это будет честно. Когда создается сайт, то необходимо
сделать, чтобы он работал во всех устройствах и, соответственно, для
разных разрешений экрана
17
.
Поэтому в разделе «предположения» напишем, что предполагали,
что разрешение экрана не повлияет на работоспособность. Дальше, если
наши предположения окажутся неверными, то появится основание для
того, чтобы попросить дополнительные ресурсы
18
.
Просить дополнительные ресурсы будет значительно сложнее. То,
в чем руководитель не уверен точно, необходимо описать как
предположения.
Подраздел «Ограничения» помогает конкретизировать рамки
проектного решения. В нем описывается то, законодательные,
технические, кадровые и иные ограничения, которые могут
непосредственно повлиять на характеристики проектного решения.
Раздел «Анализ использования».
17
Гаращенко О.В.Инновационные инструменты управления стоимостью долгосрочных
проектов в строительстве// Мир дорог. 2018. № 108. С. 35.
18
Гаврилов Д.А. Проектно–сметное дело: учеб. пособие / Д.А. Гаврилов. — М.: Альфа–М:
ИНФРА–М, 2018. – С.78.
2
В разделе перечислены пользователи проектного решения и их
описаны их основные характеристики. Она также описывает, как
пользователи будут взаимодействовать с решением.
В разделе конкретизируется информация об аудитории, для которой
предназначен проект. Далее информация конкретизируется в двух
подразделах
19
.
Раздел «Профили пользователей»
В разделе "Профили пользователей" описываются типы
пользователей предлагаемого решения и их основные характеристики.
Пользователи идентифицируются по своей принадлежности к группам.
Каждая группа пользователей работает в своей функциональной области.
Например, на предприятии пользователи из ИТ-подразделения и
работники бухгалтерии вместе работают в сфере бухгалтерского учета.
Важно определить характеристики - что пользователи делают, и
чем проектное решение будет им помогать. Эти характеристики могут
быть выражены в терминах деятельности: например, пользователь ведет
учет счетов-фактур и делает платежи поставщикам. Если проектируется
парк культуры и отдыха, то пользователей можно разделить по видам
деятельности: те, которые ходят, или сидят на скамейках.
Можно разделить по времени, которое согласны отдать посещению
парка: кто-то пришел на пол-дня, кто-то заскочил на минуточку. Кроме
того, профили пользователей определяют проектные группы с жизненно
важными требованиями к проектному решению.
Полный набор Профилей гарантирует, что все требования все
высокого уровня к проекту будут определены. В дальнейшем проектная
команда использует эти профили в качестве исходных при разработке
списка функций, которые должны быть у продукта проекта. Дальше эти
19
Горбачёва Д.Р.Управление стоимостью проекта//В сборнике: Экономика, управление,
финансы: теория и практика сборник материалов XI-ой международной очно-заочной
научно-практической конференции. В 2 т.. Москва, 2019. С. 90.
2
профили используются для разработки общей архитектуры проектного
решения и технического дизайна.
Команда обучение пользователей использует эти профили, чтобы
установить объем своей работы. Важно, чтобы все основные группы
пользователей и все их основные действия были описаны и
конкретизированы.
Требования Содержание раздела логически вытекает из
предыдущего раздела из описаний профилей пользователей и функций,
которые они выполняют.
Требования определяют, что проектное решение должно делать
(какие функции выполнять). Для архитектурного проекта требования
могут быть выражены в форме требований к составу проектной
документации или к характеристикам будущего объекта,
сформулированном в виде задания на проектирование.
Требования могут быть выражены в терминах функциональности
(например, если проектное решение Веб-сайт «Регистрация», то
выполнение проекта позволит пользователям регистрироваться удаленно,
организовать проживание и т.д., А также определяет правила и
параметры, которые используются в этой функциональности (например,
пользователь может зарегистрироваться только один раз, и не должны
переезжать, а должны оставаться в жилье, утвержденном отделом
путешествий.
Существуют требования как на уровне пользователя и
организационном уровне. Раздел «Требования» - мост между анализом
использования и описанием решения.
Полная формулировка требований показывает, что проектировщик
понимает потребности своих клиентов. В заявлении также становится
базовой для более детальной технической документации на стадии
планирования. Хороший анализ требований снижает риск последующих
сюрпризов.
2
Характеристики конечного продукта Раздел "Характеристики
конечного продукта" содержит характеристики проектного решения,
выраженные в плане его возможностей и функций. Содержание раздела
определяется теми требованиями, которые ранее были предъявлены в
проектному решению. Т.е список характеристик должен содержать не
только сами характеристики, но и функции, которые должен выполнять
конечный продукт. Список функций позволяет клиенту (заказчику)
совместно с командой проекта, понять, что проект будет разрабатывать и
поставлять в реальной обстановке у заказчика. Содержание раздела
должно отвечать на вопрос, какими характеристиками должен обладать
продукт проекта (проектное решение), что соответствовать всем
требованиям. Естественно, что все характеристики должны быть
выражены в цифровой форме. Остается вне рамок
В разделе «Остается вне рамок проекта» содержится список
исключений, (возможностей и функций), которых точно не будет в
конечном результате проекта. То, что выходит за рамки документации
помогает уточнить содержание (объем работ) проекта и явно заявляет, что
не будет в конечном результате. Это очень полезная практика с точки
зрения управления содержанием проекта. На практике объем по проекту
имеет склонность расти из-за того, что появляются новые требования
"хотелки" заказчика. Наличие явно выраженных исключений позволяет
этот процесс затормозить.
1.3. Нормативно – правовое и методическое сопровождение
разработки концепции проектов
Результатом процесса инициации проекта является устав проекта
(Project Charter) – документ, который формально санкционирует проект.
В него включают (прямо или путем ссылок на соответствующие
документы) потребности бизнеса, ради удовлетворения которых
предпринимается проект; описание продукта проекта. Устав проекта
2