Пилот стартовал с 120 пользователей и 10 приоритетных проектов. Через 4 месяца в системе шло около 50 активных проектов, а через год вся проектная деятельность компании с численностью больше 1000 сотрудников велась в одной среде, без параллельных таблиц и чатов для статусов. Это кейс миграции с Jira на российскую PM-систему, и он показывает, что внедрение почти никогда не случается одномоментно.
Но куда чаще встречается противоположный сценарий. В системе работают три человека из отдела разработки, остальные по-прежнему живут в мессенджерах и экселе. Пилот прошёл, отчёт написан, а дальше тишина. Проблема почти никогда не в самом инструменте.
Дальше разберём маршрут из трёх шагов: пилот, расширение, стандарт. Поговорим о плане задач на восемь недель, роли внутреннего адвоката изменений, триггерах, по которым понятно, что пора подключать следующий отдел, и о семи причинах, по которым пилоты умирают, так и не дожив до масштабирования.
Почему внедрение таск-трекера выгоднее вести как внутреннюю продажу, а не как ИТ-проект
В крупной компании у системы управления проектами нет заказчика на всю организацию. Есть десятки отделов со своими процессами, своими привычками и своим пониманием, что считать задачей. Директивный запуск «с понедельника все работаем в новой системе» обычно разбивается об это разнообразие в первую неделю.
Поэтому логика, которую в B2B-продажах называют «посадить и расширить» (land and expand), внутри компании работает лучше директивного запуска. Аналогия тут не буквальная: внутри организации нет контракта и нет конкурента, зато есть коллега, который может тихо продолжать вести задачи в Excel. Но механика совпадает: закрепиться в одной команде, доказать ценность на цифрах, которые видны руководству, и уже после этого расширяться на смежные подразделения.
В whitepaper Greylock про land and expand есть наблюдение, которое переносится на внутреннее внедрение почти без правок: исход определяет adoption and usage — то, использует ли команда систему на практике. Сам факт установки и запуска не решает ничего. Авторы рекомендуют заранее определить стейкхолдеров, связать продукт с конкретной выгодой для пользователя и управлять переходом как отдельным процессом.
Stratrix в материале The Anatomy of a Land and Expand Strategy называет порог: переход к статусу корпоративного стандарта обычно начинается после активного использования минимум в трёх подразделениях. Пока работает одна команда, это пилот. Когда активно работают три, это уже тенденция, с которой считаются остальные.
Та же схема описана и для крупных закупок 2026 года: enterprise-инструменты разворачивают фазами — сначала пилот, затем поэтапное подключение подразделений. Единовременный запуск на всю организацию там встречается редко.
Если ценность нужно доказывать, сначала надо решить, кому и чем её доказывать. А это зависит от того, какую команду взять первой.
Какую команду брать в пилот и почему это не должна быть самая лояльная
Первую команду выбирают по двум признакам: насколько её боль видна руководству и насколько её процесс можно повторить в соседнем отделе. Готовность сотрудников к экспериментам здесь вторична.
Боль должна быть измерима и уже обсуждаться на уровне директора: сорванные сроки согласований, невидимая загрузка людей, регулярные вопросы «а что там с проектом» в личных сообщениях. Если боль существует только в голове у инициатора внедрения, спонсор не выделит на неё время при расширении.
Процесс нужен типовой, такой, который можно превратить в шаблон для следующих команд. Это сразу экономит время при подключении второго и третьего отдела. Внутри решения «Запуск однотипных проектов по шаблону» описана именно эта логика: один раз настроить структуру проекта, а дальше копировать её под новые команды вместо настройки с нуля.
Размер команды — ориентир 10–25 человек. При меньшем составе эффект на стыках между отделами почти не виден, при большем пилот рискует утонуть в настройке и обучении до того, как покажет результат.
Нужен и отдельный руководитель с собственным интересом в прозрачности: человек, которому реально не хватает ответа на вопрос «когда будет готово». Формальный куратор, назначенный для галочки, эту роль не закроет.
Отдел ИТ-разработки часто оказывается худшим первым кандидатом, если он уже живёт в своём трекере. Для разработчиков внедрение новой системы выглядит как смена привычного инструмента, а не как решение реальной проблемы, и бизнес в итоге не видит выигрыша: разработка и так была прозрачна для себя самой.
Лучше брать команду на стыке бизнеса и ИТ: маркетинг с подрядчиками, внедрение продуктов у заказчика, проектный офис. В банковском кейсе единой системы задач эффект появился именно на границе с внешними подрядчиками: около 25% экономии времени на коммуникацию и ускорение поставки новой функциональности на 20%. Граница между отделами — почти всегда самое дорогое место для потерь времени.
Семь причин, по которым пилоты систем управления проектами умирают
Чаще всего пилот убивают организационные решения, принятые ещё до старта. Функциональные ограничения системы в этом списке почти не встречаются. Семь причин повторяются из внедрения в внедрение.
- Нет даты окончания и критериев успеха. Пилот без них превращается в вялое «мы пробуем» на полгода без финала. В гайдах по enterprise-внедрению метрики вроде видимости проектов, соблюдения сроков, утилизации ресурсов и управляемости фиксируют до старта, а не придумывают постфактум под нужный результат.
- Параллельная работа со старым инструментом. Команда ведёт задачи и в новой системе, и в прежнем чате, трудозатраты растут вдвое, и естественный вывод людей: «стало хуже, чем было».
- Нет адвоката изменений с выделенным рабочим временем. Иначе он тащит проект в свободные часы между основными обязанностями, и внедрение превращается в хобби одного человека, от которого первым отказываются в загруженную неделю.
- Избыточная кастомизация. Пилот топится в настройке полей и статусов под каждое исключение ещё до того, как в системе появились первые реальные задачи команды.
- Перенос всего архива сразу. Вместо 10 приоритетных проектов туда заливают пять лет истории, и первая неделя уходит на разбор накопленных файлов, а не на то, чтобы показать команде, как выглядит живая задача в работе.
- Неправильные метрики. Пилот оценивают по активности: считают «число созданных задач» вместо срока согласования документа или доли проектов со статусом «в срок». Цифра растёт, исходная проблема никуда не уходит, и через два месяца сложно объяснить спонсору, что изменилось.
- Нет спонсора. Любая реорганизация, смена приоритетов или просто загруженный квартал обнуляет инициативу без поддержки на уровне топ-менеджмента. Искать спонсора стоит по боли, а не по должности в структуре: подходит руководитель, который сегодня не может получить внятный ответ на вопрос «когда будет готово», и поэтому лично заинтересован, чтобы пилот не остановился на полпути.
Шесть из семи причин закрывает одна роль: человек, который отвечает за внедрение как за отдельный проект, а не как за факультативную нагрузку.
Внутренний адвокат изменений: кто это, что ему дать и чем его мерить
Внедрение расширяет сотрудник внутри компании — тот, у кого есть мандат, время и собственная выгода от того, что пилот перерастёт в стандарт. Вендор эту работу за него не сделает.
Подходящие кандидаты: руководитель проектного офиса, руководитель направления, аналитик процессов, иногда сильный тимлид с амбициями на рост. Не подходит ИТ-администратор без влияния на процессы соседних отделов. Не подходит и внешний консультант без прав внутри компании: он уедет вместе с проектом, а правила ведения задач останутся без хозяина.
Этому человеку нужно явно выдать четыре вещи: 4–8 часов в неделю рабочего времени именно на внедрение, права администратора в системе, прямой канал к спонсору без промежуточных звеньев и право утверждать правила ведения задач для команды.
На пилоте у адвоката по сути одна зона ответственности, разложенная на практические шаги: собрать базовую конфигурацию, обучить первую команду на живых задачах и еженедельно показывать спонсору одну метрику, по которой видно изменение. Не пять метрик, не отчёт на десять слайдов, а одну цифру, динамика которой понятна без пояснений.
Самого адвоката стоит оценивать по тому, насколько реально команда перешла в систему: по доле задач, которые ведутся в ней, а не в чате, по доле сотрудников с активностью за неделю и по изменению срока прохождения типового процесса до и после внедрения.
Отдельный момент: адвокат изменений не должен оставаться один. При расширении на второй и третий отдел нужна «вторая волна» — по одному адвокату изменений в каждом новом подразделении. Иначе весь поток вопросов идёт в одну точку и упирается в календарь одного перегруженного человека.
Из практики внедрений. Провальный мандат выглядит так: адвокату дают систему и говорят «разберись», без выделенного времени, без прав и без спонсора, готового хоть раз защитить его перед другими руководителями. Рабочий мандат начинается с одного вопроса спонсору: какое решение вы хотите принимать по данным из системы через два месяца. Если ответа нет, не с чем идти ни к команде, ни к совету директоров.
План задач пилота на 8 недель
План задач пилота на 8 недель
Пилот должен быть оформлен как проект с фиксированными неделями, ответственными и выходными критериями. Иначе его нечем закрыть, и он плавно перетекает в бессрочный режим «пробуем дальше».
Первые две недели пилот существует только на бумаге, если не закрыть базовую рамку: зафиксировать 2–3 метрики успеха и целевые значения, выбрать 5–10 приоритетных проектов (ориентир из практики — 10 проектов), определить спонсора и адвоката изменений письмом с мандатом и выделенными часами, описать на одну страницу правила: что считается задачей, какие статусы обязательны, кто ставит сроки. Без этой рамки всё остальное строится на песке.
Дальше конфигурация и ввод людей. Полезен простой образ: пилот на этом этапе похож на переезд в новый офис, где мебель ещё не расставлена, но сотрудники уже должны знать, где их стол. На неделях 3–4 создаются рабочие пространства под выбранные проекты, настраиваются стадии и группы задач под реальный процесс команды, сотрудники приглашаются по email с нужным уровнем доступа, а обучение проходит на живых задачах команды в формате сессии на 60–90 минут. Демо-данные для этого не годятся: их никто не запомнит.
Недели 5–6 — рабочий режим. Обсуждения по пилотным проектам переходят из чатов в задачи, вводится одно обязательное правило отчётности (например, статус по срокам на еженедельной встрече), а все запросы на доработку процесса фиксируются в одном списке, но внедряются только те, что реально блокируют работу. Задача этапа: выработать привычку, а не собрать идеальную конфигурацию.
К неделям 7–8 должен появиться ответ на вопрос, который задавали себе все участники с первого дня: стоило ли это затраченного времени. Для ответа сравнивают метрики с нулевой точкой, собирают 3–5 цитат пользователей и готовят одностраничное решение для спонсора: расширяем, корректируем или останавливаем, с зафиксированной датой следующего шага. Для прогноза стоимости расширения удобно свериться с калькулятором TCO и ROI.
Правила ведения задач нужно зафиксировать письменно уже на второй неделе. Если отложить это до результатов пилота, при расширении каждый новый отдел придумает свои статусы и свою логику сроков, и сводный портфель окажется несопоставимым набором данных, по которому ничего не посчитать. Там же, на старте, стоит договориться, где живут правила и регламенты: решение «Ведение базы знаний и регламентов компании» закрывает эту задачу и заодно снимает половину вопросов при онбординге участников следующих волн расширения, потому что инструкции лежат рядом с задачами, а не в отдельном документе, который быстро устаревает.
Как выглядит рост пилота в цифрах: ЕДИНЫЙ ЦУПИС и миграция с Jira
Реальные внедрения дают два типа эффекта: охват (сколько людей перешло в систему) и процессный (насколько быстрее проходит цикл конкретной работы). Первый без второго плохо убеждает финансового директора. Можно отчитаться, что «500 человек в системе», и не ответить на вопрос, что изменилось в деньгах или времени.
Платёжный сервис в регулируемой индустрии развлечений, ЕДИНЫЙ ЦУПИС, завершил внедрение Shtab после анализа рынка и оценки соответствия требованиям безопасности финансовой компании. Внедрение шло этапами: подготовка инфраструктуры, развёртывание в собственном контуре компании, интеграция с корпоративными сервисами, обучение персонала. По итогам больше половины сотрудников компании работают в системе (пресс-релиз, «Ведомости»). Отдельно компания перенесла в систему работу с целями по OKR. Shtab включён в Единый реестр российского ПО и доступен в облаке, частном облаке и on-premise, так что контур развёртывания не меняется по мере роста охвата — для регулируемой организации это обязательное условие расширения.
Во втором кейсе, миграции с Jira, новым по сравнению со стартовым охватом стал процессный эффект: срок согласования документов сократился с типичных 30–60 дней до 12, то есть почти втрое.
Полезны и внешние ориентиры, даже не из отечественной практики. Atlantic Lottery в регулируемой отрасли после перехода к централизованному управлению проектами заявляет 50% ROI и более $240 тыс. годовой экономии (кейс Atlantic Lottery). Context Architects отчитывается о более чем 700 днях сэкономленного рабочего времени в год суммарно по всем функциям компании; из них 530 дней приходится на дизайн и 53 дня на управление проектами, остальное распределено по прочим функциям (кейс Deltek).
Во всех четырёх примерах эффект проявлялся на цепочке передач между подразделениями: между бизнесом и ИТ, компанией и подрядчиками, дизайном и управлением проектами. Отсюда вывод, который редко формулируют прямо.
Контр-интуитивное: успешный пилот — плохой предсказатель корпоративного внедрения
Пилот на одной команде по определению не может показать главный экономический эффект системы, потому что этот эффект возникает на границах между отделами. Поэтому «отличный пилот» часто обрывается на попытке подключить вторую команду.
Внутри одной команды задачи и так более-менее видны: люди сидят рядом, обсуждают статусы на летучках, знают, кто чем занят. Выигрыш от системы здесь в удобстве: меньше сообщений, понятнее структура. Это реальная ценность, но она плохо конвертируется в цифру для бюджетного комитета.
Деньги появляются там, где заканчивается зона ответственности одной команды: на согласовании с юристами, на передаче задачи подрядчику, на приёмке у заказчика. Именно на этой границе и возникли эффекты из кейсов выше: почти трёхкратное сокращение цикла согласования, четверть рабочего времени, которое раньше уходило на переписку с подрядчиками, и переход ИТ-задач на единые стандарты по всему потоку. Если перевести в часы одного менеджера проекта, это примерно неделя рабочего времени в месяц, которая возвращается из переписки в работу.
Поэтому уже в пилот стоит включить один межфункциональный процесс с участием хотя бы одного соседнего подразделения, даже если формально пилотирует одна команда. Иначе на этапе расширения ценность придётся доказывать заново, с нуля, людям с другой мотивацией и другим начальником. Похожую логику показывает кейс завода, где единая система связала производственные и проектные задачи вместо разрозненной работы цехов и проектного офиса.
Второе наблюдение: не нужно гнаться за стопроцентным охватом компании. Порог, после которого система становится фактическим стандартом, наступает раньше полного покрытия. В кейсе ЕДИНОГО ЦУПИС стандартом систему сделало уже то, что в ней работает больше половины сотрудников, а в материалах по стратегии «посадить и расширить» достаточным условием называют активное использование в трёх и более подразделениях. После прохождения порога задача меняется: теперь нужно закрывать оставшиеся обходные пути — параллельные таблицы, чаты для статусов, отчёты в Excel, которые ещё живут по инерции. Уговаривать новых пользователей на этом этапе уже не требуется.
Чем настраивать расширение: рабочие пространства, роли и шаблоны в Shtab
Уровни доступа в Shtab
Расширение на соседние отделы упирается прежде всего в структуру доступа и повторяемость конфигурации. Покупка дополнительных лицензий тут самая простая часть.
Под каждый отдел или направление создаются отдельные рабочие пространства с проектами; внутри проекта процесс делится на стадии, а направления работ на группы задач. На диаграмме Ганта стадии выводятся по срокам, и каждая задача визуально находится на своём этапе. Сводный статус для встречи со спонсором собирается прямо отсюда, готовить отдельный отчёт руками не нужно.
Доступы раздаются приглашением сотрудников по email с указанием уровня доступа. В системе три системных уровня: «Пользователь» создаёт и выполняет задачи, «Менеджер» создаёт и настраивает рабочие пространства с проектами, «Администратор» управляет компанией, сотрудниками и правами и видит все проекты. Подразделения, группы сотрудников и должности можно заполнить позже, после приглашения людей. Для пилота это снимает подготовительный этап, который иначе отъедает первую неделю.
Если готовые роли не подходят под специфику отдела, создаётся свой уровень доступа: например, финансовый модуль закрывается полностью, а права по проектам остаются полными. Так подключаются отделы, которым не нужен раздел «Финансы», но нужна полная работа с задачами и сроками.
При росте числа подразделений важна гигиена доступов. Права меняются в настройках команды или через профиль сотрудника, отработавшие рабочие пространства архивируются, доступы настраиваются на уровне папок. Перенос прав руководителя выполняется по письму с его почты в поддержку, и этот порядок стоит прописать в регламенте заранее, до того как адвокат изменений передаст дела, а не разбираться постфактум, когда он уже ушёл на новую роль.
Третий и четвёртый отдел не обязательно настраивать с нуля. Для этого и существует сценарий из решения «Запуск однотипных проектов по шаблону»: структура проекта, стадии, группы задач и роли копируются с пилотной конфигурации, а правится только то, что действительно отличается у нового отдела. На практике это разница между двумя днями и двумя неделями на подключение подразделения.
Так маршрут и замыкается: 10 проектов и одна команда в первый месяц, три подразделения к концу квартала, больше половины сотрудников через год. Начните с одного вопроса спонсору: какое управленческое решение он хочет принимать по данным из системы через восемь недель. Если на этот вопрос есть ответ, пилот можно запускать в следующий понедельник.
