Почему проваливаются проекты внедрения CRM

CRM "не встаёт" в тех компаниях, где пробуют "пропустить" важные этапы эволюции культуры.

На всякий случай и для тех, кто не в курсе, заглянем в Википедию и уточним терминологический словарь. Система управления взаимоотношениями с клиентами (CRM, CRM-система, сокращение от англ. Customer Relationship Management) — прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процессов и последующего анализа результатов.

Как мне кажется, оптимальная эволюция при внедрении CRM — это следующая цепочка:

Листок бумаги — файл(ы) Excel — CRM-система — решения класса ERP — решения класса BI.

Возьмём для примера ведение клиента по сделке:

• Делаем бумажные "Рабочие журналы" и пусть поработают 2–4 недели в них. На бумаге — проще, нагляднее и понятнее. Ведь первая задача — освоить и закрепить порядок, — здесь выполнима гораздо легче. Посмотрите, какой% руководителей до сих пор пользуется бумажными ежедневниками? При том, что есть десятки систем контроля и планирования поручений…
• Смещаем всё это на следующий месяц в типовой файл Excel. Сотрудники осваивают электронную фиксацию всех шагов в течение периода 2–3 недели. И — о, ужас! — в части компаний можно остановиться на этом… Если у вас 3–4 сделки в месяц, не факт, что вам нужна полноценная CRM. В разработку и функционал электронных таблиц Microsoft вкладывала сотни миллионов долларов. Многие CRM системы используют Excel как механизмы экспорта/импорта. Вы уже исчерпали этот потенциал?
• А теперь можно "пересаживать" ваших сотрудников в сделки CRM. Что будет, если всех сразу забросить в CRM? Возникает слишком большое сопротивление и порция неперевариваемого объёма информации: надо менять привычки (сделал-отпишись в CRM), привыкать к новому интерфейсу, осваивать культуру ведения клиента по этапам сделки, распаковывать все обращения в новую карточку клиента и т.п. В моей версии выше, мы это делаем поэтапно и вместе с тем достаточно быстро.

С другой стороны, CRM сегодня — уже давно не венец совершенства.

Надо ускоряться. Есть ERP (Enterprise Resource Planning), BI (Business intelligence) — решения. Проснитесь, коллега: в соцсетях вовсю орудуют чат-боты, нейронные сети определяют предпочтения и рисуют "портреты" ваших идеальных клиентов.

Пора догонять, вот только стоит разобраться как. А то ведь и дров можно наломать.

Общаюсь с представителем среднего бизнеса, затронули тему CRM. Вижу, взгляд потух: "Мы уже это пробовали… В прошлом году отдали в районе 8 млн. рублей. И ничего не получилось". Потому что начали не с того. Когда меня учили автоматизации промышленных процессов (в ВУЗе), я запомнил твёрдое правило: прежде чем автоматизировать, объект (автоматизации) должен быть хорошо механизирован. Попробую перевести на язык бизнеса.

Прежде чем автоматизировать продажи (ставить CRM), отладьте и формализуйте (опишите) механику этих продаж:

• Какую механику привлечения, развития лидов и продаж вы используете? В какой последовательности?
• Что будет результатом на выходе каждого шага? Подготовленное КП (коммерческое предложение) — когда его кто-то сделал и положил к себе на стол? Или, может, когда это КП согласовано в компании со всеми участниками и готово к передаче клиенту? А быть может, когда клиент ответил: "Мне это подходит" или "Совсем не интересно!"?
• Как измеряем эффективность каждой коммерческой активности? Сейчас очень модно быть в соцсетях и заниматься SMM. Возьмём Facebook: только ленивый что-то там не пробовал делать. А как измеряете? Ведь там целая панель для бизнеса: вовлечённость, охват и т.п.
• Какие этапы проходит у вас типовая сделка от статуса "лид" до состояния "покупатель"? Заявка на сайте — телефонный звонок — встреча-знакомство — подготовка КП — финальные переговоры — подписание договора — оплата аванса и т.п.
• Сколько у вас типов типовых структур сделок? У меня, например, в консалтинговом бизнесе, — 4. В сервисной компании — 3, в ноябре добавилась 4-ая "франшиза".
• Какой промежуток времени сделка может "висеть" в каждом этапе? Например, поступила заявка на сайт. Через сколько стоит перезвонить и уточнить? У лидеров этот показатель доходит до десятков секунд, а заявка попадает на горячую линию. И не случайно: ведь пока вы собираетесь, клиент просто набирает номер вашего конкурента… А вы сливаете рекламный бюджет.
• Кто и за какой шаг должен отвечать? Где кончается ответственность маркетолога, а где — начинается "зона" менеджера по продажам в нашем примере выше.

