Бизнес интегратора CRM-систем: почему Пинкит - это уход от каскадной модели внедрения к Scrum

В статье расскажем, как мы перестроили модель внедрения CRM от каскадной к Scrum, какие выгоды это дает, как избежать ошибок при оценке, к чему тут наш продукт Пинкит в связке с Битрикс24/amoCRM и почему нужно экспериментировать, чтобы быть в плюсе.

1.1. Качество и скорость обработки запросов. Проблемы при внедрении CRM-систем начинаются уже в момент получения запроса от клиента: человек хочет получить квалифицированную консультацию эксперта сразу при первом звонке (так сказать, во входящем канале). Задача интегратора, который хочет избежать негативных отзывов клиентов — максимально быстро обрабатывать все обращения, поступившие за день. Делать это нужно исключительно день в день. Но ставить на первую линию эксперта, который будет прорабатывать все запросы клиентов день в день, нет ни технической возможности, ни здравого смысла.

1.2. Проблемы при оценке. Здесь очень важно правильно определить, какие запросы клиентов мы можем брать в работу и ставить в оценку, а какие считаем не целевыми и как об этом правильно сказать клиенту.

1.3. Ошибки при выполнении задач. Зачастую инженеры на рынке считают конверсию от ошибки к общему числу отработанных проектов. Но ошибки инженера дорого обходятся компании: мы не только можем потерять клиента. Выработка инженера по решению задачи, которая не была принята клиентом, оплачивается из бюджета компании. Поэтому для нас ключевой проблемой на начальном этапе является работа с инженерной командой. Мы объясняем, что в оценку нужно брать только те задачи, по которым у них есть опыт решения. Если не знаешь, как реализовать то, что хочет клиент — отказ от сделки.

1.4. Конкуренция. Сейчас на рынке существует огромное множество интеграторов, они предлагают разную стоимость настройки и их услуги тяжело регулировать качеством.

Как справиться с этими сложностями? На помощь приходят регламенты!

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

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

Кроме регламентов, считаем, что работа по задаче не должна затягиваться. Разбиваем задачу на недельные спринты и дальше работаем по методологии Scrum. Инженер приступает к работе только тогда, когда он понимает, как ее сделать и уверен, что закончит в срок.

Если с аналогичными задачами мы не сталкивались ранее, у нас не реализован требуемый функционал, нужно время на изучение, есть сомнения в алгоритме выполнения — задача в спринт НЕ БЕРЕТСЯ. Так мы обезопасим и себя, и клиента от сырого продукта и огромных нецелесообразных затрат на разработку. Если задача дискретная (четко определенная) — она хорошо выполняется в конкретном недельном спринте.

2.1. Другой клиент обратился к нам с каскадной задачей — внедрить Битрикс24 и настроить ВСЕ. Каскадный метод, или "водопад", обычно реализуется с помощью таблицы или диаграммы, где фиксируются этапы внедрения, например, анализ, проектирование, развитие, тестирование, внедрение, а также их оценочная стоимость. Например, вот запрос:

Это отличный пример, как делать НЕЛЬЗЯ. При каскадном методе внедрения CRM-системы вы увидите все проблемы только в конце проекта, в итоге у вас не останется времени на ликвидацию их последствий. Основная трудность в том, что, пока у вас нет технического задания, все трудозатраты рассчитываются очень приблизительно. Касаемо ТЗ, все в курсе, что оценивать и внедрять по ТЗ должна только та компания, которая занималась написанием ТЗ. Также здесь есть реальный вариант получить на выходе нежизнеспособный продукт из-за того, что в разработке всегда есть подводные камни и неописанные моменты в API. Оставлять все будущие проблемы на финальный этап тестирования — абсолютно неудачный выбор.

2.2. Гибкий метод внедрения CRM в модели Scrum — это отличная альтернатива каскадному методу внедрения CRM. Он определяет цели и конкретно осязаемые задачи не на все время разработки, а на короткий недельный спринт. Благодаря этому команда инженеров быстрее дожимает проект и с каждым последующим спринтом он приводится в соответствие с клиентскими ожиданиями. В конце каждого недельного спринта демонстрируется протестированный работающий сервис, происходит приемка работ клиентом и далее набираются задачи в новый спринт — по настройкам и доработкам.

В этой системе есть и другой приятный бонус: за спринт интегратор и клиент успевают присмотреться друг к другу, и там, где у клиента и его рабочей команды уже есть реальная польза в рамках отработанного спринта, уровень коммуникации интегратора и команды клиента приходит на уровень ЕДИНОЙ команды.

Знаете, что представляет собой внедрение Битрикс24 или amoCRM? По нашему опыту в 70% случаев типовой запрос клиента — это настройка CRM в связке с какими-то сервисами (телефония, рассылки, аналитика и банкинг).

Далее мы с клиентом проводим встречу и обсуждаем, что ему нужно в первую очередь (и на что у него есть деньги). Здесь возникает ключевая проблема: кто определяет, что должно делаться в первую, вторую и третью очередь?

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

Поэтому самая важная часть спринта — это настройка интеграции в Пинкит. На шаге 2 прописываются инструменты:

Такой подход позволяет нам перевести клиента из пространной модели «внедрить и настроить Битрикс24» (чистый каскад), на четкую и понятную модель: «настроить выгрузку заказов из Яндекс.Маркет в Битрикс24» по спринту.

При таком подходе нам легче дать точную оценку. Например, «на настройку интеграции необходимо 5 часов». Клиенту это воспринять намного проще, когда он знает, что спустя это время он фактически получит рабочий функционал и сможет сразу же поставить сотрудников на обработку заказов, прилетающих из Яндекс.Маркет.

А "улучшайзинг" воронки поступающих сделок Битрикс24/amoCRM мы сможем прикрутить в следующем спринте после того, как обучим сотрудников клиента самостоятельно менять стадию сделки.

Клиент часто просит обозначить «вилку на внедрение Битрикс24». Это типовой каскадный вопрос, однозначного ответа на который нет. Все зависит от того, что клиент хочет получить на выходе, чего он ожидает от CRM. Мы отвечаем своим клиентам так:

«Давайте сейчас определимся с теми задачами, которые нужно реализовать прямо сейчас и они понятны. Сделаем их в рамках недельного спринта, а дальше определим новые задачи в спринт на новой встрече»

Такая модель позволяет:

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

4.1. Если вы выбираете партнёра-интегратора, то работайте спринтами. Так вы быстро поймёте, ваш это вариант или нет.

4.2. Если вы пользуетесь сторонними сервисами, вам понадобится интеграция этих сервисов с Битрикс24. Начните внедрение CRM с интеграции данных сервисов для того, чтобы потом не оказаться в ситуации, что бизнес-процесс не работает из-за того, что у вашего сервиса нет API или нужного API-метода, или тариф сервиса, которым вы пользуетесь, не дает доступа к API.

4.3. Покупайте Пинкит.