И почему прямые приказы едва не сорвали трансформацию.

Это история масштабных изменений в IT-компании (custom-разработка и сложная интеграция). Бизнес вырос до 100+ человек, и на стыке отделов вспыхнула классическая междоусобная война: Отдел продаж против Департамента производства (PMO и техлидов).

🤕Симптомы проблемы: Продажи: Закрывают крупные чеки, но продают клиентам «воздух», невыполнимые сроки и кастомные фичи без согласования с техлидами. Производство: Получает проект, понимает, что смета занижена втрое, начинает гореть по дедлайнам, факапит и сжигает маржинальность. Результат: Выручка растет, а чистая прибыль падает. Клиенты уходят с негативом, разработчики увольняются от выгорания, а фаундер работает мировым судьей 24/7. Руководство решает внедрить жесткую систему фильтрации — DoR (Definition of Ready): критерии готовности сделки к передаче в производство через единую карту процессов в Miro и чек-листы в Notion. Спустили регламент сверху. Назначили штрафы. Итог через 2 месяца: Продажи заявляют, что «регламенты убивают конверсию», а производство саботирует приемку новых проектов.

Сложность ADKAR: У разных ролей — разные блокировки

❕️Главная ошибка сложной трансформации — пытаться применить ADKAR ко всей компании как к единому монолиту. В кросс-функциональных процессах у каждого отдела свой барьер.

Вот как выглядела диагностика по ADKAR, когда процесс разложили по ролям:

1. Отдел продаж Awareness (Осознание): ❌ «Зачем нам DoR? Наша задача — продать. А как сдавать — пусть у техлидов голова болит». Desire (Желание): ❌ «Если я буду заставлять клиента заполнять эти 15 пунктов в Notion, он уйдет к конкурентам. Мой бонус зависит от объема сделки, а не от вашей маржи».

2. Производство (PMO и техлиды) Awareness (Осознание): ✅ «Мы прекрасно понимаем, зачем нужен DoR — чтобы не перерабатывать бесплатно». Desire (Желание): ❌ «Но мы не верим, что продаватели будут его соблюдать. Проще сразу заблокировать любую сделку и встать в позу». Ability (Способность): ❌ «Мы не умеем экологично объяснять клиенту и продажам технические ограничения — мы сразу начинаем сбиваться на агрессию».

Системная пересборка изменений по ADKAR Чтобы разблокировать трансформацию, изменения пришлось проектировать отдельно под каждую группу:

Шаг 1. Пересборка Awareness & Desire для Продаж (Связка мотивации) Перешили к смене KPI: Привязали бонус менеджеров по продажам не к факту подписания договора, а к факту успешного прохождения первого этапа производства (кассовому разрыву). Подсветили личную выгоду: Покажи клиенту DoR на старте — и клиент увидит в тебе не просто продавца, а сильного эксперта. Это повышает чек, а не снижает его.

Шаг 2. Развитие Knowledge & Ability через парное проектирование. Вместо чтения сухих регламентов запустили совместные воркшопы в Miro. Техлидов обучили фасилитации, а прожажников — базовой технической оценке. Первые 10 сложных сделок оценивались в формате «пары» (сейлз + техлид), где они вместе заполняли архитектуру проекта.

Шаг 3. Reinforcement (Закрепление) на уровне архитектуры. Внедрили автоматический триггер: карточка сделки физически не может перейти на этап «Договор» в CRM, пока в Notion не заполнен DoR с подписью техлида. Ввели еженедельный Post-Mortem разбор: если проект уходит в минус по марже, на общий ревью выносится конкретный шаг из карты процессов, где был допущен сбой. Без поиска виновных — чиним систему, а не людей.

✅️ Результаты через 4 месяца Маржинальность проектов: 📈Выросла на 28% за счет исключения непросчитанных рисков на этапе пресейла. Скорость онбординга проекта: ⛷️Сократилась с 3 недель до 5 дней (благодаря прозрачной карте в Miro). Конфликт отделов: 🤝Снизился до уровня конструктивного рабочего диалога, так как правила игры стали прозрачными и зашитыми в систему.

Главный вывод для B2B и IT: Если в изменении задействовано несколько отделов, нельзя прокатывать ADKAR «бульдозером» по всей компании. Диагностируйте точку затора (узкое место) отдельно для каждой роли. У Продаж затык может быть в Desire, а у Инженеров — в Ability.