Автор: Александр Михайлов, MBA по стратегическому управлению,
Генеральный директор компании «Консалтинг по управлению ИТ».
Материал статьи построен на базе лучшего международного опыта разработки ИТ-стратегий и практического опыта автора:

- 10 лет работы ИТ-директором;
- 15 лет проведения обучений по ИТ-стратегии;
- 17 лет консалтинга по ИТ-стратегиям (из них 7 лет в IBM);
- помощи в разработке более трех сотен ИТ-стратегий, выполнения сотен ИТ-проектов, проведения десятков стратегических сессий.
Резюме статьи: хороший портфель ИТ-проектов — это не перечень работ, а управленческий выбор компании: что делать сейчас, что подготовить, что отложить, что исключить и какой бюджет действительно нужен для развития ИТ, а именно:
- Портфель ИТ-проектов — один из главных результатов ИТ-стратегии, потому что именно через проекты стратегия превращается в практические действия, бюджет и дорожную карту.
- Портфель проектов отличается от обычного списка заявок: в нём должны быть приоритеты, зависимости, владельцы, сроки, бюджет, риски и связь с требованиями бизнеса.
- В ИТ-стратегию не нужно включать каждую мелкую задачу; в портфель должны попадать проекты, которые заметно влияют на бизнес, информационные системы, данные, инфраструктуру ИТ, ИБ, цифровую трансформацию, ИИ, бюджет или риски.
- Проекты нужно выбирать не от желаний ИТ-службы или отдельных подразделений, а от требований бизнеса, текущего состояния ИТ и требуемого состояния компании.
- В портфеле важно отдельно учитывать фундаментальные, обязательные, быстроокупаемые, развивающие, сценарные проекты, а также проекты цифровой трансформации и ИИ.
- Проекты ЦТ и ИИ должны оцениваться так же строго, как остальные: по бизнес-сценарию, данным, процессам, владельцам результата, ИБ, бюджету и возможности масштабирования.
- Приоритеты проектов зависят не только от ожидаемой пользы, но и от срочности, риска отказа, зависимостей, стоимости, готовности бизнеса, данных и ИТ-ресурсов.
Оглавление на три уровня (h1, h2, h3) (удалить перед выставлением на сайт)
ИТ-стратегия должна завершаться не красивыми формулировками, а портфелем проектов. Именно в портфеле становится видно, что компания собирается делать, в какой последовательности, за какие деньги и с каким ожидаемым результатом.
Если стратегия не помогает выбрать проекты, очередность, бюджет и ответственных, она остаётся методическим документом. Практическая ценность стратегии появляется тогда, когда из неё следует дорожная карта развития ИТ.
Портфель ИТ-проектов — это место, где ИТ-стратегия превращается в управленческие решения. Здесь становится понятно, какие проекты обязательны, какие создают фундамент, какие дают быстрый эффект, какие связаны с цифровой трансформацией и ИИ, а какие стоит запускать только при определённых условиях.
Вставить рисунок 1 — новый рисунок во всю ширину страницы.
Рисунок: «Портфель ИТ-проектов в ИТ-стратегии»
Что нарисовать: внизу — фундамент ИТ: данные, интеграции, инфраструктура, информационная безопасность. Выше — обязательные проекты. Ещё выше — быстроокупаемые проекты, проекты цифровой трансформации и ИИ. Справа — дорожная карта и бюджет. Стрелками показать зависимости между проектами.
Комментарий: эта идея уже есть в исходном файле и хорошо подходит для первого экрана статьи.
1. Почему ИТ-стратегия должна завершаться портфелем проектов
ИТ-стратегия без портфеля проектов остаётся неполной. В ней могут быть правильно описаны требования бизнеса, текущее состояние информационных систем, инфраструктура ИТ, данные, информационная безопасность, цифровая трансформация и ИИ. Но если после этого не понятно, какие проекты делать, в какой последовательности и за какой бюджет, стратегия не становится инструментом управления.
Для руководства компании портфель проектов часто важнее длинного описания текущего состояния. Именно через проекты стратегия превращается в действия: что запустить, что отложить, что завершить, что профинансировать, какие риски принять, а какие снизить.
| Раздел стратегии | Что он даёт | Как связан с портфелем проектов |
| Требования бизнеса | показывает, что нужно компании | определяет приоритеты проектов |
| Текущее состояние ИТ | показывает проблемы и ограничения | даёт основания для проектов |
| Требуемое состояние ИТ | показывает, к чему нужно прийти | задаёт целевую картину изменений |
| Данные, ЦТ и ИИ | показывают новые направления развития | добавляют проекты по данным, цифровым сервисам и ИИ |
| Информационная безопасность | показывает риски | формирует обязательные проекты |
| Бюджет | показывает ресурсные ограничения | помогает выбрать реалистичный портфель |
Главная мысль: портфель ИТ-проектов — это не приложение к стратегии, а один из её главных результатов.
Портфель проектов показывает, как именно компания будет переходить от текущего состояния к требуемому. Он помогает руководству увидеть не только отдельные работы, но и связи между ними.
| Без портфеля проектов | С портфелем проектов |
| Стратегия остаётся набором идей | Стратегия превращается в план действий |
| Проекты выбираются ситуативно | Есть приоритеты и зависимости |
| Бюджет трудно обосновать | Бюджет связан с дорожной картой |
| ЦТ и ИИ остаются лозунгами | Они входят в конкретные проекты |
| Ответственность размыта | Видны владельцы и участники |
2. Чем портфель ИТ-проектов отличается от списка заявок
Во многих компаниях под портфелем проектов фактически понимают список заявок: подразделения попросили доработки, ИТ-служба записала их в таблицу, затем список пытаются согласовать с руководством.
Такой список может быть полезен для текущего управления, но он ещё не является портфелем проектов в ИТ-стратегии. В нём обычно не хватает приоритетов, зависимостей, связи с требованиями бизнеса, оценки рисков, бюджета, владельцев и логики последовательности.
Список заявок отвечает на вопрос: что хотят сделать подразделения или ИТ-служба?
Портфель ИТ-проектов отвечает на другой вопрос: какие проекты действительно нужны компании, почему именно они, в какой последовательности и с каким бюджетом?
| Признак | Список заявок | Портфель ИТ-проектов |
| Источник | просьбы подразделений и ИТ-службы | требования бизнеса и стратегия |
| Приоритеты | часто спорные или неявные | определяются по критериям |
| Зависимости | обычно плохо видны | показываются явно |
| Бюджет | считается по отдельным строкам | связан с приоритетами и сценариями |
| Ответственные | могут быть не назначены | есть владельцы и исполнители |
| Результат | список работ | дорожная карта развития |
Список заявок может стать входом для портфеля. Но перед включением в стратегию каждую заявку нужно проверить: какую задачу бизнеса она решает, какой риск снижает, от каких проектов зависит, какой эффект даёт и что будет, если её не делать.
Cтатья «ИТ-стратегия или список ИТ-проектов: что нужно компании»
Если пока есть только перечень работ и заявок, полезно сначала разобраться, чем список проектов отличается от портфеля и полноценной ИТ-стратегии. читать
Рисунок не тот, блок недоделан.
3. Какие проекты должны попадать в ИТ-стратегию
В ИТ-стратегию не нужно включать каждую мелкую заявку. Если в стратегии появляется слишком много небольших задач, она превращается в операционный план ИТ-службы и теряет управленческий смысл.
В портфель стратегии должны попадать проекты, которые заметно влияют на бизнес, информационные системы, данные, инфраструктуру ИТ, информационную безопасность, цифровую трансформацию, ИИ, бюджет или риски.
Это могут быть не только крупные внедрения. Иногда небольшой проект по интеграции или качеству данных важнее дорогостоящей, но необязательной доработки.
| Тип проекта | Примеры | Почему попадает в стратегию |
| Проекты информационных систем | внедрение, замена, модернизация, интеграции | влияют на ключевые процессы |
| Инфраструктурные проекты | серверы, сети, резервирование, рабочие места | обеспечивают устойчивость и рост |
| Проекты по данным | справочники, качество данных, хранилище, BI | нужны для аналитики, ЦТ и ИИ |
| Проекты информационной безопасности | доступы, мониторинг, защита данных | снижают риски бизнеса |
| Проекты управления ИТ | процессы, роли, сервисная модель, управление подрядчиками | повышают управляемость ИТ |
| Проекты цифровой трансформации | цифровые сервисы, каналы, автоматизация процессов | меняют работу компании |
| Проекты ИИ | ИИ-помощники, интеллектуальный поиск, прогнозы | проверяют новые сценарии и возможности |
Граница между стратегическим проектом и обычной задачей не всегда очевидна. Хороший критерий простой: если отказ от проекта влияет на развитие компании, риски, бюджет, данные, цифровую трансформацию, ИИ или работу ключевых процессов, его стоит рассматривать на уровне стратегии.
4. Как связать проекты с требованиями бизнеса
Портфель проектов не должен начинаться с того, что ИТ-служба хочет внедрить или заменить. Он должен начинаться с требований бизнеса.
Если бизнесу нужно ускорить обработку заказов, проект может быть связан с информационной системой, интеграцией, данными, процессом или цифровым сервисом. Если бизнес хочет повысить управляемость, могут понадобиться единые показатели, BI, качество данных и регламенты ответственности. Если руководство хочет использовать ИИ, нужно сначала понять, какие сценарии действительно полезны и готовы ли данные.
| Требование бизнеса | Возможные ИТ-проекты | Как проверять приоритет |
| Ускорить обслуживание клиентов | доработка системы, интеграции, цифровой сервис | влияет ли проект на скорость и качество |
| Снизить операционные затраты | автоматизация ручных операций, аналитика | есть ли понятный эффект |
| Улучшить управляемость | данные, BI, единые показатели | нужны ли данные для решений |
| Снизить риски | ИБ, резервирование, замена устаревшей системы | что будет при отказе |
| Развивать ЦТ | цифровые сервисы, процессы, каналы | есть ли бизнес-владелец |
| Использовать ИИ | данные, доступы, пилоты, контроль качества | готова ли компания к сценарию |
Если проект не удаётся связать ни с одним требованием бизнеса, его нужно проверить особенно внимательно. Возможно, это полезная техническая задача. Возможно, её стоит оставить в операционном плане. Но не каждый полезный проект должен попадать в стратегический портфель.
Вывод: проект становится стратегическим не потому, что он дорогой или технологически интересный, а потому что он связан с требованиями бизнеса, рисками, развитием ИТ или будущими возможностями компании.
Вставить рисунок 2 — новый рисунок.
Рисунок: «От требований бизнеса к портфелю ИТ-проектов»
Что нарисовать: требования бизнеса → требуемое состояние информационных систем, данных, инфраструктуры, управления ИТ, ЦТ и ИИ → портфель проектов → бюджет и дорожная карта.
5. Как учитывать текущее состояние информационных систем, данных и инфраструктуры
Портфель проектов нельзя формировать только по ожиданиям бизнеса. Нужно учитывать текущее состояние ИТ. Иначе можно запланировать правильные по смыслу, но нереалистичные проекты.
Например, компания хочет внедрить ИИ-помощника, но корпоративные знания разрознены, доступы не настроены, документы устарели, а владельцев данных нет. Или бизнес хочет цифровой сервис, но ключевые информационные системы плохо интегрированы. Или руководство хочет быстро получить аналитику, но данные ведутся в разных системах и считаются по разным правилам.
В таких случаях в портфель должны попасть не только “верхние” проекты, но и фундаментальные работы.
| Текущее ограничение | Какие проекты могут понадобиться |
| Устаревшие информационные системы | модернизация, замена, поддержка переходного периода |
| Нет интеграций | проекты обмена данными и интеграционной архитектуры |
| Разрозненные данные | справочники, качество данных, хранилище, BI |
| Слабая инфраструктура | обновление мощностей, резервирование, мониторинг |
| Риски информационной безопасности | доступы, защита данных, реагирование на инциденты |
| Не хватает ИТ-процессов | управление изменениями, заявками, проектами |
| Нет владельцев со стороны бизнеса | проект по управлению ответственностью и ролями |
Часто именно такие проекты трудно объяснять руководству, потому что они выглядят менее ярко, чем новый цифровой сервис или ИИ-пилот. Но без них более заметные проекты могут оказаться дорогими, рискованными или невыполнимыми.
Cтатья «Данные в ИТ-стратегии»
Проекты по данным часто являются фундаментом для аналитики, цифровой трансформации и ИИ. Их нужно включать в портфель, даже если они не дают мгновенного внешнего эффекта. читать
Рисунок не тот, блок недоделан.
6. Как разделить проекты на фундаментальные, обязательные, быстроокупаемые и сценарные
Если все проекты находятся в одном списке, их трудно сравнивать. Инфраструктурный проект, ИИ-пилот, доработка учётной системы, проект по безопасности и цифровой сервис могут конкурировать за один бюджет, хотя решают разные задачи.
Поэтому в ИТ-стратегии полезно разделить проекты на группы. Это не отменяет приоритизацию, но делает обсуждение более честным.
| Группа проектов | Примеры | Как обсуждать |
| Фундаментальные | данные, интеграции, инфраструктура, архитектура, ИБ | как основу для других проектов |
| Обязательные | регуляторные требования, критичные замены, устойчивость | как проекты, которые нельзя игнорировать |
| Быстроокупаемые | автоматизация ручного труда, отчётность, улучшение процессов | как быстрый эффект для бизнеса |
| Развивающие | новые системы, цифровые сервисы, расширение возможностей | как развитие компании |
| Проекты ЦТ и ИИ | цифровые сервисы, ИИ-помощники, аналитика, автоматизация | как проверяемые сценарии и масштабирование |
| Сценарные | проекты, зависящие от бюджета, рынка и готовности бизнеса | как варианты при разных условиях |
Такое разделение помогает избежать ошибки, когда все проекты сравниваются только по ожидаемой экономии. Некоторые проекты действительно должны быстро окупаться. Но фундаментальные и обязательные проекты часто нужны не для быстрого эффекта, а для снижения рисков, устойчивости или подготовки других изменений.
Вставить рисунок 3 — новый рисунок.
Рисунок: «Группы проектов в портфеле ИТ-стратегии»
Что нарисовать: несколько уровней: фундаментальные проекты внизу, обязательные рядом как защищённый контур, выше — быстроокупаемые и развивающие проекты, отдельно — ЦТ и ИИ, справа — сценарные проекты. Внизу подпись: “разные типы проектов нельзя оценивать одинаково”.
7. Как учитывать проекты цифровой трансформации и ИИ
Проекты цифровой трансформации и ИИ часто выглядят привлекательнее обычных ИТ-проектов. Их легче представить как развитие, инновации или новый уровень эффективности. Но в портфеле ИТ-стратегии они должны оцениваться так же строго, как остальные проекты.
Цифровой проект должен быть связан с процессом, информационными системами, данными, пользователями, бюджетом и владельцем со стороны бизнеса. ИИ-проект должен быть связан с бизнес-сценарием, данными, доступами, информационной безопасностью, методикой проверки результата и правилами масштабирования.
| Проект | Что проверить перед включением в портфель |
| Цифровой сервис | какой процесс меняется и кто владеет результатом |
| Личный кабинет | какие системы и данные должны быть интегрированы |
| ИИ-помощник | какие документы, знания и доступы будут использоваться |
| Интеллектуальный поиск | насколько актуальны базы знаний и права доступа |
| Прогнозирование | есть ли исторические данные и владелец результата |
| Автоматизация документов | как будет контролироваться качество и ошибки |
| Клиентская аналитика | какие данные используются и есть ли ограничения |
Если проект ЦТ или ИИ нельзя связать с данными, процессами, владельцами и бюджетом, его лучше не включать в основной портфель как полноценный проект. Его можно оформить как гипотезу, пилот или сценарный проект.
Важно: проекты ЦТ и ИИ не должны вытеснять фундаментальные ИТ-проекты. Часто они зависят от данных, интеграций, инфраструктуры и информационной безопасности.
Cтатья «Как включить цифровую трансформацию и ИИ в ИТ-стратегию»
ЦТ и ИИ лучше включать в ИТ-стратегию не отдельным приложением, а через данные, информационные системы, проекты, бюджет и ответственных. читать
Рисунок не тот, блок недоделан.
8. Как выбирать приоритеты между проектами
Приоритет проекта зависит не только от его “важности”. В исходной заготовке уже было отмечено, что нужно учитывать влияние на бизнес, срочность, риск отказа, зависимости от других проектов, стоимость, готовность бизнеса, наличие данных и ресурсов, влияние на ЦТ и ИИ. Это хороший набор критериев, его стоит сохранить.
Но критерии не должны быть формальной таблицей. Они нужны для управленческого разговора: почему один проект должен начаться сейчас, второй можно перенести, третий нужно сначала подготовить, а четвёртый лучше исключить.
| Критерий | Вопрос для оценки | Что показывает |
| Влияние на бизнес | какую задачу бизнеса решает проект | ценность проекта |
| Срочность | что будет, если перенести проект | необходимость срока |
| Риск отказа | какой риск останется без проекта | цена отказа |
| Зависимости | какие проекты зависят от него | место в дорожной карте |
| Стоимость | сколько стоит запуск и владение | нагрузка на бюджет |
| Готовность бизнеса | есть ли владелец и участники | вероятность реализации |
| Готовность данных и ИТ | есть ли системы, данные и ресурсы | реалистичность проекта |
| Влияние на ЦТ и ИИ | создаёт ли проект основу для новых направлений | стратегическая значимость |
Иногда проект с невысоким прямым эффектом должен получить высокий приоритет, потому что от него зависят другие проекты. Например, интеграция систем может быть менее заметна, чем цифровой сервис, но без неё сервис будет работать плохо. Проект по качеству данных может выглядеть скучно, но без него ИИ-пилот будет ненадёжным.
Приоритизация должна учитывать не только выгоду, но и последовательность.
Вставить рисунок 4 — новый рисунок.
Рисунок: «Фильтр приоритизации ИТ-проектов»
Что нарисовать: вход — список проектов. Фильтры: бизнес-эффект, срочность, риск отказа, зависимости, стоимость, готовность бизнеса, данные и ресурсы. Выход — приоритетный портфель: сделать сейчас / подготовить / отложить / исключить.
9. Как связать портфель проектов с бюджетом
Портфель проектов без бюджета остаётся списком пожеланий. Бюджет показывает, какие проекты компания действительно готова делать и в каком объёме.
Но бюджет не должен формироваться просто как сумма всех желаний. В ИТ-стратегии нужно показать несколько уровней: обязательные затраты, поддержка текущей работы, фундаментальные проекты, проекты развития, быстроокупаемые улучшения и сценарные проекты.
| Часть бюджета | Что включает | Как обсуждать |
| Поддержка текущей работы | сопровождение систем, инфраструктура, подрядчики | как обеспечение работоспособности бизнеса |
| Обязательные проекты | ИБ, регуляторные требования, критичные замены | как снижение рисков и выполнение обязательств |
| Фундаментальные проекты | данные, интеграции, архитектура, инфраструктура | как основу для развития |
| Проекты развития | системы, процессы, цифровые сервисы | как изменение работы компании |
| Проекты ЦТ и ИИ | пилоты, сервисы, аналитика, автоматизация | как проверяемые сценарии |
| Сценарный резерв | проекты при наличии бюджета или условий | как гибкость стратегии |
Такой подход особенно полезен, когда бюджет ограничен. Руководство видит не просто общий объём затрат, а структуру: что обязательно, что желательно, что можно делать поэтапно, что даёт быстрый эффект, а что создаёт фундамент.
Cтатья «ИТ-стратегия и ИТ-бюджет»
ИТ-бюджет легче обосновывать, если он связан с портфелем проектов, требованиями бизнеса, рисками, данными, ЦТ и ИИ. читать
Рисунок не тот, блок недоделан.
10. Как показать зависимости между проектами
Зависимости между проектами часто важнее формального приоритета. Если не показать зависимости, компания может начать с более заметного проекта и не подготовить фундамент для его реализации.
Например, цифровой сервис может зависеть от интеграций. BI — от качества данных и справочников. ИИ-помощник — от базы знаний, доступов и информационной безопасности. Замена системы — от миграции данных и обучения пользователей. Проект информационной безопасности — от понимания критичных систем и данных.
| Проект верхнего уровня | От чего может зависеть |
| Цифровой сервис | информационные системы, интеграции, данные, пользователи |
| BI и управленческая отчётность | справочники, качество данных, хранилище, правила расчёта |
| ИИ-помощник | документы, знания, доступы, безопасность |
| Замена информационной системы | миграция данных, интеграции, процессы, обучение |
| Проект информационной безопасности | критичные системы, данные, роли, мониторинг |
| Автоматизация процесса | описание процесса, владельцы, система, данные |
В дорожной карте нужно показывать не только даты начала проектов, но и их логическую последовательность. Иногда сначала нужно сделать короткий подготовительный проект, чтобы основной проект стал реалистичным.
Зависимости помогают объяснять бюджет. Если один проект является условием для трёх других, его нельзя оценивать только по прямому эффекту.
Вставить рисунок 5 — новый рисунок.
Рисунок: «Зависимости между ИТ-проектами»
Что нарисовать: несколько проектов на дорожной карте. Проекты данных, интеграций и инфраструктуры идут раньше и стрелками связаны с цифровыми сервисами, аналитикой и ИИ. Справа — бюджет и ожидаемый результат.
11. Какие ошибки возникают при формировании портфеля
Ошибки в портфеле ИТ-проектов обычно появляются из-за попытки упростить сложную картину. Компании хочется быстро получить список проектов, утвердить бюджет и начать работу. Но если пропустить требования бизнеса, текущее состояние ИТ, данные, зависимости и владельцев, портфель будет слабым.
| Ошибка | Почему опасно | Как лучше |
| Включать все заявки подряд | портфель превращается в операционный список | отбирать проекты по стратегическим критериям |
| Оценивать проекты только по стоимости | дешёвый проект не всегда важен | учитывать эффект, риск и зависимости |
| Не показывать зависимости | проекты запускаются в неправильном порядке | строить дорожную карту |
| Игнорировать фундаментальные проекты | ЦТ и ИИ остаются без основы | включать данные, интеграции, инфраструктуру |
| Не назначать владельцев | проекты остаются задачами ИТ-службы | закреплять бизнес-владельцев |
| Не связывать с бюджетом | стратегия остаётся пожеланием | показывать стоимость и сценарии |
| Делать портфель слишком жёстким | стратегия быстро устаревает | предусмотреть регулярный пересмотр |
Главная ошибка — считать портфель простым списком работ. На самом деле портфель — это способ показать выбор компании: что важно, что можно отложить, что обязательно, что создаёт фундамент и что должно получить финансирование.

