8 причин, которые сорвут внедрение CRM-системы. Часть 1
Когда в компании заходит речь о внедрении CRM-системы, то на голову руководства сваливается куча вопросов:
- Какую выбрать, чтобы все работало, а не стало хуже?
- Как отнесется к переменам команда? Вдруг не получится, и я потеряю их доверие?
- Как убедить команду перейти на новую систему и избежать потерь при переходе?
- А если “втюхают” ненужный функционал и мы переплатим в Х2?
Спокойствие! На самом деле ваша главная задача - выбрать качественного подрядчика. Того, кто вникнет в ваши бизнес-процессы, подберет подходящее решение и поможет справиться с саботажниками.
В двух статьях мы, агентство Vitamin C, подробно расскажем, на что обратить внимание на этапе pre-sale, чтобы облегчить себе жизнь при переходе на crm-систему. Это первая часть, загляните к нам, что прочитать позже вторую.
Для наглядности рассмотрим наш недавний кейс с крупным клиентом. Проект в процессе разработки, поэтому его имя озвучивать не будем.
Что уже есть: подключено две 1С. “Управление торговым предприятием”, которое состоит из 6 баз и “Управление торговлей”, которое состоит из 4 баз, где ведется бух учет. Базы УТП обмениваются данными с базами УТ. Конфигурация очень старая и давно не обновляется.
Что должны сделать мы:
Переместить работу всех менеджеров и логистов в Битрикс24;
- Настроить CRM в соответствии с текущими бизнес-процессами, включая автоматизацию задач, маркетинга и документооборота;
- Связать CRM с 1С, чтобы они обменивались информацией о заказах. Настроить перемещение товаров между складами, сделать продажу между внутренними юр лицами, оформить права доступа на стороне Битрикс;
- Подключить два магазина на движке Joomla, где должны быть актуальные остатки. С одного из них должна идти запись на СТО;
- Сделать интеграцию с 2 профильными платформами;
- Подключить Инстаграм, Вконтакте и Фейсбук и мессенджеры, чтобы обращения падали в Битрикс24.
Внедрение CRM даже в небольшую компанию сопровождается препятствиями: расхождение ожиданий и реальности, появление дополнительных стейкхолдеров в процессе разработки или выявление не озвученных процессов. Все это может задержать внедрение или испортит впечатления после его окончания. Этого можно избежать если правильно провести pre-sale.
ТОП- 8 проблем, с которыми сталкивается заказчик и исполнитель:
1. Ожидания/реальность заказчика о базовом функционале.
У клиента есть свое внутреннее представление о том, каким функционалом обладает система. И это ожидание часто сильно расходится с реальностью. Например, он думает, что abc xyz отчеты по продажам есть по умолчанию, а это не так. Из-за этого на сдаче проекта заказчика ждет разочарование. Он был уверен, что сможет уже сейчас пользоваться этой функцией и не рассчитывал, что это стоит отдельных денег.
В нашем случае клиент хотел, чтобы менеджеры и логист работали только в Битрикс. В этом плане есть нюанс: необходима автоматизация определенных работ на стороне 1С. Если логист сделал отгрузку на стороне Битрикс, то в 1С должна произвестись проводка этого документа и списание товара. Иначе остатки будут неактуальными. Автоматизация проводки документа - отдельная работа, клиент же считал что CRM сама все проведет и спишет.
Решение: на этапе обсуждения синхронизировать представления о системе и ее работе. Мы узнали, что клиент собирается использовать после внедрения помимо описанных в ТЗ функций. Как по его мнению будут вести себя взаимосвязанные системы?
Подробно рассказываем о базовом функционале человеческим языком. Клиент совершенно не обязан разбираться в тонкостях crm-систем, как и пациент не должен знать, как будет лечить зуб стоматолог. В конце этого процесса мы изображаем укрупненно процессы в нотации BPMN и только после этого переходим к расчетам.
2. Представление заказчика об уровне сложности реализации.
Часто заказчик думает, что реализовать определенную задачу совсем несложно. Например, он выполнял ее в Эксельке. В его представлении CRM - это Эксель с более обширными возможностями, которые настраиваются в несколько кликов.
Решение: объяснить, как это работает и какие действия нужны для реализации задумки. Так ни у кого не будет вопросов о сроках внедрения или цене по функционалу.
3. Несовпадение интересов всех пользователей.
Допустим, клиент просит реализовать функционал, который может привести к изменению каких-то действующих механизмов. Например, мы меняем в 1С поле, которое участвует в бухгалтерском отчете. Из-за чего страдает и злится бухгалтерия: система испортила работу отдела.
Решение: после моделирования бизнес-процессов, всевозможные стейкхолдеры будут как на ладони. Нужно сразу привлечь к обсуждению всех и выявить конфликты интересов.
4. Фокус только на текущих проблемах клиента.
Если подрядчик решает только те вопросы, которые клиент сформулировал в настоящее время, это может оказаться проблемой для заказчика в будущем. У заказчика могут быть стратегические идеи, которые он планирует реализовать на базе этого решения. Если их не учесть на этапе постановки ТЗ, вполне вероятно, что в будущем реализовать задуманное без переделки архитектуры не получится. Будет технически сложно, нерентабельно или неудобно в использовании. А скорее всего - все сразу.
В нашем случае клиент планировал в будущем сделать управленческие дашборды. У него было представление, что Битрикс24 будет по умолчанию генерировать отчеты со всей существующей информацией в 1С. Но в Битриксе не очень удобно пользоваться отчетами, кроме базовых визуализаций. А еще, чтобы подтянуть нужную информацию, потребуется дополнительный обмен между 1С и Битрикс.
Решение: обсуждать все стратегические планы клиента. Мы узнали об этой идее на самом старте и заложили нужный функционал при разработке решения.
Продолжение статьи и еще 4 подводных камня в pre-sale читайте в следующей статье!
Часто сталкиваюсь с тем, что информацию у клиентов приходится вытягивать, порой они сами не представляют, что хотят получить в результате.
Эта проблема решается с помощью подробно составленного ТЗ на основании бизнес процессов заказчика и детального обсуждения задачи со всеми заинтересованным участниками проекта(а не только с руководителем).
А что вы делаете, если у заказчика абсурдные представления о результате работы, которые 100% погубят проект или не выполнимы за его бюджет?
Говорим с заказчиком на понятном ему языке, а не засыпаем терминологией. Визаулизируем все в bpmn. Вникаем в идею заказчика, какую цель он преследует и предложить альтернативное решение, ведь в IT все можно решать несколькими способами.
Как не разбираясь в технической составляющей задачи, определить, что подрядчик квалифицированный?
Обсудить задачу с несколькими подрядчиками, узнать про кейсы, обратить внимание на то, какие вопросы задает исполнитель. Как вариант, заказать технадзор у сторонней компании, мы рекомендуем делать это крупным организациям.
Недавно столкнулся с подрядчиком, который на этапе согласования ТЗ сходу подтвердил, что все наши хотелки выполнимы, а через месяц стало выясняться что "а так сделать нельзя", "а тут у вас тариф неподходящий" и.т.д .
Вы случайно не фрилансера выбрали?) Если исполнитель ознакомился с ТЗ и у него не возникло никаких вопросов, стоит задуматься - понимает ли он какие у вас ожидания от проекта и есть ли у него экспертиза.
Про привлечение к обсуждению по проекту всех - полностью согласен, но как объяснить это заказчику? Чаще всего в обсуждении проекта учавствует 1-2 человека, которые не дают всех деталей.
Попросите заказчика получить подтверждение от заинтересованных лиц на его стороне и сообщить вам об этом) Скорее всего буквально через пару дней он сам будет инициировать общие встречи)