Привет! Меня зовут Константин Замков, я главный менеджер в компании «СИБИНТЕК». Я занимаюсь управлением проектами и портфелями проектов и являюсь сертифицированным профессионалом (PMI PMP, PMI PfMP, PSM‑I). За годы работы с корпоративными ИТ‑инициативами я заметил, что успех проекта во многом определяется еще до того, как разработчик пишет первую строчку кода.

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

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

Особое внимание уделю разделению двух понятий:

• допроектная проработка — подготовка и финансирование самого процесса инициирования, то есть OPEX

• инициирование проекта — детальная проработка будущего решения и обоснование общего бюджета проекта, то есть CAPEX.

На мой взгляд, именно такое разделение позволяет избежать многих проблем еще до начала основных работ.

1. Сначала определяем потребность и выстраиваем коммуникации

Прежде чем запускать какие‑либо формальные процедуры, необходимо понять, что именно хочет получить бизнес, кто заинтересован в результате и какие подразделения должны участвовать в работе.

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

Шаг 1. Собираем исходную информацию

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

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

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

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

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

Шаг 2. Формализуем идею в «Запросе на автоматизацию»

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

В документе фиксируются основные характеристики будущей инициативы:

• цель проекта

• ожидаемый бизнес‑эффект

• предполагаемые сроки

• предварительная стоимость

• функциональные требования.

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

При этом не стоит пытаться сразу превратить запрос в подробное техническое задание. На данном этапе задача другая — сформировать общее понимание того, что именно и зачем необходимо автоматизировать.

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

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

2. Планируем ресурсы и бюджет стадии инициирования

Когда запрос сформирован и согласован, следующим шагом становится подготовка самой стадии инициирования.

Для того чтобы определить будущий CAPEX, сначала необходимо потратить определенный объем ресурсов на детальную проработку. Иными словами, нужно отдельно спланировать и профинансировать OPEX стадии инициирования.

Шаг 3. Определяем границы работ

На основании «Запроса на автоматизацию» и имеющихся функциональных требований совместно с главным архитектором определяется, какие работы потребуется выполнить на стадии инициирования.

Одновременно устанавливается необходимый состав специалистов и их квалификация. В зависимости от проекта это могут быть аналитики, архитекторы, консультанты, специалисты по инфраструктуре, эксперты по информационной безопасности и другие профильные специалисты.

Определяем, какие компетенции потребуются для подготовки полноценной оценки и детальных функционально‑технических требований.

Шаг 4. Планируем ресурсы

После определения состава работ в системе управления проектной деятельностью формируется план стадии инициирования. Параллельно в системе ресурсного планирования фиксируется потребность в необходимых специалистах.

Таким образом, еще до фактического начала работ появляется понимание того, кто должен участвовать в инициировании и какой объем ресурсов потребуется.

Шаг 5. Формируем бюджет OPEX

Следующим этапом рассчитывается стоимость самой стадии инициирования.

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

После того как расчет согласован с заказчиком, выделяется операционный бюджет(OPEX).

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

3. Инициирование: от общей идеи к детальному решению

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

Шаг 6. Разрабатываем функционально‑технические требования

Одним из основных результатов стадии инициирования становится документ с функционально‑техническими требованиями(ФТТ). Работу по его подготовке необходимо организовать таким образом, чтобы требования были согласованы всеми ключевыми участниками.

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

В документе необходимо описать как функциональную, так и техническую составляющую будущего решения. В частности, ФТТ должны содержать:

Функциональные требования

Здесь описывается, какие возможности должна предоставить система и какие пользовательские сценарии она должна поддерживать.

Технические требования

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

Требования информационной безопасности

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

Шаг 7. Разрабатываем и согласовываем архитектурное решение

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

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

Это важная контрольная точка, поскольку архитектурное решение является необходимой основой для дальнейшего бюджетирования проекта.

Шаг 8. Детализируем бюджет и защищаем CAPEX

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

Что в итоге дает такой подход

Допроектная проработка — это гораздо больше, чем просто предварительная продажа услуги или подготовительная работа перед запуском проекта. Это этап подготовки инвестиционного решения.

До начала основных работ необходимо убедиться, что:

• бизнес и ИТ одинаково понимают цели будущего проекта

• ключевые заинтересованные стороны вовлечены в процесс

• определены необходимые компетенции и ресурсы

• существует понимание стоимости стадии инициирования

• подготовлена основа для последующей детальной оценки

• подтверждена целесообразность дальнейшего движения.

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

Три условия для перехода к инициированию

На практике я считаю, что полноценное инициирование проекта можно начинать, когда выполняются условия:

1. Утвержден «Запрос на автоматизацию».

2. Выделен бюджет на проведение стадии инициирования.

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

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

Заключение

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

После получения OPEX можно переходить к полноценной детальной проработке: формировать ФТТ, разрабатывать архитектурное решение, уточнять календарный план и рассчитывать стоимость будущего проекта. И только после этого появляется возможность обоснованно защищать CAPEX и переходить к реализации.

В итоге последовательность выглядит следующим образом: идея бизнеса → сбор исходных данных → письменный запрос на автоматизацию → планирование ресурсов → бюджетирование OPEX → детальные ФТТ → архитектурное решение → детальная оценка CAPEX → защита бюджета → начало реализации проекта.

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