Крах CRM проекта. Что делать?

19.09.2018

Информация полезна? Поделитесь ею:

Автор: Дэвид Тэйбер


Крах CRM проекта. Что делать?

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

Существует как минимум десяток часто цитируемых отчетов отраслевых аналитиков, в которых рассчитывается вероятность неудачи CRM проекта. Используемые методологии и стандарты различаются, поэтому показатели провала противоречивы – от 18 до 69 процентов.

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

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

5 признаков провала проекта

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

1. Соответствует ли проект хоть на 20% изначальному плану и бюджету? Может график изначально был обречен на провал? А бюджет: реалистичный или нет?

2. Усугубились ли какие-либо проблемы с качеством данных во время выполнения проекта?

Качество данных – это важный фактор, который может повлиять на уровень удовлетворённости пользователей, даже если система работает отлично:

  • Дупликация записей
  • Не тот владелец записи, неправильно назначенные или невидимые записи
  • Точность данных полей, особенно адрес и номер товаров

3. Насколько функциональна система?

  • Для объектов, которые отсутствуют или были проигнорированы: четко ли пользователи сформировали свои цели на начальном этапе проекта?
  • Для объектов, по которым велась работа, но результат неудачный: какая ключевая причина – недостаток понимания, невозможность выполнить или проблемы, связанные с качеством или легкостью использования?
  • Для объектов, результат которых считается удовлетворительным, но присутствуют проблемы с надежностью и согласованностью: в чем суть проблемы – некачественные проект, архитектура и концепция или некачественные внедрение, разработка и развертывание?
  • Работает ли функционал в связи с другими системами (например, телефонная система, хранилище данных, внешние каналы данных или бухгалтерская система)?

4. Оцените вовлеченность и ожидания пользователя

  • Вовлекались ли пользователи в процесс выполнения проекта и насколько сильно? Это ключевой фактор успешного и гибкого управления проектом. Вовлекались ли те пользователи, которые сейчас больше всего жалуются, в процесс выполнения проекта? Понимали ли сотрудники, которые формировали ожидания от CRM проекта, о чем они говорят на самом деле?
  • Убедитесь, что в вашей компании нет сотрудников, которые слышат только то, что хотят услышать. Это убийственное явление позволяет пользователям считать, что все, что воспринимается возможным в функционале системы, становится «стандартом, которого мы ждем».
  • Сформировали ли продавцы CRM продукта ожидания, которые можно достичь только многочисленными работами по кастомизации и сформировали ли ожидания о том, во сколько обойдется привлечение консультантов к их осуществлению?
  • Были ли сотрудники внутри компании, которые пытались помешать проекту? Внедрение CRM системы – это «политическое» решение, всегда найдутся те, кто не желает успеха проекта.

5. Оцените управление проектом

  • Проектом управляла компания пользователя? Если да, был ли это первый крупный проект группы?
  • Тесно ли взаимодействовали с отделом IT?

С учетом всей этой информации вы можете объективно определить, что проект не совсем-то и неудачный. Можно было достичь цели проекта, если бы сроки и бюджет были реалистичны и было бы уделено достаточно внимания. Вечная мудрость Джорджа Карлина гласит: «Некоторые говорят, что стакан на половину пустой, другие говорят, что на половину полный. Лично я считаю, что стакан слишком большой».

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

Давайте посмотрим, почему проект провалился

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

И хотя такие реакции эмоционально и политически удовлетворительные, они, как правило, затратные, т.к. все изменения проходят период притирания и требуют длительного обучения. Но худшее заключается в том, что программа по устранению ошибок следует сценарию, описанному в книге Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы».

Давайте разберем, можем ли мы ответить на ряд сложных вопросов:

  • Была ли изначальная концепция проекта жизнеспособной?
  • Готова ли компания справиться с серьезными усовершенствованиями в автоматизации, технологии и управлении?
  • Были ли задействованы пользователи, когда изменения требовали дисциплины и процесса? Хотели ли они сохранить все, как есть, или предпочитали действовать более ситуативно?
  • Тратили ли руководители время на излишний контроль все и вся?
  • Гибкость и качество данных IT систем и источников данных, с которым должна интегрироваться CRM система, были достаточными?
  • Соотносились ли бюджет и сроки с функциональными ожиданиями?
  • Если ли невысказанные требования? Продолжается ли их выявление?
  • Есть ли хитрые зависимости от других проектов (например, необходимость интеграции с другими приложениями, которые меняются, а интеграция не заложена в бюджет)?
  • Проводил ли кто-то возрастающую оценку стоимости того, сколько на самом деле будет стоить выполнение всех требований? (Моя недавняя любимая ситуация: спецификация на 68 страниц поведения единственного поля CRM системы, без каких-либо оценок бюджета ни одним из трех вендоров, вовлеченных во внедрение)
  • Могли ли заинтересованные участники проекта посвящать ему достаточно времени? Или им не хватало времени для принятия взвешенных решений?
  • Были ли большие промежутки в изначальном плане, когда ничего не происходило?
  • Были ли конкурирующие группы пользователей, где компании имели конфликтующие и противоречащие цели?
  • Было ли настоящее доверие между пользователями и проектной командой?
  • Сомневались ли члены команды в мотивации или компетенции друг друга?
  • Истолковывались ли вопросы иногда как проблемы или даже угрозы?
  • Были ли перепады настроения у некоторых людей или угрозы покинуть проект?
  • Были ли люди, которые просто не могли работать друг с другом эффективно?
  • Были ли какие-либо угрозы или подачи исков?

Если вы дали ответ «Да» на эти сложные вопросы, проект по устранению ошибок уже заражен. Имеет смысл позвать консультанта по управлению или специалиста по развитию компании перед тем, как запускать новый IT-проект на полную мощность.

Помощь во внедрении CRM системы

Источник: cio.com

При копировании материалов данной статьи обязательно указывайте активную ссылку на сайт-источник www.integros.com.ua. Все права на перевод принадлежат компании ИНТЕГРОС.


Присоединяйтесь к нам:

Другие материалы по этой теме:


Присоединяйтесь к нам на Linkedin      Присоединяйтесь к нам на Facebook


Вы интересуетесь, кому и зачем нужна CRM-система? Как выбрать CRM-систему и какие они бывают? Ответы на эти и другие вопросы можно найти в статьях Николая Булавы на нашем сайте

Логин

Пароль

Забыли свой пароль?

Запомнить меня

Регистрация