Блог

Почему до 70% изменений в компаниях не оправдывают ожиданий?

Около 50−70% организационных изменений заканчиваются провалом — не приводят к ожидаемым результатам. Причём это касается как частного бизнеса, так и госсектора. Почему так происходит? Чаще всего проблема не в самой идее изменений, а в способе их внедрения.
В этой статье разберём главные причины провалов и расскажем, как гибкие методологии (Scrum, Agile) помогают компаниям проводить трансформации успешно.
Давайте рассмотрим типичный пример неправильного внедрения изменений в компании.


Пример неудачных преобразований в компании: анализ ошибок и рекомендации по их успешному внедрению

Неправильный подход: «сверху вниз» без вовлечения команды. ❌
Компания: Крупный розничный банк, внедряющий новую CRM-систему.
Что пошло не так?

  • Решение принято без сотрудников
  • Руководство купило дорогую CRM-систему, не спросив мнения менеджеров по продажам, которые будут ею пользоваться.
  • Жесткий дедлайн без тестирования
  • Приказ: «Через месяц все переходят на новую систему». Обучение — два часа вебинара.
  • Игнорирование обратной связи
  • Сотрудники сразу заметили баги и неудобный интерфейс, но их жалобы проигнорировали: «Вы просто не хотите меняться».
  • Нет поддержки
  • IT-отдел не успевал устранять ошибки, а продажи упали из-за простоя.
Результат:
  • Через 3 месяца 60% менеджеров вернулись к Excel.
  • Текучесть кадров выросла на 25%.
  • Убытки: $ 500K на лицензии + падение доходов.
Итак, вернёмся к ключевым причинам, лежащим в основе неудачного внедрения изменений в компании.

1. Отсутствие чёткого видения и вовлеченности руководства

Проблема:
Многие изменения проваливаются, потому что нет ясной цели или руководство не доносит её до сотрудников. Люди не понимают, зачем что-то менять, и сопротивляются.
Решение:
  • Scrum-подход: В Agile ключевую роль играет Product Owner (Владелец продукта) — он формирует видение и доносит его до команды.
  • Прозрачность: Регулярные Sprint Reviews и Retrospectives помогают держать всех в курсе изменений.

2. Сопротивление сотрудников

Проблема:
Люди боятся перемен, особенно если:
  • не видят личной выгоды;
  • чувствуют, что изменения навязаны «сверху»;
  • не уверены в своих навыках для новой работы.
Решение:
  • Постепенное внедрение: Scrum предлагает короткие итерации (спринты), что снижает стресс.
  • Вовлечение команды: В Agile решения принимаются коллективно (на планировании и ретроспективах).
  • Обучение и поддержка: Scrum Master помогает команде адаптироваться.

3. Недостаток коммуникации

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

4. Жёсткие планы вместо гибкости

Проблема:
Классическое управление строится на долгосрочных планах, но рынок меняется слишком быстро. В итоге:
  • компания тратит месяцы на разработку, а продукт уже неактуален;
  • невозможно оперативно скорректировать курс.
Решение:
  • Гибкость Scrum: короткие спринты (2−4 недели) позволяют быстро адаптироваться.
  • Итеративный подход: каждый спринт — новый маленький проект, который можно проверить на реальных пользователях и у которого есть свой бюджет и свой инкремент — результат работы за спринт, который можно показать, оценить и принять решение о том, что стоит сделать в будущем, а чего не стоит делать.
  • Фокус на ценности: владелец продукта постоянно пересматривает приоритеты разработки элементов бэклога, доносит эту информацию как команде, так и всем заинтересованном в проекте лицам.

5. Отсутствие быстрых побед

Проблема:
Если сотрудники долго не видят результатов, мотивация падает.
Решение:
  • Демонстрация результатов после каждого спринта (Sprint Review).
  • Разбивка больших целей на маленькие задачи (User Stories).

6. Неправильная оценка ресурсов

Проблема:
Компании часто:
  • переоценивают свои возможности;
  • не учитывают риски;
  • не имеют «подушки безопасности» на случай изменений.
