внедрение корпоративной системы управления проектами

Когда слышишь ?внедрение корпоративной системы управления проектами?, первая мысль — выбрать Jira, Asana или что-то отечественное. Но это, пожалуй, самый распространённый и опасный миф. На деле, сам софт — это процентов 20 успеха, если не меньше. Основная битва разворачивается вокруг процессов, людей и, что часто упускают, вокруг простого вопроса: ?А зачем нам это вообще нужно??. Многие компании, особенно те, что растут быстро, как ООО Хэнань Цзюйхэ Текнолоджи, сталкиваются с тем, что Excel и чаты уже не справляются, но переход на новую систему оборачивается хаосом. И я говорю не о технических сбоях, а о сопротивлении, которое никто не просчитал.

От идеи до боли: почему начинается внедрение

Обычно всё стартует с благой цели: навести порядок, повысить прозрачность, ускорить процессы. Руководство видит, что проекты срываются, ресурсы учитываются плохо, а ответственность размыта. В случае с ООО Хэнань Цзюйхэ Текнолоджи, как с поставщиком услуг цифровой трансформации, это особенно критично — собственные процессы должны быть безупречным образцом для клиентов. Но здесь и кроется первый подводный камень. Часто решение о выборе системы принимается IT-отделом или топ-менеджментом в отрыве от тех, кто будет этой системой пользоваться ежедневно — менеджеров проектов, разработчиков, аналитиков.

Я вспоминаю один из ранних проектов внедрения, не в этой компании, но в похожей по духу. Был выбран мощный инструмент, куплены лицензии, проведено обучение. А через месяц активность упала почти до нуля. Оказалось, что для отчёта о простой задаче нужно было заполнить 15 полей, половина из которых была не нужна конкретному исполнителю. Люди просто стали дублировать работу в старом добром Telegram, а в систему заходили раз в неделю, чтобы ?отметиться?. Это классическая ошибка: попытка автоматизировать хаос приводит только к более структурированному хаосу.

Поэтому сейчас, подходя к вопросу, мы в первую очередь задаёмся не ?какую систему купить??, а ?какие процессы мы хотим зафиксировать и улучшить??. Иногда после такого анализа выясняется, что для начала достаточно прописать регламенты в Confluence и использовать простые канбан-доски. Но если речь идёт о масштабах и разнообразии проектов, как у ООО Хэнань Цзюйхэ Текнолоджи, где могут параллельно идти и разработка ПО, и внедрение ERP, и ИТ-консалтинг, то без единой корпоративной системы управления проектами не обойтись. Ключ — в её адаптивности.

Выбор неочевидного: критерии, о которых не пишут в блогах

В статьях обычно советуют смотреть на функционал, интеграции, стоимость. Это важно. Но есть нюансы, которые становятся ясны только на практике. Например, скорость отклика интерфейса. Если система ?подвисает? при загрузке страницы с десятком задач, её будут ненавидеть. Или возможность кастомизации workflows. Жёсткие, негибкие процессы оттолкнут команды, которые работают по Scrum, Kanban и водопадным моделям одновременно.

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

Ещё один критичный пункт — поддержка и сообщество. Когда что-то ломается в пятницу вечером, а проект ?горит?, важно иметь возможность быстро найти решение. Официальная поддержка крупных вендоров иногда бывает медленной, поэтому наличие активного сообщества разработчиков и администраторов на Stack Overflow или в Telegram-чатах часто перевешивает пару ?крутых? фич в дорогом продукте. Мы рассматривали и российские аналоги, но в итоге остановились на гибридном подходе, о котором — дальше.

Пилот как лакмусовая бумажка: первый блин и комом, и полезен

Никогда не стоит внедрять систему сразу на всю компанию. Мы выбрали для пилота один отдел — отдел разработки внутренних инструментов. Команда относительно небольшая, процессы более-менее отлажены, и люди технически подкованы. Казалось бы, идеальные первые пользователи. Но именно здесь мы наступили на грабли, которые потом сэкономили нам кучу нервов в масштабном rollout.

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

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

Что не сработало в пилоте

Попытка перенести все исторические данные из старых инструментов. Потратили уйму времени на миграцию тысяч устаревших и закрытых задач. В живой работе оказалось, что никто на них не смотрит. Нужно было переносить только активные проекты и, может быть, несколько ключевых завершённых для истории. Ещё провалом было стандартное обучение ?от возможностей системы?. Люди зевали. Гораздо лучше сработали короткие сессии ?как решить вашу конкретную проблему с помощью новой системы?: ?как запланировать спринт?, ?как отчитаться о задержке?.

