Производственная компания тратит восемь месяцев и несколько миллионов рублей на внедрение корпоративной СУП — и возвращается к Excel и мессенджерам. Система была рабочей. Провалилось внедрение: никто не разобрался с процессами и ролями до того, как открыл первый экран новой системы. Этот сценарий консультанты по проектному управлению описывают настолько часто, что он уже стал типовым.
По данным обзора развития проектного управления в России, в отечественной практике сложился гибридный подход — классический контроль портфеля на уровне руководства плюс Agile или Kanban на уровне команд. Внедрение СУП в таких условиях означает перестройку рабочих привычек, иногда у нескольких десятков людей одновременно. С 2022 года задача миграции с зарубежных систем стала острой для сотен компаний, давление на скорость внедрения резко выросло — а вместе с ним и риск ошибок. По оценкам Standish Group, около 70% организационных изменений в IT-проектах не достигают заявленных целей — и внедрение СУП здесь не исключение.
В этой статье — семь этапов внедрения, которые работают именно потому, что главный объект управления в них не софт, а люди и процессы. Плюс конкретные роли, разбор типов сопротивления, реальный кейс, чек-лист из 12 пунктов и метрики, которые можно замерить уже через 30 дней после старта.
Почему большинство внедрений СУП буксуют ещё до запуска — и при чём тут не софт
Когда внедрение системы управления проектами заходит в тупик, за этим стоят несколько устойчивых сценариев. Все они хорошо известны практикам, но раз за разом повторяются в новых компаниях.
Первый — автоматизация хаоса. Компания покупает систему, не разобравшись с тем, как задачи реально движутся внутри. Кто за что отвечает — непонятно. Где фиксируются договорённости — в чатах, почте и головах руководителей. Какие статусы у задач — каждый придумывает сам. В такую среду выгружают новый инструмент и ждут, что он наведёт порядок. Он не наводит. СУП умеет структурировать процессы, но не умеет их придумывать за вас.
Второй — «big bang». Руководство решает перевести всю компанию на новую систему одновременно: в понедельник работаем в старых инструментах, во вторник — только в новых. Обучение занимает два часа. Регламент — три страницы. Через три недели половина команды вернулась в мессенджеры, потому что там быстрее.
Третий — внедрение «сверху» без вовлечения команды. Система выбрана, настроена, запущена. Команда узнаёт об этом на общем собрании. Никто не объяснил, зачем это нужно лично каждому сотруднику. Никто не спросил, как люди работают сейчас. Результат предсказуем: система живёт в отчётах руководства, а реальная работа продолжается там, где она была.
Четвёртый — неправильный выбор вендора под специфику. Компания выбирает систему по функциональному списку или по рекомендации коллег из другой отрасли. В итоге инструмент не поддерживает нужные методологии, не интегрируется с существующими системами или требует такой глубокой кастомизации, что внедрение растягивается на год.
СУП как класс решений объединяет планирование, ресурсы, бюджет, документы и аналитику в одном месте. Внедрять нужно не «ещё одну программу», а новый способ работы. А значит, нужен не план внедрения софта, а план организационных изменений.
Вот его семь этапов.
Этап 0. Аудит: что происходит с задачами до внедрения
Прежде чем выбирать систему, нужно понять, что именно вы собираетесь в неё переносить. Megaplan называет это «нулевым шагом» — и это точное определение, потому что без него все последующие этапы строятся на предположениях, а не на фактах.
Аудит — это не документ на 50 страниц. Это карта «как есть» на одном листе: каналы, в которых сейчас живут задачи, ответственные за каждый тип работ и точки, где информация теряется.
Конкретные вопросы, на которые нужно ответить до начала внедрения:
- Где сейчас фиксируются задачи — в почте, мессенджерах, таблицах или нигде?
- Кто ставит задачи, и как исполнитель понимает, что именно от него ожидается?
- Где теряются договорённости — на совещаниях, в переписке, при передаче между отделами?
- Какие отчёты делаются вручную и сколько времени на это уходит?
- Есть ли задачи, которые «висят» неделями без движения, и почему?
- Какие решения принимаются вне формальных процессов — и почему люди обходят установленный порядок?
Вот что обычно обнаруживается. В одной из компаний, описанных в кейсе PMLogix, аудит показал: формальный процесс согласования существовал, но фактически решения принимались в личных переписках между руководителями. Автоматизировать формальный процесс было бессмысленно — сначала нужно было разобраться, почему люди его обходят, и перестроить маршрут согласования так, чтобы он не создавал лишних шагов.
Результат аудита — список точек потерь и конкретные процессы, которые нужно перестроить до или параллельно с внедрением системы. Если компания работает в условиях высокой неопределённости — например, при параллельной миграции с зарубежного ПО — стоит заранее проработать несколько сценариев. Допустим, ключевой интегратор не укладывается в сроки: кто берёт на себя настройку, какие этапы можно запустить без него? Часть команды не принимает новую систему в первые две недели: переключаетесь на индивидуальную работу с сопротивлением или сдвигаете дату отключения старого инструмента? Бюджет на внедрение урезают на 30%: какие этапы сокращаете, а какие нельзя трогать? Проработка таких сценариев до старта занимает пару часов, но экономит недели в момент, когда что-то идёт не по плану.
Этап 1. Определите роли: кто «владелец» внедрения
Внедрение СУП — это проект. Как у любого проекта, у него должен быть чёткий состав участников с понятными ролями. Без этого пошаговый план превращается просто в документ.
Спонсор — это топ-менеджер, который «прикрывает» проект: выделяет ресурсы, принимает решения при конфликтах приоритетов и публично демонстрирует, что система — всерьёз и надолго. Если спонсора нет или он назначен формально, команда быстро считывает сигнал: «это временно, можно не стараться».
Владелец внедрения — человек, который ведёт rollout как отдельный проект: составляет таймлайн, контролирует этапы, собирает обратную связь, эскалирует проблемы спонсору. Часто эту роль отдают IT-директору или операционному менеджеру. Ошибка — отдать её тому, у кого нет полномочий влиять на работу других команд.
Амбассадоры — по одному в каждой команде, которая переходит на новую систему. Амбассадор — не технический суперпользователь, а человек с авторитетом внутри команды, который искренне верит в изменения. Его задача — отвечать на вопросы коллег, собирать обратную связь и быть первым, кто начинает работать в системе правильно.
Кейс PMLogix подтверждает: закрепление ответственности за конкретными исполнителями и эскалация проблем к руководителю проекта — то, что отличает работающее внедрение от формального. Без чётко назначенных ролей ответственность размывается, и система остаётся ничьей.
Этап 2. Сформулируйте «зачем» на языке команды, а не руководства
У руководителя и у исполнителя разные причины хотеть (или не хотеть) новую систему. Руководитель хочет прозрачности, контроля, соблюдения сроков. Исполнитель хочет понятных приоритетов, меньше рутины и отсутствия вопроса «а почему ты не сделал?» по задачам, которые ему никто не ставил.
Когда внедрение объясняется языком руководства, команда слышит: «теперь за нами будут следить». Это запускает защитную реакцию. Практика управления изменениями показывает: когда сотрудники понимают личную выгоду от нового инструмента, скорость принятия растёт, а количество обходных практик снижается.
Два примера переформулировки, которые работают лучше всего.
«Контроль исполнения» → «Если задача поставлена в пятницу с дедлайном в понедельник, система это зафиксирует. Вас не обвинят в том, что вы не успели, если срок изначально был нереальным». Пример работает, потому что снимает страх: система фиксирует факты в обе стороны, а не только против исполнителя.
«Сокращение времени на отчётность» → «Отчёт в пятницу вечером больше не нужен — руководитель видит статус напрямую в системе». Это болезненная точка во многих командах, и её устранение — конкретная, ощутимая выгода с первой недели.
Если в компании уже внедрены OKR, переход на СУП — хороший момент наконец связать стратегические цели с ежедневными задачами. Подробнее о том, как это работает в командах вне IT, — в материале об OKR для non-IT.
Этап 3. Почему big bang убивает adoption раньше, чем система успевает заработать
Поэтапный rollout с пилотом на одной команде — это прагматика, а не осторожность. Пилот даёт то, что невозможно получить иначе: обкатанный процесс, реальную обратную связь и внутренний кейс успеха, на который можно ссылаться при масштабировании.
При выборе пилотной команды есть один критерий, который важнее остальных: мотивированный руководитель, который сам хочет изменений. Если выбирать только по одному параметру — это он. Отсутствие мотивированного лидера нельзя компенсировать ни размером команды, ни простотой процессов, ни наличием амбассадора. Остальные критерии — типичные процессы (а не уникальные), размер 5–15 человек, наличие потенциального амбассадора — важны, но поддаются коррекции. Демотивированный руководитель пилотной команды не поддаётся.
На пилоте тестируют не функциональность системы, а рабочие привычки. Конкретная программа (сроки ориентировочные — для команды из 5–15 человек; при большем составе каждый этап может потребовать дополнительную неделю): первая неделя — создание рабочего пространства и перенос активных задач из текущих инструментов; вторая и третья недели — ежедневная работа в системе с параллельным использованием старых каналов; четвёртая неделя — полный переход, отключение дублирования. В кейсе PMLogix внедрение на пилотной команде заняло сопоставимый срок: регулярные планёрки с использованием ИТ-системы запустили с первой недели, а полноценная работа по доске проекта стабилизировалась к концу первого месяца.
Отдельно про обучение: «прочитайте инструкцию» не работает. На пилоте стоит провести живую сессию на 60–90 минут, где амбассадор или владелец внедрения разбирает реальные задачи команды прямо в системе — создаёт задачу, назначает ответственного, двигает по статусам, показывает, как выглядит дашборд руководителя. Люди запоминают то, что видели на своих задачах, а не на демо-данных.
В Shtab для этого можно создать отдельное рабочее пространство для пилотной команды, настроить роли с разным уровнем доступа и запустить работу по готовым шаблонам проектов — команда не начинает с пустого экрана, что снижает порог входа и ускоряет адаптацию.
Результат пилота — не «всем понравилось». Это конкретные данные: сколько задач перенесли, сколько времени ушло на адаптацию, какие процессы не легли в систему и почему. Именно эти данные определяют, что нужно изменить перед масштабированием. При переносе задач полезно сразу декомпозировать крупные задачи на управляемые части — иначе в системе появляются задачи-монстры без чёткого исполнителя и срока.
Этап 4. Миграция: что переносить, а что оставить в прошлом
Три категории задач при миграции
Типичная ошибка — тащить в новую систему весь «хвост» из старых инструментов. Команда открывает импорт, видит 800 задач, половина из которых не двигалась полгода, и теряет ориентацию.
Перед миграцией нужно разделить задачи на три категории. Активные задачи — те, по которым есть движение прямо сейчас, — переносятся в новую систему с полным контекстом: описание, файлы, связи, ответственный. Завершённые задачи архивируются: они не попадают в рабочее пространство, но остаются доступными для поиска. «Зомби-задачи» — то, что висит без движения больше месяца и не имеет понятного следующего шага, — закрываются навсегда. Это неудобно, но необходимо: зомби-задачи создают информационный шум и снижают доверие к системе.
При переносе активных задач важно перенести не только название, но и контекст: что уже сделано, какие есть зависимости, почему задача стоит именно сейчас.
Параллельный период: сколько он должен длиться
Длительность параллельного периода, когда команда работает и в старой, и в новой системе одновременно, зависит от размера команды: для группы до 15 человек достаточно 5–7 рабочих дней, для отдела от 50 человек — до двух недель. Затягивать дольше не стоит ни в том, ни в другом случае.
Затягивание создаёт ситуацию «двух стульев»: люди не чувствуют необходимости перестраиваться, потому что старая система под рукой. В результате новая система накапливает задачи, но не становится тем местом, где команда реально работает.
Конкретный таймлайн: первая неделя — перенос активных задач и создание структуры в новой системе; вторая неделя — параллельная работа, все новые задачи создаются только в новой системе; начало третьей недели — отключение старой системы для постановки задач. Жёсткая дата отключения — наиболее надёжный способ завершить переход: без неё команда не чувствует необходимости перестраиваться.
Этап 5. Работа с сопротивлением: четыре типа «саботажа» и что с каждым делать
«Мы уже пробовали Trello, Asana и ещё три системы. Ни одна не прижилась. Почему эта будет другой?» — примерно так звучит первая реакция в команде, которая пережила несколько неудачных внедрений. За этим вопросом стоит не лень и не вредность, а накопленный опыт разочарований.
Руководители часто работают с сопротивлением одним инструментом — давлением. Это даёт краткосрочный эффект, но не формирует привычку.
Первый тип — «мне и так нормально». Опытные сотрудники, у которых за годы сложились рабочие привычки. Человек ведёт проект в голове и в блокноте семь лет — для него система не помощь, а сигнал недоверия. Работать с этим типом через давление бессмысленно: они формально выполнят требования, но система останется для них дополнительной нагрузкой.
Здесь помогает нестандартный ход: назначить такого человека амбассадором. Когда скептик начинает объяснять систему другим, он сам начинает в неё верить — это хорошо известный эффект из практики change management. Один из PM-практиков в профессиональном сообществе описывал это так: «Я взял самого громкого критика, дал ему роль "эксперта по переходу" — и через три недели он защищал систему на планёрках активнее меня».
Второй тип — «это слежка». Страх контроля особенно распространён в командах с высокой автономией. Здесь важно объяснить принципиальную разницу: система фиксирует не скорость работы сотрудника, а факт постановки задачи. Если задача поставлена в пятницу с дедлайном в понедельник, система это видит — и это защищает исполнителя, а не обвиняет его. Прозрачность работает в обе стороны. Этот аргумент стоит проговорить публично, на общей встрече — иначе слух «нас будут контролировать» распространяется быстрее официальной позиции.
Третий тип — усталость от изменений. «Ещё одна система» — это не возражение, а диагноз: команда пережила несколько волн внедрений, ни одна не закрепилась. Лечится только одним: публичным commitment руководства, конкретным таймлайном без размытых формулировок и железным правилом — не менять правила игры на ходу в течение первых трёх месяцев.
Именно непоследовательность руководства, а не сложность системы, убивает adoption в большинстве случаев.
Четвёртый тип — «тихие саботажники». Опытные сотрудники, которые не выступают против системы открыто, но продолжают работать по-старому, создавая параллельную реальность. Их можно выявить ещё на этапе аудита: это люди, которые описывают свои процессы как уникальные и не поддающиеся стандартизации. Работать с ними нужно индивидуально — через личную выгоду и вовлечение в настройку системы под их задачи. Если «тихий саботажник» увидит, что система учитывает специфику его работы, а не навязывает чужой шаблон, сопротивление ослабевает.
Кейс: как компания перешла с гибридного хаоса на единую систему за 8 недель
Кейс, опубликованный на PMLogix и PMJournal, описывает внедрение гибридного управления проектами с применением ИТ-платформы в компании с несколькими параллельными проектами. Это один из немногих открытых российских кейсов, где подробно описан процесс, а не только результат. Сразу оговорюсь: кейс качественный, не количественный — авторы раскрывают шаги и эффекты, но не публикуют метрики ROI.
Что было. Запрос на повышение управляемости: нет связки между уровнем руководства и командой, непрозрачность по задачам, срокам и рискам. Договорённости теряются, проблемы всплывают поздно, когда исправить уже сложно. Команды работали в разрозненных инструментах, общей картины по статусам проектов не существовало.
Что сделали. Внедрение шло поэтапно: сначала закрепили ответственность за конкретными исполнителями — не «отдел», а конкретный человек с именем. Запустили регулярные планёрки с обязательным использованием ИТ-системы: статусы обсуждались не по памяти, а по данным в системе. Ввели управление проблемами через систему флагов — открытые вопросы фиксировались и не терялись в переписке. Настроили ежедневное обновление прогноза по срокам и управление по отклонениям вех: руководство видело не «всё идёт по плану», а реальные отклонения от согласованного графика. Косвенный эффект, который отмечают авторы: планёрки сократились по времени, потому что обсуждение перешло от «кто что помнит» к «что показывает доска».
Что получили. Авторы описывают результат как объединение двух уровней: высокий контроль сроков и рисков на уровне руководства плюс вовлечённость и гибкость на уровне команды. Публичных цифр ROI нет — и это характерно для большинства российских кейсов внедрения СУП. Именно поэтому в следующем разделе — конкретные метрики, которые стоит замерять самостоятельно: они дадут собственные данные, не зависящие от чужих кейсов.
Этап 6. 30 дней прошло — как понять, что внедрение не провалилось
Эффект от внедрения СУП можно измерить через 30 дней, а не через полгода. По данным обзора развития проектного управления в России, расширенная аналитика наиболее востребована для управления рисками (60% респондентов) и планирования и контроля (49%). Но прежде чем строить аналитику, нужно замерить базовые показатели — до внедрения. Иначе «стало лучше» останется субъективным ощущением.
Пять метрик, которые работают с первого месяца:
Adoption rate — доля команды, которая ежедневно работает в системе. Цель через 30 дней: больше 80%. Если показатель ниже — система не стала основным рабочим инструментом, люди работают где-то ещё.
Задачи без ответственного — сколько задач создаётся без назначенного исполнителя. Цель: меньше 5%. Задача без ответственного — это не задача, а намерение.
Среднее время реакции — от постановки задачи до первого действия исполнителя. Для замера baseline до внедрения возьмите выборку из 20 задач в текущем рабочем мессенджере: зафиксируйте время между постановкой и первым ответом исполнителя. Это занимает около 30 минут и даёт реальную точку отсчёта. Снижение этого показателя после внедрения — прямое свидетельство того, что задачи стали видимее.
Доля задач, созданных вне системы — показывает, насколько система стала тем местом, где живёт реальная работа. Задачи, которые обсуждались в чатах или на совещаниях, но не попали в систему, — это утечка. Цель: стремится к нулю. Замеряется просто: на еженедельной планёрке владелец внедрения сверяет повестку совещаний с содержимым системы — 15–20 минут в неделю.
Время на статус-отчёт — сколько минут руководитель тратит на понимание текущего состояния проекта. До внедрения это обычно 30–60 минут в день (звонки, переписка, «как дела с задачей?»). После — должно сократиться до 5–10 минут просмотра дашборда.
Все пять метрик нужно зафиксировать до старта пилота. Без baseline любой прогресс — ощущение, а не факт. Подробнее о том, как строить план управления проектом с измеримыми критериями успеха, — в материале о плане управления проектом.
Когда базовые метрики выстроены и adoption растёт, следующий уровень зрелости — автоматизация контроля. О том, какие типы AI-ассистентов берут на себя рутинный мониторинг задач и когда они реально нужны, — в материале о трёх типах AI-ассистентов в управлении проектами.
Почему функциональность системы — не главный критерий выбора
Руководители часто выбирают систему «на вырост»: берут максимально функциональное решение, потому что «потом не придётся менять». Логика понятна, но на практике она работает против adoption.
Команда, которая видит 40 пунктов меню, 15 типов задач и 8 уровней приоритетов, делает одно из двух: либо использует 10% функциональности, либо не использует систему вообще. Порог входа оказывается выше, чем ценность, которую человек получает в первые дни.
Этот эффект подтверждается не только здравым смыслом. В профессиональных PM-сообществах одна из самых устойчивых рекомендаций звучит так: «нужны простые правила и единый регламент, а не комбайн». Гибридные подходы к управлению проектами, которые сложились в российской практике, появились именно потому, что полная одномоментная замена процессов не работает — команды отторгают радикальные изменения. Тот же принцип действует при выборе инструмента: сложность нужно наращивать постепенно, после того как базовые привычки сформированы.
Это принцип «минимально жизнеспособного процесса», аналог MVP в продуктовой разработке. На старте команде нужны четыре вещи: задача, ответственный, срок, статус. Диаграмма Ганта, автоматизации, зависимости между задачами, аналитика по загрузке — это не то, с чего начинают. Это то, к чему приходят, когда люди уже работают в системе каждый день и начинают сами просить больше возможностей.
В Shtab, например, можно начать с простого канбана в рабочем пространстве, а затем по мере роста зрелости команды подключить диаграмму Ганта с автопланированием и критическим путём, добавить цели компании для связки стратегии с ежедневными задачами. Команды, которые начинают с канбана и переходят к Ганту, обычно делают это после первых двух-трёх ретроспектив — когда базовые привычки уже сформированы и люди сами начинают спрашивать про зависимости между задачами. Каждый следующий слой добавляется тогда, когда предыдущий уже стал привычкой, а не нагрузкой.
Прежде чем усложнять систему, убедитесь, что базовые принципы работают — об этом подробнее в материале о 8 принципах управления проектами.
Этап 7. Масштабирование: от одной команды ко всей компании
После успешного пилота масштабирование идёт волнами. Попытка перейти сразу от пилота к «всей компании» — это тот же big bang, только с отложенным стартом.
Первая волна — две-три команды, смежные с пилотной. Главный риск здесь: «у нас другие процессы, нам это не подходит». Это звучит как техническое возражение, но за ним стоит сопротивление изменениям. На практике помогает адаптация шаблонов под специфику каждой команды вместо навязывания единого формата. Базовая структура (задача, ответственный, срок, статус) остаётся общей; детали настраиваются под команду. В кейсе PMLogix именно так и поступили: общие принципы управления были едиными, а инструменты визуализации и частота планёрок различались между командами.
Вторая волна — отдел или целое направление. Здесь появляется новый риск: конфликт номенклатур. Разные команды называют одинаковые статусы по-разному. «В работе» у одних — это то же самое, что «на согласовании» у других. Без унификации базовых статусов руководитель не может читать общую картину. Минимальный набор общих статусов нужно зафиксировать до начала второй волны, оставив командам свободу в деталях внутри этих статусов.
Третья волна — вся компания. Самый неочевидный риск на этом этапе — потеря внимания руководства. Когда система «запущена», спонсор переключается на другие задачи. Команды считывают это как сигнал, что проект закрыт. Adoption начинает падать. Что удерживает инерцию: регулярные ревью метрик adoption (раз в месяц), публичное признание команд-лидеров и конкретный план развития системы на следующий квартал — какие новые возможности будут подключены, какие процессы автоматизированы, какие интеграции настроены. Без этого плана масштабирование затухает.
Количество волн определяется не размером компании, а числом автономных команд с разными процессами. Три волны закрывают большинство случаев; если команды работают по принципиально разным методологиям или в разных юрисдикциях — волн будет больше, и это нормально.
Чек-лист: 12 пунктов готовности к внедрению СУП
До пилота
- Аудит текущих процессов проведён, карта «как есть» зафиксирована на одном листе.
- Роли назначены: спонсор, владелец внедрения, амбассадоры в каждой команде.
- «Зачем» сформулировано на языке команды, а не только на языке руководства.
- Пилотная команда выбрана по критериям: мотивированный руководитель, типичные процессы, 5–15 человек, есть потенциальный амбассадор.
- Baseline-метрики замерены до старта: adoption, задачи без ответственного, время на статус-отчёт.
- Шаблоны проектов и базовые статусы подготовлены до того, как команда открыла систему первый раз.
Во время rollout
- Критерии разделения задач на «активные / архивные / зомби» определены до начала миграции.
- Параллельный период ограничен: до 7 дней для команды до 15 человек, до двух недель для отдела 50+; дата отключения старой системы зафиксирована.
- План работы с сопротивлением есть: для каждого из четырёх типов — конкретный подход, а не общие слова.
- Таймлайн rollout утверждён спонсором и доведён до команды с конкретными датами.
- Обучение запланировано: живая сессия 60–90 минут с разбором реальных задач команды в системе (не «прочитайте инструкцию»).
После запуска
- Первый ревью метрик через 30 дней стоит в календаре у спонсора и владельца внедрения; если adoption rate ниже 60% — это стоп-сигнал для разбора причин.
FAQ — частые вопросы о внедрении системы управления проектами
Каковы этапы внедрения системы управления проектами?
В этой статье описан семиэтапный план: аудит текущих процессов (этап 0), определение ролей, формулировка «зачем» на языке команды, пилот на одной команде, миграция задач, работа с сопротивлением и масштабирование. Каждый этап подробно разобран выше. Работа с сопротивлением идёт параллельно со всеми остальными этапами, а не после миграции.
Каковы 5 этапов управления проектом?
Классический жизненный цикл проекта включает пять фаз: инициация, планирование, исполнение, мониторинг и контроль, завершение. Не стоит путать эти фазы с этапами внедрения СУП — это разные вещи. Пять фаз описывают, как управлять любым проектом. Семь этапов из этой статьи описывают, как провести конкретный проект внедрения системы.
Что делать, если спонсор теряет интерес через месяц после запуска?
Это один из самых частых рисков на этапе масштабирования. Встройте ревью метрик adoption в регулярный управленческий цикл спонсора: не отдельное совещание «про систему», а пункт повестки на существующей планёрке. Если спонсор видит цифры adoption и время на статус-отчёт раз в месяц, он остаётся вовлечённым без дополнительных усилий. Если adoption падает ниже 60% — это повод для разговора не о системе, а о том, почему команда не видит в ней ценности.
Что такое план управления внедрением?
Это документ, который фиксирует цели внедрения, роли и ответственных, таймлайн rollout, критерии успеха и план работы с рисками. По сути — проект внедрения СУП, управляемый по тем же принципам, что и любой другой проект: с ответственным, сроками, метриками и регулярными ревью. Компании, которые пренебрегают этим документом, чаще всего именно его отсутствие и называют причиной провала.
Большинство компаний застревают не на техническом внедрении — с этим справляется вендор. Застревают на этапе 2: когда нужно объяснить команде личную выгоду от изменений. Это единственное, что нельзя делегировать.
Начните с аудита — этапа 0 из этой статьи. Возьмите шесть вопросов из раздела про аудит, соберите ответы от руководителей трёх-четырёх ключевых команд и нанесите результат на один лист: каналы, ответственные, точки потерь. Это занимает 2–3 часа и не требует никакого софта. А каждая неделя без этого аудита — это ещё одна неделя, когда задачи теряются в чатах, сроки срываются без видимой причины, а руководитель тратит час в день на выяснение статусов вместо того, чтобы принимать решения.