Интеграция систем: способы, примеры и как выбрать

Интеграция систем это настройка автоматического обмена данными между программами компании: сайтом, CRM, 1С, складом, телефонией и платёжными сервисами. Заявка с сайта сама появляется в CRM, оплата сама меняет статус заказа, остатки из учёта сами обновляются на сайте. Способов интеграции пять: обмен файлами, прямой обмен по API, вебхуки, готовые коннекторы и промежуточный сервис. Выбирают способ по объёму данных, допустимой задержке и возможностям самих систем, а окупается интеграция там, где сейчас данные переносят руками часто и с ошибками.

Примеры интеграции систем в обычной компании

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

Связка	Что передаётся	Что ломается без интеграции
Сайт → CRM	Заявки с формы, источник и метки рекламы	Заявка лежит в почте, источник теряется, менеджер видит её поздно
CRM ↔ 1С	Клиенты, счета, оплаты, отгрузки	Менеджер не знает, оплачен ли счёт, бухгалтер переспрашивает реквизиты
1С → сайт	Остатки, цены, карточки товаров	Покупатель заказывает то, чего нет, или по старой цене
Маркетплейс → учёт	Заказы, возвраты, выплаты	Заказы вбивают руками, остатки расходятся между площадками
Телефония → CRM	Звонки, записи, пропущенные	Пропущенный звонок никто не перезванивает
Платёжный сервис → заказ	Факт оплаты, возвраты	Оплату подтверждают вручную, клиент ждёт

Отдельная большая тема: как CRM связывают с сайтом, почтой и телефонией. Она разобрана в статье интеграция с CRM: что это, здесь речь о выборе способа для любых систем.

Пять способов интеграции

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

• Обмен файлами. Одна система выгружает файл, другая забирает его по расписанию. Просто и дёшево, но данные приходят с задержкой, а ошибка в одной строке может остановить весь файл.
• Прямой обмен по API. Программа сама обращается к другой системе: запрашивает новое или записывает данные. Быстро и точно, но упирается в лимиты запросов.
• Вебхуки. Система-источник сама присылает уведомление о событии: «создана сделка», «пришла оплата». Реакция почти мгновенная, но принимающая сторона должна быть всегда на связи.
• Готовый коннектор. Приложение из каталога CRM или маркетплейса, которое связывает две популярные системы. Запускается за день, но делает ровно то, что задумал его автор.
• Промежуточный сервис. Отдельный слой, через который идут все потоки: он принимает, проверяет, переводит форматы и пишет журнал. Дороже на старте, зато системы не связаны каждая с каждой.

Во вкладках подробнее, когда какой способ подходит и что проверить.

Каждая с каждой или через посредника

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

Арифметика простая: при прямых связях между n системами возможных пар n × (n − 1) ÷ 2. Для трёх систем это три связи, для пяти уже десять, для восьми двадцать восемь. Не каждая пара обменивается данными, но каждую новую систему приходится подключать к нескольким старым. Промежуточный сервис меняет картину: новая система подключается один раз, к нему, а журнал ошибок и правила проверки лежат в одном месте.

Что ограничивает интеграцию: лимиты и возможности систем

Возможности интеграции задаёт не разработчик, а сами системы: есть ли у них API, сколько запросов они принимают и сколько данных отдают за раз. Это стоит проверить по документации до того, как обещать «обмен в реальном времени».

Система	Что сказано в документации	Что это значит на практике
amoCRM	Не более 7 запросов в секунду на одну интеграцию и до 50 на аккаунт; списочные методы обычно отдают не более 250 сущностей; создавать или менять за раз можно до 250, рекомендуется не более 50; после окончания подписки API отвечает кодом 402	Массовую загрузку делят на пачки и растягивают во времени; при неоплате интеграция останавливается
Битрикс24 (облако)	Счётчик запросов уменьшается на 2 в секунду при пороге 50 (на тарифе Энтерпрайз 5 и 250); один запрос должен уложиться в 60 секунд; метод batch передаёт до 50 вызовов в одном запросе; документация прямо пишет, что REST API не предназначен для массового и интенсивного обмена большими данными	Короткие всплески проходят, постоянный высокий поток нет; для больших выгрузок нужны пакеты и очередь
1С:Предприятие 8.3	В руководстве разработчика описаны Web-сервисы, HTTP-сервисы и стандартный интерфейс OData	Способ зависит от конфигурации и того, что опубликовано на сервере: это выясняют с тем, кто сопровождает вашу 1С

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

