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

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

Сначала разберите одно расхождение до конца

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

Разделите обнаруженные проблемы. Одни связаны со смыслом: разные подразделения называют «готовностью» разные состояния. Другие — с данными: товар продублирован, единицы измерения различаются, контрагент не сопоставлен. Третьи — с доставкой: событие задержалось или повторилось. Четвёртые — с порядком работы: сотрудник исправил данные после передачи, но никто не согласовал новую версию.

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

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

У каждого факта должен быть хозяин

Фраза «все системы должны показывать одинаковые данные» требует уточнения. CRM может хранить согласованный с клиентом срок, производственная система — прогноз завершения, учётная — дату проведённой отгрузки. Это разные факты. Если объединить их в одно поле «дата заказа», обмен начнёт уничтожать полезную информацию.

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

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

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

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

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

Возьмём условный заказ на изготовление деталей. Продажи согласовали 120 штук по чертежу версии 3. В производство передаётся утверждённая спецификация с идентификатором заказа и номером редакции. Через час клиент меняет количество на 140. Новая редакция не должна незаметно переписать уже выданное задание: требуется согласованное правило изменения запущенного заказа.

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

Описывайте и пустые значения. Пустое поле может означать «не передано», «неизвестно» или «удалить ранее указанное». Если получатель трактует эти состояния одинаково, очередное обновление способно стереть корректные данные. Для дат нужны единые правила часового пояса, для сумм — валюта и точность, для статусов — допустимые переходы.

Повторная доставка не должна создавать повторное действие

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

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

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

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

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

Сохранённый заказ ещё не означает доставленное событие

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

Один из технических подходов — transactional outbox: бизнес-данные и запись о предстоящей отправке сохраняются в одной транзакции базы данных, затем отдельный процесс доставляет сообщения. Механизм и границы реализации разобраны в архитектурной документации Microsoft. Он закрывает разрыв между локальным сохранением и постановкой на отправку, но сам по себе не заменяет проверку повторов у получателя.

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

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

Ошибка должна приводить к действию

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

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

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

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

Приёмка на неудобных сценариях

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

Задайте измеримые пределы: допустимую задержку обычного обмена, время обнаружения остановки, объём накопленной очереди, срок её обработки после восстановления. Цифры выбирают по требованиям процесса и возможностям систем. Например, для ночной аналитики и подтверждения складского резерва допустимые задержки будут разными.

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

Запуск без второй теневой базы

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

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

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

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

Что считать результатом

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

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

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

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

Все материалы →