Все современные компании — в той или иной степени технологические. Каждая из них использует IT-инструменты — от пары-тройки в малом бизнесе, до десятков — в крупном. Каждый из них — отдельное программное решение или чащу — независимый сервис.В общей системе, решающей задачи бизнеса такие сервисы — как кубики Лего. Выходит, что всякий бизнес-процесс проходит через несколько таких сервисов-кубиков. Часть из них уже собрана — интегрирована между собой, как например форма сбора заявок на вашем сайте и CRM. Но при этом для каждого случая есть как минимум 2−3 способа построения связей.

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

Не всё ещё интегрировано

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

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

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

Что делать?

Большинство сервисов и приложений можно подключать друг к другу, используя API (Application Programming Interface — программный интерфейс приложения). Это специальный протокол, позволяющий программам общаться друг с другом, у каждой из них он свой.

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

Стоит их использование относительно недорого, а иногда есть и и бесплатные версии.

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

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

В таких случаях можно описать логику вашего процесса и заказать интеграцию у профессионалов. Скорее всего это будет стоить дороже «коробочного решения» — но позволит упаковать часть бизнес-процесса «под капот». Результат очевиден — вырастет скорость процессов в компании, снизится влияние человеческого фактора, ценность клиенту будет предоставляться быстрее — а значит вырастет прибыль.

Конечно не все процессы стоит сразу автоматизировать, как, например, не стоит убирать под капот коробку скоростей в автомобиле.

Думаю, в каждой компании есть хотя бы 1−2 процесса, которые стоит упаковать.

Что может автоматизация

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

Если программа или сервис, который вы используете имеет API (а он там точно есть), то мы можем автоматизировать этот процесс.

Есть некоторые оговорки:

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

Логика должна быть однозначной. Например, мы делали автоматизацию импорта товаров в магазин и «склеивали» несколько прайс-листов. Если один и тот же товар присутствует в двух прайсах, какую запись использовать для цены, наличия остатков, описания товара, картинки? (Правильный ответ: тот или другой прайс можно использовать в разное время и в разных процессов в зависимости от задач, которые нужно решить клиенту).

Желательно, чтобы логика была полной. Последнее трудновыполнимо. 

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

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

Например, интеграция может делаться так:

Сервис подбора жилья принимает заявки в CRM и использует базу данных для подбора предложений конкретному клиенту.

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

И CRM и база данных имели API. Мы составили сценарий интеграции — что передаем, по каким триггерам, как передаются данные из каждого поля, как передаются разные типы данных (локации, статусы, числа).

В CRM есть статусы и типы у заявки, в БД эти статусы и типы отличались. Клиент привел все что мог к общему формату, все было описано в таблице сопоставления.

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

Программист реализовал подключение по API к CRM и к БД, создал справочники по таблице сопоставления, описал логику в алгоритме.

По сценарию интеграции создали сценарий тестирования. После тестирования запустили интеграцию.

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

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

Какие есть недостатки у такого решения:

При изменении бизнес-процесса в компании скорее всего придется дорабатывать автоматизацию. То есть лучше автоматизировать устоявшиеся процессы.

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

Итак, для успешного проекта нужно:

• описать сценарий интеграции
• описать передаваемые данные
• определить триггеры
• определить поведение в нечетких условиях
• дополнить инструкции для сотрудников

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