Я не начинаю интеграцию с API, пока не понятен владелец ошибки
Интеграция почти никогда не ломается «сама». Обычно в момент сбоя оказывается, что две системы обменялись данными, а отвечать за конкретную ошибку некому. Продажи говорят, что передали заказ. Склад не видит его у себя. Разработчик проверяет очередь. Руководитель открывает чат, где уже десять сообщений и ни одного решения.
Поэтому я не начинаю разговор об интеграции с API, форматами и очередями. Сначала хочу понять, кто заметит ошибку, кто разберёт её по существу и кто имеет право принять решение в спорном случае. Это не бюрократия перед разработкой. Это способ не превратить полезную связку систем в источник ежедневной тревоги.
Техническая связка — только половина работы
Представим обычную ситуацию. Менеджер оформил заказ в CRM. Его нужно передать в учётную систему, затем на склад, а покупателю — отправить подтверждение. На схеме четыре прямоугольника и три стрелки. Выглядит просто.
Но рабочий день живёт не на схеме. У клиента может не совпасть телефон. Товар может быть зарезервирован другим заказом. Менеджер может исправить адрес уже после передачи. У одной системы может быть техническая пауза. И каждая такая «мелочь» превращается в вопрос: что именно должно случиться дальше?
Недавно я писал о том, почему передача заказа из продаж в исполнение требует явных деталей. Здесь важен следующий слой: даже правильно переданный заказ иногда не проходит дальше. Нормальная интеграция не прячет такой случай в техническом журнале. Она помогает человеку быстро понять, что делать.
Владелец ошибки — не тот, кто чинит код
Эти роли полезно разделить. Технический специалист отвечает за доступность обмена, повторную отправку и исправление дефекта. Но он не должен угадывать, какой из двух одинаковых контрагентов верный или можно ли отпустить заказ без ИНН.
Владелец ошибки — это человек или роль, которые знают бизнес-смысл случая и могут завершить его решением. Для ошибки реквизитов это может быть менеджер. Для расхождения остатков — сотрудник склада. Для правила расчёта цены — финансовый контролёр. У него должны быть не только обязанности, но и право сказать: «исправляем так».
Когда роли смешивают, появляются две крайности. Либо бизнес ждёт, пока разработчик вручную разберётся в чужом процессе. Либо техническая команда получает десятки одинаковых запросов без признака срочности. В обоих случаях связь систем формально работает, а компания тратит время на обходы.
Четыре вопроса до первой задачи разработчику
Я предлагаю пройти по каждому направлению обмена коротко, но буквально. Не «CRM интегрируется с учётом», а один конкретный объект: заказ, клиент, счёт, остаток.
- Как выглядит успех? В какой системе и в каком состоянии должна появиться запись, чтобы следующий сотрудник мог продолжить работу?
- Как выглядит сбой? Какие три–пять наиболее вероятных причин важны для бизнеса, а не только для логов?
- Кому он попадает? Где человек увидит случай: в своей очереди, уведомлении или отчёте? Не в общем чате.
- Что он может сделать? Исправить данные, выбрать вариант, отправить повторно, остановить операцию или передать дальше с понятной причиной.
После этих вопросов обсуждение API становится намного спокойнее. Команда понимает, какие статусы нужны, какие данные нельзя потерять и что считать повторной попыткой, а не новой операцией.
Одна ошибка должна быть видна одному человеку
Это не значит, что ошибка всегда имеет единственного виновника. Речь о первом владельце. Если уведомление одновременно получают директор, бухгалтер, менеджер, аналитик и разработчик, чаще всего его не берёт никто. Все думают, что это уже сделал кто-то другой.
Хорошее правило: у сбоя есть начальная очередь и понятный срок реакции. Например, запись с неполным адресом возвращается менеджеру. Если он не исправил её до конца дня, она становится видна руководителю продаж. Техническая команда подключается, когда есть признак сбоя обмена, а не когда данных не хватает.
Такой порядок похож на сортировку почты. Не нужно, чтобы каждый сотрудник компании открывал каждое письмо. Нужно, чтобы письмо сразу попадало тому, кто способен ответить, а сложный случай не исчезал в ящике.
Не путать наблюдаемость с тревожной сиреной
У интеграции полезно видеть три уровня. Первый — общая картина: сколько объектов прошло, сколько ждёт, сколько отклонено. Второй — конкретная карточка с причиной и действием. Третий — техническая диагностика для команды разработки.
Без первого уровня руководитель узнаёт о проблеме от клиента. Без второго сотрудник копирует номер заказа в чат. Без третьего разработчик не может отличить неправильные данные от сбоя соединения. О том, почему важнее видеть момент потери контроля, чем искать виноватого после сбоя, я рассказывал в заметке про наблюдаемость системы.
Здесь не нужна дорогая панель ради самой панели. Иногда достаточно очереди исключений, статуса последней попытки и ссылки на исходную запись. Главное — чтобы это было частью рабочего процесса, а не скрытой страницей для администратора.
Небольшой составной пример
Возьмём компанию с продажами через сайт и менеджеров. Заказ сначала попадает в CRM, затем в учётную систему. В начале проекта команда хотела передавать всё сразу и «разбираться по ходу». Но в тестовом сценарии появился клиент с уже существующей карточкой и другим телефоном.
Если просто создать дубль, склад может отправить не туда. Если остановить весь обмен, зависнут остальные заказы. Решение оказалось не техническим: спорные карточки ушли в отдельную очередь менеджера, а остальные заказы продолжили движение. У записи появились две кнопки — подтвердить совпадение или создать нового клиента. Разработчику не пришлось решать за продажи, а менеджеру — искать логи.
Это не универсальный шаблон. В другой компании владельцем мог бы быть оператор контакт-центра. Ценность подхода в том, что правило рождается из реального действия, а не из красивой стрелки между системами.
Что проверить перед запуском
- У каждого типа исключения есть владелец бизнес-решения.
- Сотрудник видит не технический код, а понятную причину и следующий шаг.
- Повторная отправка не создаёт дубликат.
- Срочные случаи отличаются от обычных и не теряются в общей очереди.
- Команда раз в неделю смотрит не только на ошибки, но и на их повторяемость.
Если одна и та же ошибка повторяется, это не повод нанять ещё одного человека для ручной обработки. Скорее всего, правило или данные требуют пересмотра. В этом месте полезно вернуться к вопросу о границах интеграции: не каждая информация обязана мгновенно путешествовать между всеми системами.
Интеграция становится надёжной не тогда, когда в ней нет ошибок. Такого состояния в живом бизнесе почти не бывает. Она становится надёжной, когда ошибка быстро оказывается у человека, который понимает её последствия и может завершить работу без длинного совещания.
Как договориться о владельцах без большого регламента
Не нужно начинать с документа на двадцать страниц. Достаточно собрать на час тех, кто работает с объектом каждый день: представителя бизнеса, будущего владельца очереди и технического специалиста. Возьмите пять последних нестандартных случаев или смоделируйте их честно. «У клиента уже есть карточка». «Цена изменилась после подтверждения». «Ответ от учётной системы не пришёл». «Заказ отменили в одной системе, но он уже ушёл на склад».
Для каждого случая зафиксируйте одну короткую строку: триггер, первый владелец, допустимое действие и момент эскалации. Например: «Если контрагент не проходит проверку, менеджер уточняет данные; если не ответил до 16:00, подключается руководитель продаж». Такая запись важнее общего обещания «оперативно решать проблемы».
После запуска этот список не должен лежать в архиве. Первые две недели он почти наверняка изменится. Окажется, что один тип ошибки встречается чаще, другой вообще не важен, а человеку не хватает одного действия в карточке. Это нормальный результат. Интеграцию проверяют не только тестовыми запросами, но и тем, как спокойно с ней живут люди.
Почему нельзя измерять только процент успешных передач
Показатель «99,8% сообщений доставлено» полезен инженеру, но иногда успокаивает бизнес слишком рано. В оставшихся двух десятых процента может оказаться заказ ключевого клиента, отмена платежа или изменение остатка. Поэтому рядом с общим процентом я бы смотрел на возраст незакрытых исключений и на долю тех, что потребовали ручного вмешательства повторно.
Если количество ошибок небольшое, но одна очередь висит по три дня, система уже не управляется. Если ошибок много, но большинство решают за минуту на понятном шаге, это может быть обычная особенность процесса. Числа нужны не для отчёта, а чтобы увидеть, какой разговор начать: о данных, правилах работы или надёжности самой связи.
У владельца бизнеса здесь появляется простой вопрос для еженедельной встречи: «Какие три исключения у нас были самыми дорогими по последствиям и что мы изменим, чтобы они не повторились?» Такой вопрос не требует читать технические логи, но держит интеграцию в зоне управляемого внимания.
С чего начать, если связь уже работает плохо
Не пытайтесь сразу переписать весь обмен. Возьмите один поток, где задержка заметна клиенту или деньгам. Соберите реальные примеры за последнюю неделю, сгруппируйте их по причине и назначьте первого владельца хотя бы для двух самых частых. Затем сделайте видимой небольшую очередь: номер исходной записи, причина, время возникновения, текущий ответственный и действие.
После этого становится видно, нужна ли техническая доработка. Иногда достаточно запретить ручное изменение поля после отправки. Иногда — добавить проверку до передачи. Иногда — вынести сложное решение на этап согласования. А иногда выясняется, что две системы обмениваются данными, которые второй системе вообще не нужны.
Так интеграция перестаёт быть чёрным ящиком между подрядчиком и отделом продаж. Она становится частью обычной операционной работы: с понятным входом, контролируемыми исключениями и человеком, который в нужный момент может сказать, как двигаться дальше.
Обсудим?