Для первой оценки интеграции не требуется готовое техническое задание. Нужен конкретный рассказ об одном потоке данных: какое событие его запускает, где появляются данные, куда они должны попасть, как обе системы распознают одну и ту же запись и кто реагирует, если операция завершилась ошибкой.
Не начинайте с фразы «мы хотим соединить две системы». Начните с результата, который можно проверить. Например: «после приёма заказа данные клиента и позиции должны попасть в программу обработки без повторного ввода и без создания дублей».
Такое описание ещё не определяет, что именно станет решением: API, webhook, регулярный импорт файла или небольшое промежуточное приложение. Но оно позволяет ограничить первый этап и понять, что следует проверить до обоснованной оценки.
Начните с одного процесса, а не со всей компании
Компания может одновременно использовать интернет-магазин, CRM, бухгалтерскую программу, складскую систему, портал поставщика и несколько таблиц. Попытка сразу описать все возможные связи быстро превращается в список пожеланий без ясного начала и конца.
Для первого этапа выберите поток, который:
- регулярно повторяется;
- требует ручного переноса или повторной проверки данных;
- имеет понятное начало и результат;
- при ошибке или задержке создаёт конкретную проблему;
- закреплён за ответственным человеком.
Это может быть передача заказа из магазина в систему обработки, создание сделки в CRM после отправки формы или возврат статуса доставки. Один хорошо описанный поток даёт больше пользы для первого разговора, чем общее требование синхронизировать всю систему компании.
Если сначала нужно оценить объём ручной работы, прочитайте материал Когда стоит автоматизировать ручной перенос данных? и воспользуйтесь калькулятором рабочего времени и сценария автоматизации.
Заполните карту потока данных
Для этой карты не нужны термины разработчиков. В каждой строке опишите текущее состояние и ожидаемый результат. Если вы чего-то не знаете, отметьте это прямо. Открытый вопрос — это пункт для проверки, а не ошибка в брифе.
| Элемент карты | Что нужно выяснить | Пример ответа |
|---|---|---|
| Начало | Что запускает поток? | В магазине подтверждена оплата заказа. |
| Исходная система | Где возникает информация? | В интернет-магазине. |
| Состав данных | Какие данные действительно нужно передать? | Номер заказа, данные доставки, позиции и суммы. |
| Идентификатор | Как обе системы распознают один случай? | Номер заказа магазина сохраняется как внешний идентификатор. |
| Направление | Данные идут в одну сторону или что-то возвращается? | Заказ уходит из магазина, статус обработки возвращается. |
| Срок | Как быстро изменение должно стать видимым? | В течение пяти минут после оплаты. |
| Подтверждение | Как понять, что операция успешна? | Целевая система возвращает собственный номер обращения. |
| Ошибка | Что происходит при отсутствии данных или недоступности системы? | Операция ожидает повтора, а ответственное лицо видит сообщение. |
| Сверка | Как обнаружить отсутствие или расхождение? | Ежедневный список оплаченных заказов без подтверждённого номера обращения. |
| Ответственность | Кто принимает решение в неоднозначной ситуации? | Руководитель обработки заказов. |
Такая таблица полезна и тогда, когда текущий процесс работает через CSV-файл или электронную таблицу. Важнее не название технологии, а то, кто отвечает за информацию на каждом этапе.
Определите источник истины для каждой информации
«Двусторонняя синхронизация» звучит удобно, но без правил создаёт конфликты. Если цена одновременно изменилась в магазине и складской программе, интеграция должна знать, какое значение считать действующим.
Источник истины не обязательно один для всей записи. Например:
- магазин может отвечать за состав заказа, принятого от клиента;
- складская система — за наличие товара;
- бухгалтерская программа — за номер и статус документа;
- CRM — за сотрудника, отвечающего за отношения с клиентом.
До первого разговора перечислите важные поля и укажите систему, в которой каждое из них разрешено менять. Если сотрудники сейчас исправляют одни и те же данные в нескольких местах, также отделите официальный процесс от обходных действий, возникших из-за его ограничений.
Определите, как системы распознают одну запись
Имени клиента, адреса электронной почты или названия товара обычно недостаточно для безопасного сопоставления. Эти значения могут меняться, повторяться или записываться по-разному. Нужен стабильный идентификатор или согласованное правило сопоставления.
В описании интеграции укажите:
- идентификатор записи в исходной системе;
- идентификатор, присвоенный целевой системой;
- место хранения связи между ними;
- правило для записи, которую невозможно сопоставить однозначно;
- способ распознавания повторной операции.
Последний пункт защищает от дублей. Целевая система могла сохранить данные, но её ответ не вернулся из-за разрыва соединения. Простой повтор способен создать вторую запись. Интеграция должна понять, что операция уже выполнена, или передать неоднозначный случай на проверку.
Подберите частоту под реальную потребность
Не каждый процесс требует мгновенной реакции. Обновление статуса заказа может понадобиться через несколько минут, а сводный экспорт для отчёта — раз в день. Требование работы «в реальном времени» повышает зависимость от доступности обеих систем и не всегда приносит дополнительную пользу.
Опишите допустимую задержку и исключительные ситуации. Поток может запускаться:
- после конкретного события, например отправки формы;
- по расписанию, например каждые пять минут или раз в день;
- вручную после подтверждения уполномоченным сотрудником;
- пакетно, если данные предоставляются в файле.
Технический механизм выбирают после проверки возможностей обоих инструментов. Само упоминание API не гарантирует доступ к нужным данным, подходящие лимиты или безопасную тестовую среду.
Предусмотрите ошибки, повторы и сверку данных
Интеграция не готова только потому, что правильно обработала одну тестовую запись. Нужны правила и для случаев, когда отсутствует обязательное поле, система не отвечает, формат данных изменился или результат неоднозначен.
Подготовьте ответы на четыре вопроса:
- Какие ошибки можно безопасно повторять автоматически?
- Какие ошибки требуют исправления данных или решения человека?
- Кто и каким способом узнаёт о проблеме?
- Как позже проверить, что все операции завершились?
Повтор и сверка решают разные задачи. Повтор пытается завершить конкретную операцию. Сверка сравнивает состояние обеих сторон и находит записи, которых не хватает или которые остановились без ясного результата.
Не каждая ошибка должна запускать серию автоматических попыток. Если данные неверны или требуется бизнес-решение, повторная отправка того же содержимого ничего не исправит. Такой случай должен оставаться видимым для ответственного сотрудника.
Отделите технический доступ от материалов для оценки
Для первого анализа достаточно названий систем, типов данных, обезличенного примера структуры и доступной документации. Не отправляйте в сообщении пароли, токены, сертификаты, копию рабочей базы, реальные данные клиентов или сотрудников.
Во время реализации мы отдельно согласовываем:
- способ аутентификации каждого соединения;
- минимальные права технических учётных записей;
- тестовую среду или безопасные примеры данных;
- место хранения секретов;
- лиц, уполномоченных подтвердить доступ;
- порядок отзыва прав после завершения сотрудничества.
Интеграционная учётная запись не должна получать лишние права только потому, что администратору так проще. Разрешения должны следовать из согласованной карты потока.
Что нужно проверить до обоснованной оценки?
Одного названия программы редко достаточно, чтобы определить объём. До оценки может потребоваться проверить:
- предоставляет ли разработчик поддерживаемый способ обмена данными;
- охватывает ли документация нужные операции и текущую версию;
- требования аутентификации, лимиты и условия доступа;
- наличие тестовой среды;
- состояние идентификаторов и исторических данных;
- кто отвечает за изменения со стороны каждого поставщика;
- следует ли исправить существующую интеграцию или заменить её.
Если документация неполная, в данных много исключений или нужно взаимодействие нескольких поставщиков, первым этапом может стать платное техническое обследование. Его цель и объём мы согласовываем заранее. Результатом должны быть конкретные выводы для принятия решения, а не общее утверждение, что проект сложный.
Пример заполненной карты
Следующий сценарий вымышлен. Он показывает способ описания, а не готовый проект и не внедрение для клиента Domin Software.
Компания принимает заказы в интернет-магазине, а команда обработки работает в отдельном приложении. После оплаты сотрудник вручную переносит данные клиента и позиции, а затем вручную обновляет статус в магазине.
Цель первого этапа: оплаченный заказ должен создать ровно одно обращение в приложении обработки. Его номер возвращается в магазин, чтобы сотрудники могли связать обе записи.
Источники истины: магазин отвечает за содержание принятого заказа. Приложение обработки — за назначенного сотрудника и статус работы. После передачи интеграция не изменяет позиции заказа.
Идентификаторы: номер заказа магазина сохраняется в приложении обработки как внешний идентификатор. Магазин сохраняет возвращённый номер обращения.
Срок: поток запускает подтверждение оплаты. Допустимая задержка — пять минут.
Ошибки: отсутствие обязательных данных останавливает запись и создаёт задачу на исправление. Ошибку соединения можно повторить. Перед повтором интеграция проверяет, существует ли уже обращение с таким номером заказа.
Сверка: раз в день формируется список оплаченных заказов без номера обращения и обращений, статус которых не вернулся в магазин.
Ответственность: сотрудник клиентской службы исправляет недостающие данные, а руководитель решает неоднозначные случаи. Технические проблемы передаются в согласованный канал поддержки интеграции.
По такой карте мы можем проверить, поддерживают ли обе системы необходимые операции, какие предположения требуют теста и можно ли оценить первый этап без дополнительного обследования.
Что сильнее всего влияет на объём интеграции?
Количество передаваемых полей — лишь один из факторов. Важны также:
- односторонний или двусторонний обмен;
- качество и согласованность существующих данных;
- стабильность идентификаторов;
- количество исключений, требующих решения;
- ожидаемая задержка;
- доступность документации и тестовой среды;
- лимиты и изменения внешней службы;
- требуемый мониторинг и порядок обработки инцидентов;
- перенос исторических данных, если он действительно нужен.
Поэтому два проекта, соединяющие похожие типы программ, могут иметь совершенно разный объём. Надёжно оценить интеграцию только по названиям приложений нельзя.
Что отправить для первого разговора?
Подготовьте:
- названия и версии обеих систем, если они известны;
- описание одного потока по приведённой выше карте;
- список данных, необходимых на первом этапе;
- информацию о системе, отвечающей за каждое ключевое поле;
- обезличенный пример файла или структуры данных;
- ссылку или файл с официальной документацией интеграции, если она доступна;
- описание текущей ручной работы или ошибки;
- ожидаемый результат и допустимую задержку;
- человека, который знает процесс и может решать исключения.
Вам не нужно самостоятельно выбирать протокол, очередь, библиотеку или архитектуру. Эти решения должны следовать из возможностей систем и согласованного процесса.
Услуга Domin Software по интеграции систем и автоматизации потока данных включает API, webhook, импорт и экспорт. Если интеграция является частью более крупного изменения приложения, посмотрите также наши услуги разработки на PHP и Laravel.
Подготовим первый поток к оценке
В сообщении опишите две системы и один процесс, который хотите улучшить. Если вы не знаете, существует ли API или какая программа должна быть источником данных, прямо укажите этот открытый вопрос. Мы проверим, можно ли сразу определить объём или сначала нужно изучить документацию и данные.
Если хотите сначала самостоятельно упорядочить исходные данные, воспользуйтесь планировщиком интеграции двух систем.