Что подготовить перед интеграцией систем: чек-лист для бизнеса

Почему интеграции тормозят на подготовке

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

Поэтому до разработки полезно описать один конкретный поток данных от события до результата. Например: заказ создан на сайте → проверены обязательные поля → создана или обновлена карточка в CRM → менеджеру назначена задача → ошибка передачи попала ответственному.

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

Список систем и владельцев

Первый блок чек-листа — перечень всех систем, которые участвуют в процессе. Важно учитывать не только две основные программы, но и промежуточные источники: сайт, CRM, 1С, Excel-файлы, почту, внутренний портал или внешний сервис.

• Система: где создаются или используются данные.
• Роль в процессе: источник, получатель или промежуточная точка.
• Владелец: кто со стороны бизнеса отвечает за корректность данных и правила работы.
• Технический контакт: кто может предоставить документацию, доступ или помочь проверить обмен.
• Источник правды: какая система считается основной для конкретного объекта или поля.

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

Данные, правила, события и частота обмена

После списка систем нужно описать не «синхронизацию целиком», а конкретные объекты и поля. Для каждого потока фиксируют, что запускает передачу, какие данные обязательны и что происходит при изменении.

Для интеграции 1С и CRM такой подход помогает отделить нужные бизнесу данные от попытки «синхронизировать всё». Примеры приоритетов по клиентам, сделкам, оплатам и отгрузкам есть в статье о связке 1С и CRM.

Доступы, API и тестовые контуры

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

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

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

Пример карты интеграции

Допустим, компании нужно передавать заказ с сайта в CRM, а после оплаты показывать менеджеру статус из 1С. Короткая карта может выглядеть так:

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

Чек-лист перед стартом

1. Опишите бизнес-результат. Что должно измениться после интеграции: исчезнет ручной перенос, ускорится обновление статуса, уменьшится число ошибок.
2. Перечислите системы. Добавьте источники, получателей и промежуточные файлы или сервисы.
3. Назначьте владельцев. Отдельно зафиксируйте бизнес-ответственных и технические контакты.
4. Определите источник правды. Для ключевых сущностей и полей должно быть понятно, где хранится основное значение.
5. Составьте список данных. Поля, идентификаторы, обязательность, форматы и правила преобразования.
6. Опишите события и частоту. Когда запускается обмен и насколько быстро результат нужен пользователю.
7. Определите обработку ошибок. Повтор, журнал, уведомление и ответственный должны быть понятны заранее.
8. Проверьте доступы. API, права, лицензии, сетевые ограничения и тестовый контур.
9. Выберите один поток для пилота. Сначала проверьте обмен на ограниченном сценарии, затем расширяйте интеграцию.

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