Интеграция информационных систем: как связать сайт, CRM, 1С и сервисы

Интеграция начинается с общего процесса

Интеграция информационных систем связывает действия и данные в нескольких программах: заказ с сайта попадает в учёт, менеджер видит обращение в CRM, клиент получает актуальный статус. Полезный результат — продолжение работы без повторного ручного переноса. Сам факт установленного соединения этого не доказывает.

Рассмотрим компанию, у которой сайт принимает заказы, CRM помогает продавать, а 1С ведёт товары и учёт. До обсуждения модулей я бы описал один заказ от выбора товара до завершения работы, поскольку только такой путь покажет, где сотрудники повторяют ввод, какие сведения расходятся и в какой момент ошибка начинает влиять на обещание покупателю. Названия программ пока вторичны. Знакомый набор программ допускает разные правила связи. В одном варианте менеджер подтверждает заказ до передачи в учёт, в другом он получает уже созданный документ. Это разные правила работы.

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

Как разложить связи между сайтом, CRM и 1С

Составьте карту направлений обмена. В официальном протоколе 1С выделены два блока: выгрузка каталога, цен и остатков на сайт и обмен информацией о заказах. Для описанного протокола инициатором обоих выступает 1С, а документы соответствуют CommerceML 2.

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

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

Где находится правильное значение каждого поля

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

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

Таблица заполняется по реальной компании. Если источник пока неизвестен, это вопрос для решения, а не повод дать обеим системам одинаковое право менять значение.

Как системы узнают один и тот же товар и заказ

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

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

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

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

Мгновенная передача нужна не каждому полю. Описание услуги может спокойно ждать редактора, а остаток последнего товара влияет на возможность выполнить заказ. Частоту определяют по последствиям задержки.

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

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

Что дают готовые модули и API

Готовый обмен экономит работу, если его правила подходят процессу компании. Например, инструкция Тильды по CommerceML отдельно называет настройки «Создавать новые товары», «Обновлять цены» и «Обновлять остатки». Значит, предмет настройки — конкретные действия с данными, а не одна общая галочка интеграции.

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

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

Кому принадлежат доступы и ответственность за связь

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

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

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

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

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

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

Карточка приёмки: исходное действие; объект и его идентификатор; ожидаемая запись в получателе; допустимый срок; повторная попытка; сообщение об ошибке; ответственный за восстановление; способ сверки после восстановления.

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

Что меняется после запуска связи

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

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

Если источник каждого поля и путь заказа описаны, задачу интеграции для ШТАБ ИТ можно оценивать по конкретным операциям. Связанные программы начинают экономить ручной перенос тогда, когда компания способна доверять результату обмена и знает, как продолжить работу при отклонении.