Кто на самом деле отвечает за результат внедрения

После разговора о влиянии и контроле легко прийти к дипломатичной формулировке:

За результат отвечают и поставщик, и клиент.

Я с ней согласен.

Но для управления она почти бесполезна.

Если не назвать конкретные действия, совместная ответственность быстро превращается в ситуацию, где каждая сторона уверена: основную работу должна была сделать другая.

Поставщик говорит:

Мы все внедрили. Сотрудники клиента просто не пользуются системой.

Клиент отвечает:

Вы знали, что сотрудники должны будут ею пользоваться. Почему внедрение этого не обеспечило?

Интегратор говорит:

Мы реализовали требования технического задания.

Руководитель клиента отвечает:

Но мы покупали не техническое задание. Мы покупали улучшение процесса.

Сотрудники говорят:

Нам никто нормально не объяснил новый стандарт.

Руководитель уверен:

Все обсуждалось на совещании.

Так проект формально заканчивается, но ожидаемое изменение не происходит.

Результат проходит через цепочку владельцев

Возьмем пример из продаж.

Компания хочет повысить долю разговоров, в которых зафиксирован конкретный следующий шаг.

Для реального изменения нужно как минимум:

1. Договориться, что считать корректным следующим шагом.
2. Перевести договоренность в проверяемый критерий.
3. Настроить систему.
4. Проверить качество оценки на реальных звонках.
5. Синхронизировать собственника и РОПа.
6. Объяснить стандарт менеджерам.
7. Разобрать спорные примеры.
8. Добиться выполнения нового действия.
9. Увидеть динамику.
10. Сравнить ее с переходом по воронке.
11. При необходимости изменить критерий или процесс.

Кто отвечает за всю цепочку?

Никто один.

Но у каждого шага должен быть конкретный владелец.

Поэтому полезнее говорить не об общей ответственности за результат, а о карте ответственности.

За что отвечает поставщик

Поставщик должен отвечать за то, что находится в его профессиональной и операционной зоне.

В зависимости от продукта это может быть:

• корректность реализации согласованной функции;
• соблюдение сроков своей части проекта;
• качество интеграции;
• работоспособность системы;
• обработка доступных данных;
• прозрачность ограничений;
• понятность результата;
• возможность проверить основание вывода;
• обучение согласованным сценариям;
• помощь в первичной настройке;
• предупреждение о критичных зависимостях;
• фиксация требований к данным и процессу;
• измерение согласованных показателей;
• поддержка в период стабилизации.

Поставщик не должен прятаться за формулировкой «мы сделали по ТЗ», если уже во время проекта видит, что ТЗ не ведет к заявленной цели.

Это не означает, что он обязан бесплатно переделывать любой процесс клиента.

Но профессиональная ответственность включает обязанность обозначить риск.

Если клиент хочет получить рост дисциплины, а проект ограничивается установкой программы без правил работы, обучения и контроля, нужно сказать прямо:

Техническая часть будет запущена. Но сама по себе она не изменит поведение команды. Для ожидаемого эффекта нужны действия руководителя.

Молчать, выполнить формальную работу и затем сослаться на границы договора - слабая позиция.

За что отвечает руководитель клиента

Руководитель отвечает за среду, в которой должен работать продукт.

Например:

• определить приоритет проекта;
• назначить владельца;
• выделить время сотрудников;
• утвердить правила;
• принять спорные решения;
• обеспечить доступ к данным;
• согласовать изменения процесса;
• встроить новые действия в управление;
• контролировать исполнение;
• реагировать на выявленные отклонения;
• не менять цель каждую неделю без пересмотра плана.

Сервис может показать проблему.

Он не может заставить руководителя принять решение.

Интегратор может настроить обязательное поле.

Он не может сам определить, какая информация действительно нужна бизнесу.

Консультант может предложить стандарт.

Он не может вместо руководителя обеспечить его легитимность внутри команды.

Если продукт требует управленческой реакции, а руководитель не готов реагировать, ожидаемый эффект становится маловероятным.

Это неприятная часть разговора с клиентом. Она усложняет продажу.

Но продать проект, который не имеет владельца со стороны бизнеса, - почти всегда более дорогая ошибка.

За что отвечают сотрудники

Сотрудники отвечают за действия, которые находятся под их контролем:

• использовать согласованный процесс;
• вносить данные;
• выполнять обязательные шаги;
• проходить обучение;
• сообщать о противоречиях;
• не обходить систему без причины;
• выполнять договоренности;
• давать обратную связь на спорные случаи.

При этом фраза «сотрудники сопротивляются» не должна автоматически оправдывать плохое внедрение.

Иногда люди не используют систему не потому, что ленивы.

Возможны другие причины:

• процесс стал тяжелее;
• интерфейс неудобен;
• действия дублируются;
• критерий непонятен;
• руководители сами работают по-старому;
• новые требования конфликтуют с мотивацией;
• система оценивает людей несправедливо;
• никто не разобрал пограничные примеры.

Ответственность сотрудника начинается там, где у него есть понятный стандарт, доступный инструмент, обучение и реальная возможность выполнить требование.

Если система создает лишнюю работу, а поставщик и руководитель называют это сопротивлением изменениям, они просто перекладывают на сотрудника ошибку конструкции.

Совместная зона - место, где нельзя заменить друг друга

Некоторые результаты нельзя отдать одной стороне:

• формулировка критерия;
• описание целевого процесса;
• настройка сегментов;
• определение целевого этапа;
• интерпретация данных;
• калибровка спорных случаев;
• выбор промежуточных показателей;
• решение о том, подтвердилась ли гипотеза.

