Стоимость разработки интеграции — API, CRM, 1С и внешние сервисы

Запрос на оценку часто звучит так: «Нужно связать CRM и 1С. API у них есть. Сколько стоит?» Для трёх типовых сценариев ориентир начинается с 16–28 часов на передачу формы с сайта в CRM. Двусторонний обмен CRM с 1С занимает 80–160 часов при заранее зафиксированном составе работ, подключение внешнего сервиса по API — 28–56 часов.

Если для сценарного расчёта использовать согласованную для этой модели ставку Qtim — 3 150 ₽/час, получатся вилки 50 400–88 200 ₽, 252 000–504 000 ₽ и 88 200–176 400 ₽ соответственно. Эта модель нужна для сравнения задач. Итог зависит от систем, данных, правил обмена и требований к надёжности.

100–300 тыс. и 900 тыс. — это разный состав работ

Данные Workspace относятся к категориям целиком, а суммы из брифов — к стартовым бюджетам до получения коммерческих предложений; финальные цены договоров неизвестны. Ориентиры помогают увидеть порядок бюджета, когда рядом описан состав задачи. Сценарные вилки ниже рассчитаны по этой ставке и фиксированным границам работ.

Две системы на схеме — пять процессов в смете

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

Приблизительную сложность можно проверить в два шага:

объекты × направления обмена × события = базовые сценарии;

базовые сценарии × исключения = проверки.

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

Сценарий на 80–160 часов ниже рассчитан для двух объектов — клиентов и заказов — и заранее согласованного набора статусов. Контур на три объекта с 24 сценариями и 72 проверками уже требует отдельного обследования. Формула помогает заметить эту границу до запроса коммерческого предложения.

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

API открыт, а правила обмена ещё нужно определить

API задаёт способ обращения к системе. Он не объясняет, как связать карточку контрагента в 1С с компанией в CRM или какой статус вернуть после частичной оплаты. Эти правила команда фиксирует до разработки.

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

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

Обратный путь добавляет статусы, конфликты и проверки

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

Если остаток хранит 1С, CRM не должна перезаписать его старым значением. Если менеджер объединил два дубля клиента, обмену нужно корректно связать карточки контрагента. Платёжная система, телефония или доставка добавляют свои лимиты и статусы. Каждая развилка требует аналитики, кода и отдельной проверки.

Поэтому тестирование считают по потокам. Проверяют первичную загрузку, обычный обмен, изменение задним числом, дубль, недоступный сервис и восстановление. Демонстрация на одном идеальном заказе не показывает, что произойдёт в рабочем контуре.

Повторы, очереди и логи защищают заказы от дублей и потерь

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

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

Эти механизмы увеличивают первоначальный объём работ, зато сокращают время поиска сбоя и риск потерять оплату, заказ или актуальный остаток. После релиза отдельно оценивают наблюдение, разбор инцидентов и адаптацию к изменениям API, конфигурации 1С, полей CRM и бизнес-правил.

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

Три частых запроса — три вилки

Семь пунктов, которые превращают запрос в оценку

Для первой оценки хватит карты обмена:

• какие системы участвуют и какие у них версии;

• какие объекты и поля передаются;

• в какую сторону идут данные;

• какая система хранит исходное значение;

• какие статусы и исключения критичны;

• какая задержка допустима и что произойдёт при сбое;

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

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

Если вы планируете CRM и дашборды под процессы бизнеса, можно прийти со схемой на один лист и контактами ответственных за каждую систему. Мы разложим задачу на потоки данных, риски и состав первой версии для точной оценки.