
Когда слышишь ?информационная система управления проектами цифровой проект?, в голове сразу возникает образ идеального инструмента: всё автоматизировано, отчёты генерируются сами, риски предсказываются алгоритмами. Но на практике, особенно в сфере цифровой трансформации, всё часто упирается не в функционал системы, а в то, как её внедряют и как она вписывается в живые процессы команды. Многие заказчики, включая некоторых наших партнёров, ошибочно полагают, что купив ?коробочное? решение, они автоматически получат управление проектами. Это первое и самое распространённое заблуждение.
В работе с ООО Хэнань Цзюйхэ Текнолоджи, которая позиционирует себя как ведущий поставщик услуг цифровой трансформации, мы часто сталкиваемся с этим разрывом. Компания помогает клиентам переходить на цифровые рельсы, но внутреннее управление такими проектами — отдельная история. Цифровой проект — это не просто проект с использованием IT. Это часто гибридная структура, где нужно управлять и разработкой, и изменениями в бизнес-процессах, и данными, и людьми, которые могут сопротивляться новому.
Информационная система управления (ИСУП) в таком контексте — это не просто трекер задач. Это должна быть платформа, которая умеет работать с Agile- и Waterfall-компонентами одновременно, интегрироваться с системами аналитики и, что критично, быть достаточно гибкой для быстрого изменения самих процессов управления. Мы пробовали использовать стандартные решения вроде Jira или отечественные аналоги, но постоянно натыкались на необходимость глубокой кастомизации под каждый конкретный кейс цифровой трансформации.
Например, в одном проекте по автоматизации логистической цепочки для крупного ритейлера, который мы вели совместно со специалистами из ООО Хэнань Цзюйхэ Текнолоджи, ИСУП должна была отображать не только этапы разработки ПО, но и синхронизировать их с физическими изменениями на складах, обучением персонала и сменой документооборота. Готовых решений ?из коробки? для такого не нашлось. Пришлось фактически собирать систему из модулей, используя API для связи между трекером задач, CRM и системой документооборота клиента. Это был болезненный, но очень показательный опыт.
Исходя из такого опыта, сформировался некий список неочевидных на первый взгляд требований. Во-первых, система должна иметь открытую архитектуру. Закрытые системы, какими бы мощными они ни были, рано или поздно станут узким местом, когда потребуется подключить специфичный источник данных или отдать данные во внешнюю BI-систему для анализа.
Во-вторых, критически важна визуализация связей. В цифровом проекте всё взаимосвязано: задержка в одном модуле ПО может сдвинуть пилотное внедрение, а значит, и обучение пользователей. Диаграммы Ганта здесь часто бессильны. Нужны инструменты, показывающие зависимости между техническими задачами, бизнес-процессами и ресурсами. Иногда для этого приходится использовать отдельные инструменты визуализации, что создаёт дополнительные точки интеграции.
В-третьих, и это, пожалуй, самое важное — система должна учитывать человеческий фактор. Внедрение цифрового решения — это всегда изменение работы для людей. Поэтому в ИСУП должен быть встроен механизм трекинга не только технических задач, но и задач по change management: проведение воркшопов, сбор обратной связи, мониторинг уровня адаптации. Мы не раз видели, как технически успешный проект проваливался именно на этом этапе, потому что в системе управления не было видимости этого блока работ.
Возвращаясь к примеру с логистическим проектом. После первоначальных неудач с готовым софтом мы пошли по пути использования платформы с низко кодовой настройкой. Это позволило бизнес-аналитикам из команды заказчика и консультантам из ООО Хэнань Цзюйхэ Текнолоджи самостоятельно настраивать некоторые рабочие процессы и формы отчётности, не ожидая развёртывания ресурсов от разработчиков.
Это сократило цикл обратной связи с недель до дней. Но и здесь появились подводные камни: чрезмерная кастомизация привела к тому, что логика процессов стала запутанной, а производительность системы на некоторых операциях упала. Пришлось вводить строгие правила и гайдлайны по тому, что можно настраивать самостоятельно, а что требует архитектурного ревью. Баланс между гибкостью и порядком — постоянная головная боль.
Ещё один важный аспект — отчётность. Стандартные отчёты о выполнении задач по спринтам или по этапам интересны команде разработки, но для спонсора проекта и стейкхолдеров нужна совершенно другая информация: ROI, прогресс в достижении бизнес-целей цифровой трансформации, снижение операционных рисков. Приходится настраивать отдельные дашборды, которые агрегируют данные из ИСУП, систем аналитики и финансовых систем. Это сложно и требует постоянного поддержания актуальности.
Вот здесь как раз видна реальная ценность партнёра, такого как ООО Хэнань Цзюйхэ Текнолоджи. Хороший поставщик услуг цифровой трансформации понимает, что его роль — не просто поставить технологию. Он должен помочь клиенту выстроить и адаптировать под эту технологию процессы управления, в том числе выбрать и настроить ту самую информационную систему управления проектами.
На их сайте https://www.hnjhkjjt.ru заявлен комплексный подход, и в идеале это должно включать в себя консалтинг по выбору и внедрению ИСУП. На практике же, к сожалению, этот вопрос часто отодвигается на второй план, и команды начинают работать в разрозненных инструментах: где-то Trello, где-то Excel, где-то почта. А потом наступает момент, когда нужно предоставить сводный отчёт, и начинается ад.
Исходя из нашего опыта сотрудничества, эффективнее всего, когда консультанты по трансформации с самого начала проекта настаивают на определении и согласовании инструментов управления. И даже более того — предлагают готовые, опробованные на других проектах конфигурации систем, адаптированные под типовые сценарии цифровых проектов. Это экономит колоссальное количество времени и нервов.
Так к чему же мы пришли? Информационная система управления для цифрового проекта — это не продукт, а процесс. Её нельзя просто ?включить?. Её нужно выращивать и адаптировать по ходу дела. Идеальной системы не существует, есть более или менее подходящая платформа, которую нужно доводить до ума силами как технологов, так и бизнес-пользователей.
Критически важным становится выбор партнёра, который понимает эту двойственную природу управления цифровыми проектами. Поставщик, который фокусируется только на технологическом стеке, упустит из виду процессы. Тот, кто говорит только о процессах, может не учесть технические ограничения. Нужен баланс.
И последнее. Самая большая ошибка — пытаться автоматизировать хаос. Если в компании нет базовой культуры проектного управления, никакая, даже самая дорогая ИСУП, не поможет. Сначала нужно навести минимальный порядок в процессах, а уже потом искать цифрового помощника для их поддержки и масштабирования. Это та истина, которую понимаешь только набив шишки на нескольких сложных проектах, где цифровая трансформация — это не лозунг, а ежедневная работа с тысячами деталей.