Поставщик знает возможности системы и метод измерения.

Клиент знает контекст своего бизнеса.

Если поставщик пытается полностью заменить клиента, он начинает изображать знание чужой реальности.

Если клиент должен сам переводить размытое ожидание в технический критерий, поставщик не выполняет важную часть своей профессиональной работы.

Сильная совместная работа выглядит так:

Клиент формулирует фокус обычным языком.

Поставщик помогает перевести его в наблюдаемые действия и показатели.

Руководитель проверяет, соответствует ли критерий реальности.

Система измеряет.

Стороны вместе интерпретируют результат.

Именно на этом принципе строится калибровка в «Дожми Продажи»: AI не объявляет стандарт сам. Собственник, РОП, сотрудники и система должны договориться, что именно считается выполнением критерия.

Внешние факторы тоже нужно назвать

Есть обстоятельства, которыми не управляет ни одна из сторон проекта:

• изменение спроса;
• действия конкурентов;
• регулирование;
• экономическая ситуация;
• сезонность;
• изменение стоимости трафика;
• уход ключевого сотрудника;
• ограничения сторонних систем;
• сбои внешних платформ;
• изменение поведения покупателей.

Их нельзя использовать как универсальное оправдание.

Но их нужно учитывать при интерпретации эффекта.

Если продажи упали в период резкого изменения рынка, нельзя автоматически считать внедрение неудачным.

Если продажи выросли на сезонном пике, нельзя автоматически записывать весь рост продукту.

Хорошая аналитика не уничтожает неопределенность. Она делает ее видимой.

Как выглядит карта ответственности

Для каждого ожидаемого результата полезно заполнить четыре блока.

1. Что делает поставщик

Конкретные действия и результаты, за которые он отвечает напрямую.

2. Что делает клиент

Решения, ресурсы, изменение процесса и исполнение.

3. Что стороны делают совместно

Настройка критериев, калибровка, интерпретация и пересмотр гипотез.

4. Что находится вне контроля

Факторы, которые нужно наблюдать, но нельзя гарантировать.

Допустим, цель - уменьшить число сделок, потерянных после отправки коммерческого предложения.

Поставщик:

• настраивает определение факта отправки предложения;
• проверяет наличие согласованного следующего действия;
• показывает сделки без следующего шага;
• формирует динамику.

Клиент:

• утверждает стандарт;
• назначает владельца;
• обучает менеджеров;
• требует выполнения;
• реагирует на отклонения.

Совместно:

• стороны проверяют спорные примеры;
• уточняют критерий;
• сравнивают изменение поведения с переходом на следующий этап.

Вне контроля:

• решение покупателя;
• бюджет клиента;
• действия конкурентов;
• изменение условий рынка.

В таком виде разговор о результате становится намного честнее.

И намного требовательнее к обеим сторонам.

Карта ответственности не должна стать приложением, которое никто не читает

Есть риск превратить эту идею в еще одну таблицу на старте проекта.

Заполнили роли, положили файл в папку, забыли.

Карта работает только тогда, когда используется в управлении:

• у каждого действия есть имя владельца;
• есть срок;
• есть видимый статус;
• отклонение обсуждается;
• при изменении гипотезы карта обновляется;
• итог проекта оценивается по фактическому выполнению сторон.

Особенно важно заранее договориться, кто принимает решение в спорной ситуации.

Кто утверждает критерий?

Кто решает, что данных недостаточно?

Кто может остановить эксперимент?

Кто меняет стандарт для команды?

Без этого совместная зона быстро превращается в бесконечное согласование.

Почему это усиливает предложение

Некоторые продавцы боятся раскрывать обязанности клиента.

Им кажется, что продажа станет сложнее.

Возможно.

Но она станет честнее и надежнее.

Вместо:

Наша система повысит конверсию.

появляется:

Система будет находить сделки, в которых не согласован следующий шаг. Руководитель утверждает стандарт и обеспечивает реакцию команды. Мы вместе проверяем динамику критерия и переход на следующий этап.

Это звучит сложнее рекламного лозунга.

Но зрелому покупателю видно, что поставщик понимает механизм эффекта, а не просто обещает деньги.

Практический критерий

Для каждого ожидаемого результата проверьте:

Назван ли конкретный владелец каждого необходимого действия?

Не «команда».

Не «стороны».

Не «бизнес».

Конкретная роль, которая должна выполнить конкретное действие.

Если владельца нет, высока вероятность, что действие не будет выполнено, а ответственность после проекта станет предметом спора.

Что дальше

Даже правильная карта ответственности ничего не даст, если само обещание остается абстрактным.

В следующей части разберем, как говорить о выручке, расходах и конверсии прямо, но без ложной гарантии.

Продолжение - «Как честно говорить о росте выручки и сокращении расходов».

Предыдущая статья - «Влияние не равно контролю».

Частые вопросы

Должен ли поставщик отвечать за внедрение у сотрудников?

Он должен отвечать за согласованную часть: обучение, понятность сценария, качество инструмента и выявление рисков. Управленческое требование и контроль исполнения остаются у руководителя клиента.

Что делать, если клиент не выполняет свою часть?

Фиксировать отклонение не после провала, а в момент его появления. Стороны должны заранее договориться, какие действия обязательны и как невыполнение влияет на сроки, объем и оценку эффекта.

Кто отвечает за неверную исходную гипотезу?

Обычно это совместная зона. Клиент приносит контекст, поставщик - метод проверки. Важнее не искать виноватого, а заранее предусмотреть возможность пересмотра гипотезы.