Всё это стоит описать и узаконить ДО внедрения CRM. Ведь если автоматизировать "бардак", на выходе получите "автоматизированный бардак". И если в первом случае вы как-то успеваете поправлять сбои руками, то скорость и последствия при автоматизации могут уже этого не позволить.

CRM ускоряет процессы, снижает человеческий фактор и упрощает рутину

Но сама по себе не наводит порядок в ваших бизнес-процессах (привлечения, продаж, выполнения обязательств). Это стоит сделать вам ещё до того, как вы задумались о внедрении. И снова — хорошая новость: для коллектива продавцов в 5–20 человек этот путь можно успешно пройти за 45–60 дней. А дальше (при необходимости) — быстро распространить успешный опыт на всю компанию.

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

Отчет, который в 2014 году выпустила компания The Standish Group, предоставляет нам следующие данные для анализа:

• Из 8380 проектов по разработке и внедрению программных продуктов успеха добились лишь 16,2%
• В категорию «спорные» проекты попало 52,7%
• В категории провальных проектов (от реализации которых отказались) оказалось 31,1%

Для исследования все ИТ-проекты в этом отчете были разделены на три группы:

1. «Успешные проекты» — проект завершен в срок, в бюджет, реализованы все возможности и функции, которые первоначально были запланированы.

2. «Спорные проекты» — проект завершен и работает, но плановый бюджет или срок был превышен, либо реализованы не все функции, которые первоначально были запланированы.

3. «Провальные проекты» — проект был отменен или так и не дошел до финиша.

Как часто превышается бюджет ИТ-проекта и на сколько % от планового значения? На этот вопрос отчет дает следующий ответ:

Как видим, почти в четверти проектов из тех, что попали в группу спорных или провальных, бюджет был превышен более чем в 2 раза (свыше 100% от планового).

А теперь посмотрим, как сильно отклоняются от планового срока ИТ-проекты:

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

Почти в половине проектов (47,8%), попавших в группу спорных или в группу провальных, сроки были сорваны более чем на 100% от плановых.

Теперь узнаем, какая доля от запланированного функционала программного продукта была реализована в проекте. Эта цифра имеет смысл только для категории спорных проектов, т.к неудачные проекты так и не дошли до логического завершения:

В группе спорных проектов более четверти из них были завершены с получением лишь 25% – 49% от первоначально запланированных функций программного продукта. В отчете также есть данные о том, что в среднем был реализован 61% от первоначально запланированных функций для данной категории проектов.

В чем причины провалов проектов

Мне интересно было узнать мнение руководителей ИТ-проектов относительно причин успеха их проектов. Ниже перечислены факторы успеха и доля респондентов, участвовавших в этом опросе The Standish Group:

Вовлечение пользователей — 15,9%
Поддержка высшего руководства — 13,9%
Ясное изложение требований — 13,0%
Правильное планирование — 9,6%
Реалистичные ожидания — 8,2%
Небольшие этапы проекта — 7,7%
Компетентный персонал — 7,2%
Ownership — 5,3%
Ясное видение и цели — 2,9%
Трудолюбивый, сфокусированный персонал — 2,4%
Другое — 13,9%

В аналогичном отчете The Standish Group за 2015 год в списке появились новые факторы успеха ИТ-проекта, которых не было в списке за 2014 год, например:

Эмоциональная зрелость — совокупность основных характеристик поведения людей при совместной работе.

Использование Agile-процесса — обозначает то, что команда и владелец продукта умеют работать по одному из Agile подходов.

Как видим, в 2015 году респонденты в явном виде указали на то, что использование Agile-подхода для ИТ-проекта стало одним из факторов его успеха.

Самое интересное при изучении статистики проектов, на мой взгляд, — это понимание причин того, почему проект не стал успешным.

По мнению респондентов отчета список этих причин для спорных проектов следующий:

