Сколько стоит внедрение Битрикс24? Минимизируем риски при выборе интегратора
Давайте поговорим о такой важной теме, как оценка стоимости внедрения и разработки. Узнайте о рисках заказчика и исполнителя, и как Пинкит эти риски минимизирует.
С чего начинается внедрение CRM?
Когда клиент приходит к интегратору с задачей внедрения CRM, он редко подозревает, что оценка — это не дело пяти минут, а долгая и сложная процедура.
Инженер по внедрению или разработчик не может дать адекватную оценку, не потратив своё время на изучение задания, чтение документации, проверку API-методов сервисов (если речь идёт об интеграции).
Как вы понимаете, для компании исполнителя это расходы. А в случае, если клиент просто бродит по рынку, выясняя, у кого дешевле, эти расходы не возмещаются из маржи по проекту заказчика.
Итак, первый риск — это неоправданные расходы на оценку. Второй риск возникает в ситуации, если клиент оценку принимает, и разработчик приступает к реализации проекта, но по каким-то причинам (вы прекрасно знаете, каким, останавливаться на этом не будем) итоговая стоимость работ выходит за оценку. Все это приводит к проблемам во взаимодействии клиента и интегратора, в конечном счёте, они теряют доверие друг к другу и вряд ли будут сотрудничать в дальнейшем.
1. Как избежать неоправданных расходов на оценку задач?
В первом случае риски ложатся на интегратора. Чтобы снять эти риски мы в Пинол полностью переработали систему оценки.
Как мы делали раньше?
У нас был бриф — краткий перечень вопросов для клиента, ответы на которые должны помочь оценивающему разработчику понять клиентские требования и дать смету для оценки.
К слову, подход давно устаревший, и вот почему:
1.1 Многих клиентов бриф пугает, они не готовы тратить своё время на то, чтобы вникать в вопросы и отвечать на них. Вопросы бывают непонятны, и заполнение брифа может затянуться, что плохо для обеих сторон.
1.2 Клиент сам не знает, чего хочет, не имеет полной и доступной информации о технических возможностях интегратора, не понимает, как должен работать нужный ему функционал. В этом случае сбор требований - как испорченный телефон, даже если клиент даст вам бриф, этот документ будет бесполезен.
Если бы я сам знал, как все должно работать и как это настроить, я бы к вам не обращался.
Так мы поняли, что бриф скорее мешает, а не помогает, и пришли к другой модели оценки.
Новая модель Пинол для оценки задачи внедрения
Теперь мы не выдаём бриф, а сразу выводим клиента на встречу. Клиент голосом озвучивает, что хотел бы получить на выходе и мы с аналитиками проговариваем все нюансы, чтобы и не оставить никаких упущенных моментов и двойственных трактовок. Мы заботимся о клиенте, но также забоимся и о себе.
О чем говорим на встрече? Цель встречи — не только собрать клиентские требования (то, как он видит автоматизацию) но также и озвучить технические возможности Пинкит. Мы лучше знаем нашу платформу и когда клиент рассказывает, как в компании выстроены базовые бизнес-процессы, то сами предлагаем интеграции именно под его бизнес.
Конечно, нет гарантий, что после встречи клиент останется с нами. Но вероятность, что сделка все же состоится намного выше, чем если бы мы просто выслали ему бриф для заполнения...
На встрече мы показываем, как работает Пинкит и демонстрируем уже работающие, успешные кейсы. У нас огромный опыт в настройке интеграций и на все типичные запросы клиента мы знаем ответы (либо знаем, где их найти). Встреча позволяет нам легче и точнее идентифицировать клиента, чтобы понять, будем мы сотрудничать или нет.
Приведём конкретный пример.
Клиент пришел к нам впервые год назад с задачей сделать интеграцию между ПланФакт и Битрикс24. Мы проговорили задачу, озвучили ему условия и он ушел думать... Прошел год, и клиент вернулся к нам с той же задачей. Весь этот год сотрудники клиента вносили данные вручную, а бизнес считал, что расход на эту разработку "TOO MUCH".
Клиенту необходимо, чтобы приходы из ПланФакт автоматически распределялись между контактами, компаниями и универсальными списками в Битрикс24. Звучит как одна интеграция, но на самом деле это три интеграции:
1) по выгрузке из контактов,
2) по выгрузке из компаний,
3) по выгрузке из универсальных списков.
Причем, запуск второй и третьей интеграции будет проходить после того, как отработала первая интеграция. Внутри каждой интеграции будут свои условия, какие поля берутся для выгрузки в Битрикс24.
Дополнительно клиенту нужно, чтобы процесс работал в обратную сторону (из Битрикс24 планируемые финансовые операции попадали в нужные поля ПланФакт из контактов, компаний и универсальных списков) — это еще плюс три интеграции.
Таким образом, клиент даже не подозревал, что его запрос такой объемный. Он думал, что задача банальная, а в итоге задание получилось намного масштабнее и конечная стоимость также выросла. На этом этапе клиенты начинают сомневаться…
Тут же на встрече после определения требований мы говорим, как можем реализовать задачу клиента, и определяем, что можно сделать уже на первой неделе сотрудничества в рамках первого спринта. Как вы помните, благодаря тому, что у нас есть Пинкит, никаких подготовительных работ (например, разворачивания серверов) не требуется, мы сразу настраиваем интеграцию под клиента. При этом сама платформа Пинкит клиенту обойдется в копейки - сейчас по акции ее можно купить на год по символической стоимости. В феврале у нас действует акция «Романтичный февраль» — обычную стоимость любого тарифа Пинкит мы делим на 14:
Таким образом, клиенту не придется платить сразу за всю разработку.
Работаем спринтами. На каждом спринте выполняется определенная задача, проверяется и принимается клиентом, только тогда и оплачивается. Клиент сам выбирает, сколько итераций-спринтов мы проведём, исходя из своего бюджета и потребностей. Звучит здорово, верно?
Перейдём к другим рискам.
2. Как избежать некорректной оценки?
На помощь приходят чёткие регламенты. Наши инженеры имеют большой опыт в настройке интеграций между сервисами, у которых есть API. Таким образом, ситуация, в которой оценка окажется неверной, случается редко. Вероятность ошибки в оценке есть всегда — никто не может видеть будущее и учитывать все возможные проблемы на динамичном рынке. Чтобы минимизировать такую вероятность, мы:
2.1 Никогда не берём в работу незнакомую задачу. Если инженер не настраивал аналогичный функционал, не знает, в каком направлении двигаться и не имеет четко поставленной задачи — задача в спринт не берётся.
2.2 Никогда не работаем по каскаду. Только чёткий спринт с чёткой оценкой и приемкой.
Итог
Таким образом, если двигаться по модели спринта, все участники процесса оказываются в выигрыше — клиенту не нужно долго ждать результат, границы задачи определены и сроки согласованы. Разработчик четко понимает, что от него требуется и выполняет работы по согласованному графику.
Да, даже при таком подходе что-то может пойти не так и сумма может измениться от начальной оценки. Бывают технические нюансы и иногда API-методы сервисов, которые нужно интегрировать, не отвечают описанным требованиям и приходится тратить больше усилий для согласования всех непредвиденных проблем. Но все эти моменты подлежат строгому согласованию.
А что вы думаете о нашем подходе?