Кейс-статья: ошибки при автоматизации процессов продаж
В этой статье мы расскажем об опыте автоматизации процессов продаж и обслуживания клиентов в универсальном банке со штатом 700 человек.
Для ускорения процессов обслуживания и продаж было решено автоматизировать их. В качестве платформы выбрали программный продукт известного вендора. Проект был рассчитан на пару лет с бюджет несколько миллионов на разработку, не считая стоимости лицензий и технической поддержки. В любом проекте, возникают несколько ошибок, где можно потерять время и деньги.
Ниже приведен краткий список этих ошибок в хронологической последовательности, а дальше мы раскроем их подробнее:
- Не было формализованного процесса продаж и кредитного конвейера.
- Из-за крупности проекта приходилось бесконечно двигать дедлайны
- Не использовались принципы гибкой разработки ПО
- Ошибки выбора платформы ПО.
- Ошибка в выборе принципов синхронизации данных
Не было формализованного процесса продаж и кредитного конвейера. Повторяем избитую истину, что прежде, чем автоматизировать процесс его нужно создать. На момент начала проекта не было формализованного пошагового процесса продаж.
Из-за крупности проекта приходилось бесконечно двигать дедлайны. Это больше управленческий просчёт, который стоил нам кучи времени на внутренние согласования о передвижении сроков, подписания кипы дополнительных соглашений и т.д. Полезное время, которое могли потратить на разработку и внедрение расходовали на бюрократические работы.
Не использовались принципы гибкой разработки ПО. Не смотря на то, что проект очень крупный мы совместно с подрядчиком решили идти по классической схеме разработки – с описанием технического задания, на более чем 200 листах по каждому этапу проекта, и его последующей реализации. Все работы по проекту были разбиты на 4 этапа. Каждый из которых подразумевал свои сроки и бюджеты. В итоге при завершении 1 этапа наш подрядчик приступил к сбору требований по 2 этапу проекта. После приемочного тестированию 1 этапа было принято внутреннее решение в банке, что нам важнее запустить процесс Soft Collection в разработку, чем кредитный конвейер. И мы приостановили работы по этапу 2. В следствие чего нам пришлось покрывать расходы, которые подрядчик понёс по сбору аналитики по этому этапу. Увы и ах, но работа подрядчиком была честно сделана. В результате этой ошибки мы приняли решение создавать кредитный конвейер собственной командой разработчиком с использованием методов гибкой разработки ПО. На тот момент у нас проходил эксперимент по внедрению Scrum в нашем ИТ департаменте и мы с радостью отдали им эту задачу.
Ошибки выбора платформы ПО. Самая фатальная ошибка проекта была связанна с выбором платформы. Сама платформа нас полностью устраивала, оговорюсь, что на момент принятия решения это был лучший вариант для решения наших задач. Но в скором времени вендор вывел на рынок продукт, который в большей степени устраивал наши потребности в автоматизации процессов продаж розничным клиентам. В сожалению переход на это ПО без полного переписывания кода был не возможен! На тот момент был внедрён только 1 этап проекта и было ещё не поздно остановить работы и перейти на новую платформу. Читатели могут сказать, что это очень серьёзный шаг. И это действительно было так, переход на новую платформу позволял в базовой конфигурации использовать инструменты для автоматизации процессов продаж розничного бизнеса, контакт-центра и создать единое рабочее место продажиста без дополнительной кастомизации. В результате работ по переходу на новую платформу пришлось остановить ВСЕ процессы разработки. И кроме финансовых затрат пришлось нести ещё и временные потери…
Ошибка в выборе принципов синхронизации данных. Для обмена данными между CRM и АБС банка были созданы шлюзовые таблицы. Из-за этого просчёта процесс первичного импорта длился невероятно долгое время, в следствии чего, нам пришлось требовать от подрядчика искать способ ускорения заливки данных. Задача была решена, но последующая жизнь с таким механизмом была подобно смерти – при тестовых нагрузках происходили существенные задержки на рабочих местах операционистов, что вызывало у них море негатива. Начинать переход на новое ПО с такими критическими недоработками было не возможно, поэтому команда ИТ приступила к разработке микросервисов для быстрого обмена данными.
Какие выводы можно вынести из нашего опыта внедрения CRM? Наша жизнь в последнее время очень ускорилась, всё очень быстро меняется – продукты, процессы, продажи и т.д. Лучший вариант в подобных проектах «есть слона по кусочкам». Часто мы, как бизнес-заказчики, можем оценить результат только после того, как увидим промежуточный прототип, сможем его пощупать, попробовать на «вкус». Поэтому использование гибких методов разработки существенно упростило бы нашу работу и дало осязаемые результаты в ближайшей перспективе. Но ошибки не совершает только тот, кто ничего не делает, надеюсь, что наш опыт внедрения поможет кому-то и убережёт кого-то от тех ошибок, которые были совершены нашей командой и позволит сберечь ваши деньги.
Если вы желаете обрести новые знания по построению отдела продаж, без ошибок, выгодно и надежно, то пишите нам на почту: info@sales-stream.kz
Результативных вам продаж и самых лояльных клиентов!!!
Черненко Алёна, младший консультант компании Sales-Stream