Отсутствие вовлечения пользователей — 12,8%
Неполные требования и спецификации — 12.3%
Изменение требований — 11,8%
Отсутствие поддержки высшего руководства — 7,5%
Технологическая некомпетентность — 7,0%
Нехватка ресурсов — 6,4%
Нереальные ожидания — 5,9%
Нечеткие цели — 5,3%
Нереальные плановые сроки — 4,3%
Появление новой технологии — 3,7%
Другое — 23,0%

Понятное дело, что в исследовании The Standish Group не участвовали ИТ-проекты компаний-заказчиков из Беларуси. Но я, имея опыт руководства проектами автоматизации бизнеса белорусских компаний, могу отметить, что ключевые факторы провала таких проектов в нашей стране во многом совпадают с приведенным выше списком.

Я сформулировал собственный список причин провала проектов автоматизации бизнеса (без претензии на его истинность):

1. Нечеткие цели ИТ-проектов. Это проявляется на уровне самих формулировок целей проекта, к примеру, целью ИТ-проекта объявляют такую: «Внедрить ERP-систему». У меня много вопросов к этой формулировке цели:

• Что мы понимаем под ERP?
• Как мы поймем, что мы внедрили эту систему?
• Какова бизнес-выгода от внедрения?
• За какой период будем измерять бизнес-выгоду?

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

2. Отсутствие со стороны компании-заказчика проекта команды проекта. Я имею в виду команду, которая имеет полномочия и ответственность принимать решения по содержанию проекта.

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

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

4. Нереальные плановые сроки. А как их оценить более-менее реально, если требования на старте ИТ-проекта изложены на уровне бизнес-требований или ожиданий? Вот и ошибаются оценщики в разы, причем в сторону недооценки масштаба проекта.

5. Изменение требований. Проявляется этот фактор в том, что на стороне заказчика хотят сразу сделать идеальный продукт и не принимают позицию, связанную с тем, что пользователям все равно что-то не понравится в программном продукте, поэтому важно максимально быстро запустить ключевой функционал. А потом потихоньку дорабатывать «бантики». По статистике, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда.

6. Отсутствие поддержки высшего руководства компании-заказчика. Я встречал ситуации, когда при внедрении ERP-систем высшие руководители компании-заказчика даже не были представлены команде исполнителя. О каком вовлечении в проект или поддержке проекта руководством со стороны заказчика может идти речь?

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

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

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

факты и выводы

В подтверждении своих слов привожу далее статистику (что может быть красноречивее цифр?) по провалам проектов.

По данным отчета The Standish Group за 2015 год (в исследуемую выборку попало около 50 тысяч проектов по всему миру) около 70% проектов закончились провалом или спорно.

По данным отчета The Standish Group за 2014 год только в США ежегодно тратится 250 миллиардов долларов на разработку программного обеспечения, реализуется около 175 тысяч проектов. Многие из этих проектов заканчиваются провалом или спорно.

Ниже привожу частичные данные по исследованию 8380 проектов из указанного выше отчета:

• около 83% проектов закончились провалом или спорно;
• только 15,5 % проектов уложились или не превысили бюджет более, чем на 20%;
• в 25,2% проектов бюджет был превышен более, чем в 2 раза;
• только 13,9 % проектов уложились или не превысили сроки более, чем на 20%;
• в 47,8% проектов сроки были превышены более чем в два раза;
• только в 7,3% проектов был реализован весь запланированный функционал;
• в 49% проектов функционал был реализован в пределах 25-74%.

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

Требования – это результат бизнес-анализа, стоимость ошибок которого исчисляется сотнями миллиардов долларов в год в мировом масштабе [4].

Коэффициенты роста стоимости ошибок в процессе разработки требований приведены ниже [3]:

Данные таблицы обработаны и адаптированы автором первоисточника [3] из большого количества работ.

Например, стоимость исправления ошибки, равная 1000 $ на этапе разработки требований, может вырасти до 10000-100000 $ на этапе эксплуатации.

Очевидно, что компаниям необходимо улучшать “производственные” процессы, как и процессы бизнес-анализа, а также обратить пристальное внимание на основные причины провалов проектов – плохие требования, сомнительные попытки компенсировать ошибки этапа бизнес-анализа на последующих этапах, невнимательное отношение к проблемам и потребностям бизнеса заказчиков и причастных/заинтересованных лиц – т.е. всему тому, что ассоциируется непосредственно с бизнес-анализом.