Масштабирование: когда процессы начинают жить своей жизнью

После успешного (условно) пилота началось rollout на другие департаменты. И вот тут стало ясно, что универсального рецепта нет. То, что работало для разработки, категорически не подошло отделу внедрения и сопровождения. Их проекты более клиентоориентированы, с жёсткими сроками и массой внешних коммуникаций. Им нужен был не столько скрам-борд, сколько календарное планирование с привязкой к ресурсам и удобный инструмент для ведения документации по проекту.

Пришлось идти на компромиссы. Мы создали несколько типов проектов в системе с разными workflows, наборами полей и шаблонами отчётов. Это усложнило администрирование, но дало командам необходимое чувство ?это сделано для нас?. Важно было не переборщить, чтобы не получить десятки абсолютно разных конфигураций, которые потом невозможно сводить в общую отчётность для руководства. Баланс между гибкостью и стандартизацией — это постоянный процесс настройки.

Особый вызов — интеграция с другими системами. ООО Хэнань Цзюйхэ Текнолоджи использует CRM, бухгалтерские программы, системы документооборота. Автоматический перенос данных, например, о закрытой коммерческой сделке из CRM в проект в Jira как задачу на запуск — это огромная экономия времени и исключение человеческой ошибки. Но настройка таких интеграций часто упирается в технические ограничения API и вопросы безопасности данных. Иногда проще и надёжнее оставить точечный ручной ввод, чем строить хрупкую автоматизацию, которая будет падать раз в неделю.

Культура, а не инструмент: самый трудный этап

Спустя полгода после основного внедрения система работала, данные вносились, отчёты строились. Но стало ли управление проектами лучше? Не всегда. Оказалось, что некоторые руководители используют систему просто как инструмент тотального контроля, отслеживая каждое движение сотрудника, вместо того чтобы видеть общую картину и риски по проекту. Это вызывало отторжение и формальный подход к заполнению.

Пришлось проводить отдельные встречи не о функционале, а о философии управления. Объяснять, что система — это не ?большой брат?, а общая память проекта, инструмент для прозрачности и помощи. Что её цель — не наказать за срыв сроков, а заранее увидеть, что сроки могут сорваться, и успеть среагировать. Это сдвиг в корпоративной культуре, и он происходит медленнее, чем установка софта.

Ещё один интересный феномен — возникновение ?теневых? процессов. Даже в работающей системе люди создают для удобства дополнительные чаты, Google-таблицы для каких-то конкретных нужд. Раньше мы с этим боролись, теперь — анализируем. Если такая ?теневая? практика возникает массово, возможно, это сигнал о пробеле в функционале основной системы. Однажды так мы добавили удобный виджет для быстрого совместного комментирования макетов, что сократило использование сторонних сервисов на 80%.

Итоги и постоянная эволюция

Можно ли назвать внедрение корпоративной системы управления проектами в ООО Хэнань Цзюйхэ Текнолоджи завершённым? Нет, и оно вряд ли когда-то будет завершено полностью. Это живой организм. Появляются новые типы проектов, меняются команды, обновляется сам софт. Главный итог — это не факт наличия системы, а то, что данные о проектах стали централизованными, принятие решений — более обоснованным, а обсуждения — более предметными.

Были ли ошибки? Множество. Переоценка готовности людей к изменениям, недооценка времени на кастомизацию, попытки автоматизировать всё подряд. Но каждая ошибка — это теперь часть нашего внутреннего knowledge base, кейс, который мы, как компания, оказывающая услуги трансформации, можем осмыслить и использовать в работе с клиентами. И это, пожалуй, самая ценная часть опыта.

Что бы я сделал иначе сегодня? Больше ресурсов вложил бы не в начальное обучение, а в постоянную поддержку и развитие практик использования. Запустил бы внутреннюю гильдию менеджеров проектов для обмена опытом раньше. И с самого начала связал бы KPI руководителей проектов не с фактом использования системы, а с качеством данных в ней и итоговыми метриками успешности проектов. Ведь система — всего лишь инструмент. Цель — успешная реализация проектов, и именно на это должно работать любое внедрение.