Как стать автором
Обновить
2
0
Павел Баранчиков @Pavel_Baranchikov

CRM-интегратор

Отправить сообщение

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

Не совсем так. В начале статьи речь о том, что топ менеджера делают ответственным за внедрение, не привлекая интегратора вообще. Далее в статье говорится о том, что помимо интегратора обязательно должен быть руководитель проекта по внедрению со стороны Заказчика и он должен обладать достаточными полномочиями для привлечения к проекту нужных сотрудников (в особенности на этапе аудита бизнес-процессов).

Описанный подход не понравился. Везде виноват заказчик, которому надо 20 раз объяснить, написать тз, потом заплатить за аудит, быть 24/7 на связи, отвечая на все вопросы, вовлекаясь в каждую мелочь и выделить под это топ менеджера. Заказчик вообще то не специалист, поэтому и нанимает интегратора.

Вы сейчас в точности описали Заблуждение №3 из статьи)

Давайте разделим ответственность Заказчика и Исполнителя в рамках проекта по внедрению CRM. Исполнитель отвечает за сбор информации, аналитику, проектирование интеграций, написание ТЗ, настройку CRM, обучение, дальнейшую поддержку. Заказчик же отвечает за постановку задачи, организацию процесса предоставления необходимой Исполнителю информации и приемку работ. Как видите, их ответственность никак не пересекается. Но все ошибки заказчика, описанные в данной статье, крутятся вокруг его зон ответственности. Зачастую это неочевидно для заказчика. Для этого и написана статья.

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

Также смутили пункты про излишнее количество доработок базового функционала и дальнейшее развитие системы. Похоже на постоянное "доение" клиента - вот мы вам mvp сделали, теперь пара доработок и еще пара..., и будет работать как надо... К этому моменту выложены существенные деньги и клиенту сложно соскочить, осознав, что вляпался в цепкие лапы интегратора.

А теперь давайте посмотрим на это с другой стороны. Излишние доработки системы до ее запуска сильно увеличивают бюджет и сроки реализации проекта. Мы рекомендуем итерационный подход как раз для экономии времени и бюджета. Потратив минимум средств на MVP вы уже сможете использовать 70-80% необходимого вам функционала. А далее поэтапное запускать второстепенный функционал.

Что касается поддержки и развития, как правило, когда Заказчик начинает понимать логику работы системы и видеть преимущества от ее использования, он сам инициирует перенос все новых бизнес-процессов в свое новое ПО. Также важно заметить, что правильно спроектированная и настроенная автоматизация экономит кратно больше средств, чем в нее вкладывается. К примеру, нашей CRM уже более 10 лет и мы постоянно придумываем варианты оптимизации наших процессов.

Никто не любит изменений, если есть возможность их саботировать, большинство именно этим и будет заниматься) Если "продать" сотрудникам идею CRM через объяснение преимуществ не удается, то мы рекомендуем завязывать KPI на показателях CRM. То есть зп будет зависеть напрямую от сделок, счетов, задач в CRM. И сотруднику прийдется все туда заводить и держать на нужных стадиях. Также помогают еженедельные планерки, которые проводятся с открытым на экране монитора кан-баном сделок в разрезе конкретного сотрудника. К 3ей неделе все начинают прибирать свою CRM перед планеркой)

Такова идея статьи. Мы все привыкли винить Исполнителя. И зачастую так оно и есть. Неопытность, низкая квалификация, некорректно выстроенные процессы внутри компании исполнителя, не грамотно выстроенный процесс внедрения - все это приводит к печальным последствиям для проекта по внедрению CRM. Но это достаточно очевидно. В статье же я постарался затронуть факторы, на которые Заказчик часто не обращает внимания, а исполнитель не всегда может на них повлиять. Однако эти факторы могут оказывать сильное негативное влияние на проект, даже если с исполнителем все хорошо.

Насчёт №7 не вполне согласен - думаю, базовый функционал CRM без доработок вряд ли удовлетворит более-менее крупную компанию. Тут вопрос - что считать "огромным количеством" доработок.

Вы правы, чем крупнее бизнес, тем (как правило) более формализованы процессы, компания не готова подстраиваться под логику внешней системы, требуется подстроить систему под компанию. Микробизнес или, к примеру, новый стартап, легко может подстроиться под систему.

Речь в данном пункте не о том, чтобы не дорабатывать систему, а о том, чтобы это не влияло коренным образом на сроки ее первичного запуска, то есть сначала запустить MVP с наиболее важными процессами, следующими итерациями запускать сложную кастомизацию и интеграции. Мы неоднократно были участниками проектов, когда из-за не сильно значимого функционала раздувался бюджет и срок реализации проекта, при этом 90% значимого функционала была готова, но не могла быть запущена.

решение о составе функционала при внедрении или замене существующей CRM системы принимают в 99% случаев финансовый менеджмент, который знает, какие отчёты, графики, и т.п. нужны для директората, финансов, маркетинга, закупок, но - увы! - часто не считает нужным погрузится в существующие процессы сервисного/технического отдела

Полностью согласен, на этапе аудита очень важно присутствие реальных участников процессов, ключевых сотрудников отделов (не руководителей). Неоднократно сталкивались с тем, что видение процесса руководителем отдела и сотрудником отдела разнятся и у сотрудника оно зачастую глубже, он может осветить проблемы, о которых руководитель не в курсе.

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Зарегистрирован
Активность