Когда зелёные проекты не складываются в результат
Понедельник, управленческое совещание. В отчёте всё выглядит убедительно: CRM введена в эксплуатацию, хранилище данных принято, личный кабинет открыт для пользователей. Каждый руководитель проекта показывает выполненный объём, срок и бюджет. Затем звучит простой вопрос: сократилось ли время обслуживания, стала ли точнее управленческая информация, перестал ли сотрудник переносить данные между системами вручную?
Если ответ приходится собирать после совещания, компания, вероятно, управляет поставками, а не трансформацией.
ИТ-проект отвечает на вопрос «что создать или внедрить». Программа изменений отвечает на другой вопрос: «какое состояние бизнеса должно стать обычной работой и какие связанные изменения для этого необходимы». Разница не в масштабе бюджета и не в слове «цифровой» в названии.
В актуальном стратегическом направлении Правительства России для обрабатывающих отраслей цифровая зрелость связана с модернизацией управления производственными и бизнес-процессами и переходом к решениям на основе данных. Это отраслевой документ, а не универсальная обязанность частной компании. Но его управленческая логика важна: технология является средством изменения процесса и результата, а не самостоятельным финалом.
Тот же принцип виден в рекомендациях по стратегиям цифровой трансформации 2025 года: документ охватывает содержание стратегии, мониторинг реализации и отчётность. Формальные требования предназначены прежде всего для компаний с государственным участием, однако связь целей, инициатив и проверки результата применима шире.
Зелёный проектный статус всё ещё полезен. Он показывает, что команда поставила обещанный компонент. Он не доказывает, что компонент вошёл в работу, данные стали достовернее, сотрудники изменили действие, а бизнес получил ожидаемый результат.
Что превращает проекты в программу
Стандарт PMI по управлению программами описывает программу как координацию связанных проектов ради стратегической цели и выгод, которые превышают сумму отдельных результатов. ISO 21503:2022 распространяет общие практики управления программами на организации любого типа и размера. Эти международные документы не задают российские обязанности, но дают полезную границу: несколько проектов становятся программой только при общей выгоде и взаимозависимостях.
Для управленческой проверки достаточно четырёх признаков.
- Есть общий бизнес-результат. Не «внедрить три системы», а изменить наблюдаемую характеристику работы: срок цикла, долю ошибок, доступность услуги, качество решения или стоимость операции. Конкретный показатель выбирается по процессу, а не берётся из универсального списка.
- Результаты проектов зависят друг от друга. Новая CRM не даст целевой отчёт без справочников, интеграции и правил ввода. Хранилище не улучшит решение руководителя без владельца показателя и ритма его использования.
- Изменяется повседневная работа. В программу входят обучение, новые роли, правила исключений, поддержка и отказ от старого способа. Иначе новая система живёт рядом со старой таблицей.
- Есть управление выгодой, а не только поставкой. Кто-то вправе менять очередность, пересобирать компоненты и останавливать инициативу, если связь с результатом не подтверждается.
Российские данные показывают, почему такую связь трудно удержать внутри одного проекта. В исследовании ИСИЭЗ НИУ ВШЭ 2026 года опрошено более 1,7 тыс. организаций машиностроения. За 2022–2024 годы значимые изменения чаще отмечались в производстве и администрировании; на 2025–2027 годы наиболее высокие ожидания связаны уже со стратегическим управлением, администрированием и производством. Это данные одной отрасли, а не прогноз для любой компании. Они подтверждают другое: цифровое изменение проходит через несколько функций одновременно.
Диагностическая карта из пяти полей
Перед следующим решением по бюджету возьмите одну инициативу и заполните пять строк. Это не модель сертификации и не замена финансового расчёта. Карта нужна, чтобы быстро увидеть разрыв между системой и результатом.
| Поле | Вопрос генерального директора | Минимальное доказательство | Тревожный сигнал |
|---|---|---|---|
| Результат | Какое состояние бизнеса должно измениться? | Исходный уровень, целевое направление изменения, единица измерения и владелец результата | Успех описан запуском системы, количеством функций или освоением бюджета |
| Процесс | Как по-другому пройдёт одна рабочая операция? | Схема целевого шага, роли, исключения и старый способ, который перестанет использоваться | Новый интерфейс добавлен поверх прежнего маршрута и ручных таблиц |
| Данные | По каким данным мы увидим изменение? | Источник, правило расчёта, периодичность, контроль качества и владелец показателя | Метрика собирается вручную после запуска или разные подразделения считают её по-разному |
| Технология | Какие компоненты и зависимости делают результат возможным? | Карта систем, интеграций, прав, эксплуатации, безопасности и способ безопасного возврата | Каждый проект оптимизирует свой план, а общая зависимость не имеет владельца |
| Ответственность | Кто отвечает за результат после приёмки? | Владелец бизнес-результата, владельцы компонентов, решение по внедрению в работу и право остановки | После релиза ответственность заканчивается у проектной команды, а бизнес «должен начать пользоваться» |
Сильная карта читается слева направо. Результат требует изменения процесса. Процесс создаёт требования к данным. Данные и правила определяют технологию. Ответственность удерживает связь после запуска.
Слабая карта обычно начинается справа: уже выбран продукт, затем под него ищут процесс, пользу и владельца. В таком порядке бизнес-обоснование становится защитой принятого решения, а не способом принять его.
Как пересобрать портфель за 90 минут
Для первой проверки не нужен новый комитет. Нужна одна инициатива, её бизнес-владелец, руководитель поставки и люди, отвечающие за процесс, данные и эксплуатацию. Девяносто минут — рабочая рекомендация НТА, а не универсальный норматив.
| Время | Действие | Решение на выходе |
|---|---|---|
| 0–15 минут | Записать один результат и исходный уровень | Понятно, ради чего существует инициатива и чего пока нельзя утверждать |
| 15–35 минут | Пройти одну операцию от события до результата | Видно, какие действия, роли и исключения действительно меняются |
| 35–50 минут | Назвать источники данных и владельца метрики | Понятно, можно ли проверить эффект без ручного отчёта задним числом |
| 50–70 минут | Нанести системы, интеграции, безопасность и эксплуатацию | Видны зависимости между проектами и условия безопасного запуска |
| 70–90 минут | Назначить ответственность и принять решение | Инициатива остаётся компонентом программы, возвращается на обследование, становится отдельным проектом или останавливается |
Остановка здесь не означает провал. Она защищает компанию от расхода на компонент, которому пока не найдено место в целевом процессе. Возврат на обследование также не равен бесконечному анализу: команда должна перечислить недостающие доказательства и дату следующего решения.
В исследовании ИСИЭЗ НИУ ВШЭ для машиностроения пять главных барьеров выглядят как набор межпроектных зависимостей: средства на модернизацию, адаптация решений, срок окупаемости, риск информационной безопасности и интеграция с инфраструктурой. Доли нельзя переносить на другую отрасль, но сами категории полезно проверить до того, как каждая окажется спрятана в отдельном плане.
После такой сессии вместо списка систем появляется карта решений:
- какой результат компания защищает;
- какие проекты образуют одну цепочку;
- что можно поставить независимо;
- какое изменение должно войти в ежедневную работу;
- где находятся данные для проверки;
- кто принимает решение о продолжении, изменении или остановке.
Когда отдельный ИТ-проект остаётся правильным форматом
Не всякую инициативу нужно объявлять трансформацией. Самостоятельный проект уместен, когда результат локален, границы понятны, а общая выгода не зависит от согласованного изменения нескольких процессов.
Так может выглядеть обязательное обновление компонента, устранение конкретного риска, замена оборудования по жизненному циклу или ограниченный эксперимент. У такого проекта всё равно должны быть заказчик, критерий приёмки, карта зависимостей и эксплуатационная ответственность. Но ему не требуется искусственно создавать общий трансформационный сюжет.
Есть простой тест. Если два проекта можно выполнить в разной очередности, и каждый сохранит самостоятельную ценность без изменения ролей, данных и работы соседнего подразделения, вероятно, ими можно управлять раздельно. Если ценность одного возникает только после другого, а результат проявляется в общем процессе, перед вами кандидат в программу.
Отдельный формат также полезен для обратимого эксперимента. Компания проверяет гипотезу на ограниченном участке, заранее задаёт критерий продолжения и безопасно прекращает работу, если данных недостаточно. Эксперимент становится частью программы только после подтверждения связи с общим результатом.
Где здесь НТА
До выбора платформы полезно проверить сам процесс. Для этого можно использовать матрицу готовности бизнес-процесса к автоматизации: она помогает увидеть частоту операций, вариативность, исключения, данные и цену ошибки.
Затем технология получает своё место. Каталог решений НТА показывает возможные контуры корпоративной автоматизации, а BPMSoft Конструктор — один из способов реализовать формы, маршруты и расширения. Ни каталог, ни low-code-платформа не заменяют общего результата, владельца данных и решения о прекращении старого процесса.
Если инициативы уже идут параллельно, команда НТА может провести совместный разбор одной цепочки: от результата и процесса до интеграций, эксплуатации и границ первой версии. Предмет разговора — не новый список систем, а доказуемая связь между изменением и работой компании.
Тест понедельником
На ближайшем совещании выберите одну дорогую цифровую инициативу и не просите процент готовности. Попросите показать пять вещей:
- Один бизнес-результат и его исходный уровень.
- Одну операцию, которая после запуска выполняется иначе.
- Источник данных, по которому компания увидит изменение.
- Зависимости, без которых результат не возникнет.
- Человека, который отвечает за результат после приёмки системы.
Если ответы помещаются на одной странице и складываются в причинную цепочку, перед компанией, вероятно, программа изменений. Если есть только дорожная карта внедрений, будущее пока существует в проектных отчётах.
Будущее должно выдержать понедельник: обычный сотрудник проходит новый процесс, исключение не возвращает всех в таблицу, руководитель видит достоверный показатель, а владелец результата может объяснить, почему программу следует продолжить, изменить или остановить.
Важное уведомление
Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.
«Понедельник, управленческое совещание.»
- 01Запуск системы подтверждает поставку компонента, но не доказывает изменение бизнес-результата или ежедневной работы.
- 02Проекты становятся программой, когда связаны общей выгодой, данными, процессами, очередностью и ответственностью после запуска.
- 03Карта результат — процесс — данные — технология — ответственность помогает решить, какую инициативу связать с программой, пересобрать, оставить самостоятельной или остановить.