Сопротивление изменениям при внедрении 1С:CRM: что делать, если сотрудники продолжают работать по-старому
После запуска 1С:CRM заказчик обычно ожидает понятный результат: менеджеры создают сделки, фиксируют контакты, двигают их по этапам и ставят следующие задачи. Руководитель отдела продаж открывает воронку и видит, что происходит с продажами.
На практике рядом с CRM еще долго могут жить Excel, заметки в телефоне, личные календари и переписка в мессенджерах. Сделки в системе появляются перед совещанием, этапы меняются задним числом, а причины отказов выбираются только потому, что без этого нельзя закрыть карточку.
Такое поведение часто сразу называют сопротивлением изменениям. Но далеко не факт, что сотрудники не хотят работать по новым правилам.
На первых разборах подобных ситуаций полезнее спросить иначе: в какой момент менеджер выходит из CRM и возвращается к таблице, почте или своим заметкам?
Иногда менеджер действительно работает с клиентом всю неделю, но в CRM это почти не видно. Переписка остается в почте, дата следующего звонка — в телефоне, а сделка появляется в системе только перед совещанием.
На рабочем разборе это заметно довольно быстро — например, несколько карточек созданы одним днем, этапы обновлены почти одновременно, а у активных сделок нет следующего шага. При этом сам сотрудник не бездействовал — просто основная история работы осталась вне CRM.
Перед тем как говорить о дисциплине, я обычно проверяю сам рабочий маршрут. Может ли менеджер провести сделку без повторного ввода? Понятно ли ему, когда менять этап? Не требует ли сам руководитель параллельно обновлять Excel, ориентируясь на старый вид отчетности? То есть, уже в процессе промышленной эксплуатации полезно вместе с сотрудником пройти одну реальную продажу: от первого обращения до заказа или отказа. Обычно на этом маршруте и находится шаг, после которого менеджер возвращается к старому инструменту.
Если же на этих шагах всё работает нормально, сотруднику действительно могут понадобиться время, повторное обучение и контроль. Но пока рядом остается второй порядок работы, требование «вести всё в CRM» даст в основном формальное заполнение.
Мини-кейс: Почему больше всего сделок появлялось в понедельник
После запуска 1С:CRM менеджеры должны были создавать сделку сразу после появления подтвержденного интереса клиента и обязательно указывать следующее действие.
Через несколько недель руководитель заметил странную закономерность: больше всего новых сделок появлялось в понедельник утром перед общим совещанием.
На разборе выяснилось, что сотрудники в течение недели продолжали вести клиентов в личных таблицах. Перед встречей они переносили актуальные данные в CRM, чтобы отчет выглядел заполненным.
Сначала это восприняли как нарушение дисциплины. Но оказалось, что сам руководитель на совещании открывал старый Excel. В нем были привычные колонки, комментарии по каждому менеджеру и итоговые суммы.
Получалось, что CRM заполняли для контроля, а реальные решения принимали по таблице.
Начали не с дополнительных напоминаний менеджерам, а с изменения самого совещания. Руководитель стал открывать отчет из 1С:CRM. Из него убрали несколько лишних колонок, добавили отбор по подразделению и вывели сделки без следующего действия.
После этого вести два источника стало бессмысленно. Личные таблицы исчезли не сразу: еще несколько недель часть менеджеров оставляла их «для себя». Но для отчетности и рабочего разбора использовались уже данные 1С:CRM, поэтому постепенно Excel перестал быть основным инструментом.
Когда CRM добавляет менеджеру двойную работу
Менеджер может спокойно относиться к новой системе, но быстро перестает ее использовать, если одно и то же действие приходится повторять.
Например, клиента сначала регистрируют в 1С:CRM, затем повторно создают контрагента в 1С:УТ или ERP. Плановую сумму вводят в сделке, а через несколько дней снова указывают в заказе. Комментарий фиксируют в карточке и отдельно отправляют руководителю в чат.
В такой схеме сотрудники сами выбирают главный инструмент. Обычно им становится тот, который ближе к реальной продаже или обязательному документу.
Как я писала выше, важно проходить реальные сценарии продаж - от первичного обращения клиента до заказа и закрывающих документов. Так больше вероятность обнаружить повторный ввод данных в отличие от "идеальных" примеров, которые иногда подбираются на тестовой эксплуатации.
Часть повторов можно убрать интеграцией. Иногда достаточно определить, какая система является источником информации. Например, сумма заказа хранится в учетной системе, а в CRM передается автоматически.
В другом случае нужно официально отказаться от старой таблицы, а не оставлять ее «на переходный период» без срока.
На одном проекте менеджеры жаловались, что им приходится дважды указывать контактное лицо. В CRM контакт выбирался в сделке, но при создании заказа в учетной базе его запрашивали повторно. Технически это были два разных объекта, но для пользователя действие выглядело одинаково.
После доработки контакт стал передаваться вместе с основанием заказа. Изменение было небольшим, но повторное действие исчезло. После этого вопросов к связке CRM и учетной системы стало заметно меньше.
Один этап воронки — три разных толкования
Названия этапов могут казаться очевидными только участникам проектной команды.
Например, в сценарии продаж есть этапы «Предложение», «Переговоры», «Согласование» и «Ожидание решения». Один менеджер переводит сделку в «Предложение», когда подготовил файл. Второй — после отправки клиенту. Третий — только после первой реакции.
В отчете все сделки находятся на одном этапе, но их фактическое состояние различается.
На тестовой эксплуатации я предлагаю взять несколько реальных сделок и независимо показать их двум менеджерам. По одной и той же карточке один сотрудник выбирает этап «Предложение», потому что файл уже подготовлен. Второй оставляет предыдущий шаг, поскольку письмо клиенту еще не отправлено.
После такого разбора критерии обычно формулируются проще.
Например, «Предложение» начинается не в момент подготовки файла, а после отправки коммерческого предложения клиенту. В карточке при этом должна появиться дата следующего контакта.
На этапе «Согласование» уже обсуждаются цена, договор или другие условия. Менеджер фиксирует, какое решение ожидается от клиента и когда планируется следующий контакт.
В «Отказ» сделка переходит, когда продажа не состоится в текущем цикле. Для закрытия нужна понятная причина, а не первый доступный вариант из справочника.
Если для выбора этапа сотруднику каждый раз приходится уточнять правило у руководителя, значит, название этапа в сценарии продаж пока не стало рабочей инструкцией.
То же касается причин отказа. Большой справочник не всегда дает хорошую аналитику. Если менеджер каждый раз выбирает между «Нет бюджета», «Высокая цена», «Не согласовали стоимость» и «Дорого», отчет получится не совсем корректным.
Когда CRM нужна руководителю, а менеджеру оставляют только ввод
Руководителю от CRM нужны воронка, прогноз, причины отказов и контроль сделок без движения. Менеджеру при этом могут достаться только новые поля и требования.
Если на обучении показывать только то, что сотрудник обязан заполнить, он воспринимает систему как еще один отчет для начальника.
Пользователю стоит показать, что он получает взамен.
Дата следующего контакта помогает не держать все договоренности в голове. История взаимодействий позволяет другому сотруднику подхватить клиента во время отпуска. Связь сделки с заказом помогает увидеть оплату без отдельного запроса в бухгалтерию.
Задачи по клиенту собираются в одном месте, а не распределяются между календарем и заметками.
Эта польза должна быть реальной. Если сотруднику говорят, что CRM упростит работу, а затем требуют заполнять пятнадцать полей, которые он больше нигде не использует, доверие к новому процессу быстро снижается.
Поэтому обязательные поля на первой волне лучше проверять по простому принципу: что произойдет, если менеджер не укажет это значение?
Если без поля нельзя продолжить процесс, подготовить документ или построить отчет, который действительно используется, обязательность понятна. Если данные могут понадобиться когда-нибудь в будущем, блокировать из-за них создание сделки не стоит.
Что проверить до запуска
До старта не нужно пытаться подробно описать все возможные возражения пользователей. Полезнее пройти несколько реальных сценариев от начала до конца.
Например, новый клиент оставил заявку на сайте. Нужно понять, кто создает карточку, когда появляется сделка, какой этап выбирается, где фиксируется контакт и что менеджер делает после разговора.
Затем можно взять повторную продажу постоянному клиенту, долгую сделку с договором и отказ после коммерческого предложения.
На таких примерах быстро обнаруживаются вопросы, которые при обсуждении даже не всплывали. Контакт уже существует, но его трудно найти. Для повторной сделки система требует заново заполнить часть данных. Отказ нельзя закрыть без поля, смысл которого менеджер не понимает.
Еще до запуска нужно прямо договориться, что перестает использоваться.
Недостаточно сказать, что теперь работа ведется в CRM. Нужно определить, обновляется ли после запуска старая таблица, куда менеджер передает статус руководителю и какой отчет открывают на совещании.
Если старый и новый порядок остаются равноправными, пользователи выберут привычный.
Для пилота лучше взять сотрудников с разным подходом к работе. Если включить только самых дисциплинированных и заинтересованных, система пройдет проверку в слишком тепличных условиях.
Менеджер, который ведет много параллельных сделок, покажет проблемы со списками и задачами. Сотрудник, привыкший к личным заметкам, быстро обнаружит лишние действия. Опытный продавец задаст вопросы по нестандартным сценариям, которые не попали в первоначальное описание.
Как провести обучение, чтобы оно помогло после запуска
Обзор всех возможностей 1С:CRM редко запоминается. Пользователю показывают клиентов, сделки, задачи, рассылки, отчеты и настройки. Через несколько дней он не может вспомнить, что делать после первого разговора с клиентом.
Поэтому менеджеру лучше дать одну знакомую ситуацию. Например, постоянный клиент обратился с новым запросом.
Сотрудник сам находит карточку, создает новую сделку, выбирает этап, записывает результат разговора и ставит следующий контакт. Важно, чтобы он выполнил эти действия без подсказки консультанта.
Затем руководитель открывает эту же сделку в своем отчете и проверяет, где она появилась. Так менеджер видит, зачем заполнял карточку, а руководитель — какие данные действительно доступны для контроля.
Администратору отдельно показывают только те места, которые понадобятся при поддержке: права, историю изменений и ошибки обмена.
Вопросы обычно возникают не во время демонстрации, а когда сотрудник впервые выполняет действия самостоятельно.
Еще одна полезная часть обучения — разбор границ системы. Пользователи должны понимать, что хранится в CRM, что приходит из учетной базы и где смотреть заказ, оплату или договор.
Если эту границу не объяснить, сотрудники будут считать отсутствие части данных ошибкой CRM или вводить их вручную.
Что делать в первые две недели
На старте вопросы должны попадать в одно понятное место. Иначе часть замечаний останется в общем чате, часть — в личной переписке аналитика, а несколько ошибок менеджеры просто обойдут привычным способом.
Я обычно предлагаю один канал поддержки и одного участника со стороны заказчика, который принимает все вопросы. Он уже сам определяет, требуется консультант, администратор или разработчик.
Само замечание лучше записывать не как «неудобно работать со сделкой», а через действие пользователя.
Менеджер создавал повторную продажу по существующему клиенту. Не нашел контактное лицо в форме сделки и создал его повторно. В результате появился дубль.
Такое описание можно проверить. Видно, кто выполнял действие, что ожидал и к чему это привело.
При этом не стоит менять настройки после каждого обращения.
В первые дни пользователи часто просят вернуть привычные колонки, названия и поля. Часть предложений действительно полезна, часть связана с тем, что новый порядок еще не стал привычным.
Срочно исправляются блокирующие ошибки. Остальные замечания лучше несколько дней собирать и разбирать вместе. Если один и тот же вопрос возникает у нескольких менеджеров, это уже хороший кандидат на изменение системы или инструкции.
Вместо общего отчета по активности пользователей в первые недели достаточно посмотреть три списка: сделки без следующего действия, просроченные первичные обращения и сделки, которые давно не меняли этап.
По ним быстро видно, используется ли CRM в ежедневной работе или заполняется формально.
Мини-кейс: Почему обязательное поле не гарантирует полезные данные
В одной настройке 1С:CRM поле «Причина отказа» сделали обязательным. Руководитель хотел понять, почему компания теряет сделки.
Через месяц большая часть отказов относилась к значениям «Другое» и «Неактуально». Формально поле было заполнено, но использовать отчет для решений не получалось.
На разборе выяснилось, что в списке было пятнадцать причин. Несколько вариантов отличались только формулировками. Например, менеджеры по-разному понимали значения «Нет бюджета», «Высокая цена» и «Не согласована стоимость».
Список сократили до нескольких понятных групп. Для «Другого» оставили обязательный комментарий. Затем вместе с сотрудниками разобрали несколько закрытых сделок и выбрали причины повторно.
Дополнительного контроля за заполнением не потребовалось. Менеджеры не отказывались указывать причину. Они просто не понимали, чем один вариант отличается от другого.
Когда вопрос уже должен решать руководитель
Не все вопросы решаются настройками и обучением.
Бывает, что процесс проверен, двойного ввода нет, обязательные поля сокращены, правила этапов понятны, а сотрудник всё равно продолжает вести клиентов в личной таблице.
В такой ситуации аналитик уже не сможет решить вопрос новой памяткой. Руководителю нужно определить один рабочий источник и самому использовать его на совещании.
Пока сотрудник знает, что перед встречей у него снова попросят Excel, он будет поддерживать и таблицу, и CRM.
Административный контроль особенно важен в тех действиях, которые нельзя обеспечить только настройками. Например, система не всегда может определить, что менеджер провел звонок, но не записал результат.
При этом требование работает только тогда, когда новый порядок можно выполнить без постоянных обходов. Если сотрудник вынужден вводить одни данные дважды или не может найти нужное действие на форме, контроль даст внешнюю дисциплину, но не качественные данные.
Как понять, что переход действительно состоялся
Количество созданных сделок само по себе мало о чем говорит. Их можно занести задним числом.
Я смотрю не столько на число карточек, сколько на то, зачем сотрудники открывают CRM в течение дня.
Менеджер использует список задач, чтобы понять, кому сегодня позвонить. Руководитель смотрит сделки без движения прямо в системе. При передаче клиента другому сотруднику не нужно собирать историю из писем. Причины отказов обсуждают по отчету, а не восстанавливают по памяти.
В этот момент CRM перестает быть отдельной обязанностью и становится частью процесса продаж.
Пока Excel остается рабочим источником, данные в CRM будут появляться с опозданием. Поэтому я сначала смотрю, по какому отчету руководитель проводит совещание, где менеджер хранит следующие действия и какие поля он заполняет повторно.
Вопрос дисциплины имеет смысл обсуждать уже после этого. Иначе под сопротивлением сотрудников легко не заметить недостатки самого внедрения.