Решение:
  • Scrum помогает реалистично оценивать трудозатраты (Planning Poker, Velocity). Правда, стоит отметить, что это реалистичное планирование будет не сразу, это некая фича зрелой команды, её гордость и достижение — то, к чему надо прийти. Производительность команды за спринт равна сумме баллов (стори-поинтов) всех завершённых задач. Например, если команда завершила задачи на 5, 8 и 13 баллов, их Velocity для этого спринта составит 26. Чтобы получить более предсказуемое значение Velocity для планирования будущей работы, можно усреднить результаты за последние 3−5 спринтов.
  • Планирование спринта — при определении того, какие элементы бэклога будут выполнены в грядущую итерацию (спринт), также учитываются риски (например, команда может переоценить свои ресурсы). Для нивелирования рисков закладывается «подушка безопасности» — например, 10% времени/стори-поинтов в Velocity (скорость команды/мощность).

7. Отсутствие культуры экспериментов

Проблема:
В традиционных компаниях ошибки наказываются, поэтому сотрудники боятся пробовать новое.
Решение:
  • Agile-культура: ошибки — часть обучения. Не нужно бояться сделать ошибку, хуже — бояться её сделать, сделать и ждать наказания или просто замалчивать. При работе в спринте ситуации могут быть разными, например такими, что в принципе невозможно получить какое-то решение, если не сделаешь ошибку.
  • Fail fast, learn fast — быстрые эксперименты и коррекция курса. Данный подход к работе призывает принимать неизбежность неудач в стремлении к созданию лучшего решения. Суть философии в том, что вместо длительного планирования нужно начинать работу над проектом, зная, что первые попытки могут быть не идеальными (часть «Fail Fast»). Чем раньше выявляются и решаются проблемы, тем быстрее можно научиться на них и внести необходимые улучшения (часть «Learn Fast»).

Заключение

Как Scrum спасает реализацию изменений от провала?

  • Чёткое видение (Product Owner).
  • Постепенное внедрение (короткие спринты).
  • Прозрачность и коммуникация (Daily Scrum, Retro).
  • Гибкость (адаптация к изменениям).
  • Быстрые победы (Sprint Review).
  • Реалистичное планирование (Velocity, Planning Poker).
  • Культура экспериментов (без страха ошибок).
Если ваша компания планирует изменения — начните с малого: внедрите Scrum в одном отделе. Можно внедрять не весь фреймворк сразу, а использовать отдельные его события (планирование, ретроспектива и т. д.); покажите результат, масштабируйте. Так риск провала снизится в разы.

Давайте вспомним пример неудачно внедрённых изменений в самом начале нашей статьи и смоделируем, как это могло быть реализовано правильно:

Правильный подход: Agile-внедрение через Scrum.
Как нужно было сделать?

1) Пилотная группа и MVP (минимальная версия)
  • Внедрить CRM сначала в одном отделе (2−3 команды), собрать фидбек (обратная связь).
  • Настроить базовые функции, а не «всё и сразу».

2) Вовлечение пользователей с самого начала
  • Провести воркшопы с менеджерами: «Какие функции критичны?»
  • Назначить Product Owner’а из бизнеса, а не из IT.

3) Итеративное улучшение (спринты по 2 недели)
  • Каждый спринт:
  • добавлять 1−2 новые фичи;
  • исправлять топ-3 проблемы из ретроспективы.
  • Daily Scrum для оперативного решения сбоев.

4) Поддержка и обучение
  • Внедрить гид-поддержку: наставник из IT сидит с командой первую неделю.
  • Создать внутренний чат для вопросов.

5) Мотивация через быстрые победы
  • После каждого спринта — демонстрация улучшений (Sprint Review).
  • Премировать команду за успешные кейсы.
Результат:
  • За 4 месяца CRM адаптирована под реальные нужды.
  • Продажи выросли на 15% благодаря автоматизации.
  • Команда чувствует ownership («Это наша система»).

Вывод

🔴 Провал: директивное внедрение без тестов, обратной связи и гибкости.

🟢 Успех: постепенное изменение через Scrum с вовлечением команды и итерациями.

Главный урок: даже лучшие технологии провалятся, если игнорировать людей, которые ими пользуются. Agile и Scrum превращают сопротивление в энергию для изменений.

А как вы готовитесь к внедрению изменений?