Как выбрать способ интеграции

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

Вопрос	Если ответ такой	Подходит
Как быстро данные нужны в другой системе?	Сразу: оплата, заявка, бронь	Вебхук или API
Можно ли подождать?	Да, до утра: справочники, отчёты, остатки для прайса	Файл или пакет по расписанию
Есть ли у системы API?	Нет, только выгрузка	Файловый обмен
Есть ли готовый коннектор под ваш сценарий?	Да, без обходных путей	Коннектор, с проверкой журнала ошибок
Сколько систем и потоков?	Четыре и больше, правила меняются	Промежуточный сервис
Кто будет поддерживать?	Нет своего разработчика	Решение с понятной документацией и передачей доступов

Перед разговором с разработчиком опишите обмен на бумаге: какие системы, какие поля, кто источник правды, что делать при ошибке. Шаблон такого описания с примером есть в статье как описать обмен данными.

Три примера выбора способа

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

Пример: интернет-магазин на маркетплейсах и своём сайте

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

Пример: сервисная компания с CRM и 1С

Менеджеру в CRM нужно видеть, оплачен ли счёт. Бухгалтерии нужны реквизиты клиента без перепечатывания. Источник правды по клиентам CRM, по оплатам 1С. Счёт создаётся в CRM и уходит в 1С, оплата возвращается обратно. Если готовый коннектор делает ровно это и пишет журнал, его достаточно.

Пример: производство с пятью системами

Сайт, CRM, 1С, складская программа и система планирования производства обмениваются заказами, остатками и статусами. Прямых связей получается много, и каждая ломается по-своему. Здесь разумнее промежуточный сервис: он принимает данные от всех систем, проверяет их, переводит форматы и пишет общий журнал. Новую систему потом подключают только к нему.

Окупится ли интеграция

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

Как проходит проект интеграции

Проект интеграции состоит из пяти шагов, и ни один нельзя пропустить без последствий. Самая частая ошибка: начать с программирования, не описав обмен и не договорившись, как будут проверять результат.

1. Карта систем. Какие системы есть, какие данные куда идут, кто за них отвечает.
2. Описание обмена. Поля, направления, частота, источник правды, поведение при ошибке.
3. Разработка и приёмка. Проверка на реальных контрольных примерах, а не на тестовых «Иван Иванов». Как это сделать, разобрано в статье о приёмке интеграции.
4. Журнал и оповещения. Каждый обмен записывается, о сбое узнаёт ответственный, а не клиент. Что писать в журнал и какой нужен запасной сценарий, описано в статье о проверках и журнале ошибок.
5. Запуск и поддержка. Доступы, ключи и код передаются владельцу бизнеса, а не остаются у подрядчика.

Если нужна интеграция систем под ключ с журналом обменов, повторными попытками и оповещениями, этот порядок работ остаётся тем же, меняется только объём.

Кто поддерживает интеграцию после запуска

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

• Ответственный в компании. Получает оповещения о сбоях, решает, что делать с ошибочными записями, и знает запасной ручной сценарий.
• Технический исполнитель. Свой разработчик или подрядчик по договору поддержки: исправляет сбои и вносит изменения.
• Владельцы систем. Те, кто сопровождает CRM и 1С, предупреждают об обновлениях и изменениях полей заранее.

Отдельно запишите, где лежит документация: схема потоков, описание полей, доступы. Если всё это знает только один человек, интеграция становится такой же уязвимой, как ручной перенос.

Чек-лист перед заказом интеграции

Пройдите по пунктам до первой встречи с подрядчиком. Чем больше отметок, тем точнее будет оценка сроков и стоимости.

Типичные ошибки

• Интеграция без источника правды. Две системы меняют одно поле, и данные бесконечно перезаписывают друг друга.
• Не учесть лимиты. Первичная загрузка базы упирается в ограничения API и идёт сутками.
• Коннектор без журнала. Обмен молча останавливается, и узнают об этом от клиентов.
• Связать всё со всем. Через год никто не помнит, какая связь за что отвечает.
• Доступы у подрядчика. Ключи API и сервер оформлены на исполнителя, и при смене подрядчика интеграцию приходится собирать заново.