Сколько стоит внедрение Битрикс24? Минимизируем риски при выборе интегратора

Давайте поговорим о такой важной теме, как оценка стоимости внедрения и разработки. Узнайте о рисках заказчика и исполнителя, и как Пинкит эти риски минимизирует.

Когда клиент приходит к интегратору с задачей внедрения CRM, он редко подозревает, что оценка — это не дело пяти минут, а долгая и сложная процедура.

Инженер по внедрению или разработчик не может дать адекватную оценку, не потратив своё время на изучение задания, чтение документации, проверку API-методов сервисов (если речь идёт об интеграции).

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

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

В первом случае риски ложатся на интегратора. Чтобы снять эти риски мы в Пинол полностью переработали систему оценки.

Как мы делали раньше?

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

К слову, подход давно устаревший, и вот почему:

1.1 Многих клиентов бриф пугает, они не готовы тратить своё время на то, чтобы вникать в вопросы и отвечать на них. Вопросы бывают непонятны, и заполнение брифа может затянуться, что плохо для обеих сторон.

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

Так мы поняли, что бриф скорее мешает, а не помогает, и пришли к другой модели оценки.

Новая модель Пинол для оценки задачи внедрения

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

О чем говорим на встрече? Цель встречи — не только собрать клиентские требования (то, как он видит автоматизацию) но также и озвучить технические возможности Пинкит. Мы лучше знаем нашу платформу и когда клиент рассказывает, как в компании выстроены базовые бизнес-процессы, то сами предлагаем интеграции именно под его бизнес.

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

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

Приведём конкретный пример.

Клиент пришел к нам впервые год назад с задачей сделать интеграцию между ПланФакт и Битрикс24. Мы проговорили задачу, озвучили ему условия и он ушел думать... Прошел год, и клиент вернулся к нам с той же задачей. Весь этот год сотрудники клиента вносили данные вручную, а бизнес считал, что расход на эту разработку "TOO MUCH".

Клиенту необходимо, чтобы приходы из ПланФакт автоматически распределялись между контактами, компаниями и универсальными списками в Битрикс24. Звучит как одна интеграция, но на самом деле это три интеграции:

1) по выгрузке из контактов,

2) по выгрузке из компаний,

3) по выгрузке из универсальных списков.

Причем, запуск второй и третьей интеграции будет проходить после того, как отработала первая интеграция. Внутри каждой интеграции будут свои условия, какие поля берутся для выгрузки в Битрикс24.

Дополнительно клиенту нужно, чтобы процесс работал в обратную сторону (из Битрикс24 планируемые финансовые операции попадали в нужные поля ПланФакт из контактов, компаний и универсальных списков) — это еще плюс три интеграции.

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

Тут же на встрече после определения требований мы говорим, как можем реализовать задачу клиента, и определяем, что можно сделать уже на первой неделе сотрудничества в рамках первого спринта. Как вы помните, благодаря тому, что у нас есть Пинкит, никаких подготовительных работ (например, разворачивания серверов) не требуется, мы сразу настраиваем интеграцию под клиента. При этом сама платформа Пинкит клиенту обойдется в копейки - сейчас по акции ее можно купить на год по символической стоимости. В феврале у нас действует акция «Романтичный февраль» — обычную стоимость любого тарифа Пинкит мы делим на 14:

Таким образом, клиенту не придется платить сразу за всю разработку.

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

Перейдём к другим рискам.

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

2.1 Никогда не берём в работу незнакомую задачу. Если инженер не настраивал аналогичный функционал, не знает, в каком направлении двигаться и не имеет четко поставленной задачи — задача в спринт не берётся.

2.2 Никогда не работаем по каскаду. Только чёткий спринт с чёткой оценкой и приемкой.

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

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

А что вы думаете о нашем подходе?