API — это окно выдачи чужой программы: список запросов, которые она согласна принять от другой программы, и правила, по которым отвечает. Вебхук — обратный звонок: чужая программа сама стучится к вам в момент, когда что-то произошло, и не ждёт, пока её спросят. Всё остальное в интеграции — надстройка над этими двумя способами связи, и почти вся она нужна для одного: чтобы обмен пережил ситуацию, когда одна из сторон молчит.
Владельцу бизнеса эти два слова важны не сами по себе, а потому что из них складывается смета. Подрядчик считает работу не по системам, а по операциям: сколько запросов вызвать, сколько событий поймать, что делать, если ответа нет. Пока вы не знаете, что стоит за словами, смета выглядит непроверяемым числом, а разница между 90 000 и 400 000 ₽ за «связать сайт и 1С» — наглостью. После этой статьи она перестанет быть непроверяемой: вы сможете спросить, какие именно строки дают разницу, и получить ответ по существу.
Дальше — один сквозной пример: заказ с сайта доезжает до склада. На нём разобраны все понятия, за которые потом выставляют счёт, к каждому прикреплено денежное последствие, и в конце посчитан порог: при каком числе операций интеграция дешевле ручного переноса, а при каком дороже и бессмысленнее обычной выгрузки в таблицу. Цены и вилки — по состоянию на сентябрь 2026 года.
Кто кого спрашивает и кто кому стучится
Две программы обмениваются данными двумя способами, и вся разница в том, кто проявляет инициативу. Либо ваша система регулярно спрашивает чужую «что нового», либо чужая система сама сообщает вам, когда новое появилось. Первый способ называется опросом и работает через API, второй — событием и работает через вебхук.
Окно выдачи чужой системы: перечень операций, которые она согласна выполнить по просьбе другой программы, и формат, в котором отвечает. Инициатива всегда на вашей стороне: вы приходите к окну и спрашиваете. Если вы не спросили, вам ничего не сообщат — даже если у них там всё горит.
Обратный звонок: вы один раз оставляете чужой системе свой адрес, и она сама отправляет туда сообщение в момент события — «создан заказ», «изменён статус», «прошла оплата». Инициатива на их стороне. Ваша задача — держать круглосуточно работающий приёмник, который это сообщение примет и не потеряет.
В деньгах разница выглядит так. Опрос проще сделать: не нужен адрес, доступный из интернета, не нужен приёмник, работающий ночью, — достаточно задания по расписанию. Зато опрос тратит лимиты чужой системы впустую: если вы спрашиваете каждые пять минут, а заказы приходят по двадцать в день, 99% запросов возвращают «ничего нового». Вебхук экономит лимиты и даёт задержку в секунды, но требует инфраструктуры и обработки ситуации, когда сообщение не доехало, — а оно не доедет, потому что рано или поздно ваш сервер будет недоступен ровно в тот момент, когда чужая система решит постучаться.
Ещё одно следствие, которое стоит денег на переговорах. Требование «в реальном времени» в брифе почти всегда означает событийную схему, а она дороже опроса примерно в полтора-два раза: приёмник, круглосуточное дежурство, обработка недоставленных событий, сверка. При этом в половине задач реальное время не нужно вообще. Бухгалтерская выгрузка, аналитика за вчера, обновление каталога — всё это спокойно живёт на расписании раз в сутки. Прежде чем платить за секунды, стоит честно ответить, кто именно в компании пострадает, если данные приедут через десять минут, а не через пять секунд, и на сколько рублей.
Поэтому почти все рабочие связки — гибрид: события для срочного, регулярный опрос для сверки. События везут заказ за секунды, а ночная сверка сравнивает количества за сутки и подбирает то, что не доехало. Схему, как выбирать между расписанием и событиями и как считать допустимую задержку от бизнес-процесса, а не от желания, мы разбираем в отдельном материале кластера.
Схема из двух горизонтальных дорожек. Верхняя подписана «Опрос по API»: система А раз в 5 минут шлёт в систему Б одинаковые стрелки с подписью «есть новые заказы?», из десяти стрелок девять помечены серым «ничего нового», одна — «есть заказ №A-10482». Нижняя дорожка подписана «Событие (вебхук)»: система Б сама шлёт одну стрелку в А с подписью «создан заказ №A-10482, ссылка на состав», рядом пометка «задержка 2–5 секунд». Справа у каждой дорожки колонка «что нужно построить»: у верхней — «задание по расписанию», у нижней — «круглосуточный приёмник и адрес в интернете». Чертёжный стиль, подписи по-русски.
Семь шагов заказа: что и куда передаётся
Возьмём типовой путь: покупатель оформил заказ на сайте, заказ должен попасть в CRM к менеджеру и в учётную систему на резерв, а потом на склад в сборку. Со стороны это выглядит одним действием — «заказ уехал». Внутри это семь шагов, и на каждом передаётся что-то своё. Понимать этот путь важно не из любопытства: смета считается по шагам, а не по системам.
- 1Шаг 1. Сайт записывает заказ у себя
Покупатель нажал «оформить». Сайт сохранил заказ в собственной базе и присвоил номер — например, A-10482. На этом шаге наружу ничего не передаётся, но именно здесь появляется то, что дальше будет ездить между системами: позиции, количество, цена со скидкой, контакт, адрес доставки, способ оплаты.
- 2Шаг 2. Сайт сообщает о событии
Сайт отправляет вебхук на ваш адрес: «создан заказ A-10482, время такое-то, ссылка на карточку». Обратите внимание: в сообщении едет не сам заказ, а факт события и ссылка. Так делают почти все системы — сообщение должно быть маленьким и быстрым, потому что его отправляют тысячам подписчиков.
- 3Шаг 3. Приёмник запрашивает состав по API
Получив уведомление, ваш приёмник идёт к API сайта и спрашивает полный состав заказа A-10482. В ответ приезжают строки: артикул, количество, цена, скидка, данные покупателя, комментарий. Это уже полноценный документ, и с этого момента он у вас есть.
- 4Шаг 4. Приёмник кладёт заказ в очередь и отвечает «принял»
Заказ складывается в очередь — буфер, из которого его будут разбирать. Сайту немедленно отвечают «принято», и он закрывает свою часть работы. Наружу здесь не передаётся ничего, но именно этот шаг отвязывает судьбу заказа от того, жива ли сейчас 1С. Без очереди недоступность учётной системы означает потерю заказа.
- 5Шаг 5. Обработчик создаёт сделку в CRM
Из очереди заказ забирает обработчик и создаёт карточку в CRM: клиент, сумма, источник, состав, ответственный менеджер по правилу распределения. Передаётся то, что нужно продавцу, — и не передаётся то, что нужно бухгалтерии. Это разные наборы полей, и каждый согласуется отдельно.
- 6Шаг 6. Обработчик создаёт документ в учётной системе
Тот же обработчик создаёт «Заказ клиента» в 1С и резервирует остаток. Передаются артикул, количество, склад, вид цены, контрагент — и ключ операции, по которому система поймёт, что этот заказ она уже видела. Ключ здесь не техническая деталь: без него повтор при обрыве связи создаст второй документ и второй резерв.
- 7Шаг 7. Учётная система возвращает результат
1С отдаёт обратно номер документа, статус резерва и плановую дату отгрузки. Эти три поля уезжают обратно на сайт и в CRM, чтобы покупатель видел статус, а менеджер не звонил на склад. Обратное направление обычно забывают заложить в смету, а оно стоит примерно столько же, сколько прямое.
Карта связей систем в чертёжном стиле. Шесть прямоугольных узлов слева направо: «Сайт», «Приёмник», «Очередь», «CRM», «1С (учёт)», «Склад». Стрелки между ними подписаны тем, что передаётся: Сайт → Приёмник «событие: создан заказ A-10482, ссылка»; Приёмник → Сайт «запрос состава по API: строки, цены, скидки, контакт»; Приёмник → Очередь «заказ целиком, ключ операции»; Приёмник → Сайт «ответ: принято»; Очередь → CRM «клиент, сумма, состав, ответственный»; Очередь → 1С «артикул, количество, склад, вид цены, контрагент, ключ операции»; 1С → Склад «задание на сборку»; обратная пунктирная стрелка 1С → Сайт и CRM «номер документа, статус резерва, дата отгрузки». Узел «Очередь» выделен рамкой с подписью «здесь заказ перестаёт зависеть от доступности 1С». Все подписи по-русски.
Обратите внимание на шаг четвёртый: он не производит никакой видимой работы и при этом стоит в смете отдельных денег. Именно так устроена вся надёжность в интеграциях — она не делает ничего полезного в хороший день и оказывается единственным, что имеет значение, в плохой. Владельцу это тяжело принимать на этапе сметы, поэтому строку «очередь» вычёркивают чаще любой другой, а потом оплачивают её стоимость несколько раз потерянными заявками.
Из этой карты следует главное практическое правило. Фраза «настроить обмен с 1С» — не техническое задание, а способ получить счёт на доплату. Техническое задание перечисляет направления: номенклатура, цены, остатки, заказы, статусы, оплаты. Каждое направление обследуется, разрабатывается, тестируется и принимается отдельно. Шесть направлений вместо одного дают разницу в цене в три-четыре раза до всех остальных факторов — и это законная разница, а не накрутка.
Что именно едет по связи: поля, а не документы
Когда говорят «передаём заказ», кажется, что из одной системы в другую переезжает целый документ. На самом деле переезжает набор полей, и каждое поле нужно сопоставить руками — один раз, зато вдумчиво. У заказа на сайте порядка 34 полей, у «Заказа клиента» в учётной системе — около 51. По смыслу совпадают примерно 22. Остальные либо не нужны принимающей стороне, либо вычисляются на месте, либо заполняются значением по умолчанию, которое кто-то в вашей компании должен назначить.
Второй слой той же работы — ключ сопоставления. По какому признаку система понимает, что покупатель «Иванов И.» с сайта и контрагент «Иванов Иван Иванович» в учёте — один человек? Обычно по нормализованному телефону для физлиц и по ИНН для юрлиц, а лучше — по внешнему идентификатору, который одна система однажды присвоила и который вторая хранит у себя. Пока ключа нет, каждый повторный заказ создаёт нового контрагента, и через год в справочнике три карточки одного клиента с разной историей оплат.
- Карта полей — документ на 2–4 страницы: имя поля здесь, имя поля там, что делать, если пусто, кто хозяин значения. Утверждает его заказчик, а не подрядчик.
- Ключ сопоставления назначается отдельно для клиентов, для номенклатуры и для складов. Три разных ключа, три разных списка исключений.
- Сопоставление справочников — 15–25% работ проекта, и большая часть этого времени уходит не на код, а на ответы ваших людей: какие две карточки считать одной.
- Поле «комментарий» — индикатор незаконченной карты. Если в него складывают серию, скидку и пожелание по доставке, значит, три поля не согласовали и разбирать их будет человек.
Код обмена пишется за дни, карта полей согласуется неделями. Не потому, что она сложная, а потому, что на половину вопросов в ней может ответить только заказчик.
Восемь слов из сметы и что каждое значит в деньгах
Эти восемь слов покрывают почти всю смету на обмен. Читая коммерческое предложение, ищите их глазами: отсутствие слова в смете почти всегда означает отсутствие работы, а не её бесплатность.
| Слово | Что это по-русски | Что означает в смете и в сроках |
|---|---|---|
| API | Окно выдачи чужой системы: перечень операций, которые она согласна выполнить | Если окна нет, платите за обходной путь — файловый обмен, работу через экраны или программного робота. Это плюс 40–120% к цене прямой связки |
| Метод | Одна конкретная операция в этом окне: «создать заказ», «получить остаток», «изменить статус» | Единица счёта. Смета в 90 000 ₽ и смета в 400 000 ₽ отличаются числом методов, а не жадностью. Спрашивайте список методов, а не список систем |
| Вебхук | Обратный звонок: система сама сообщает о событии на ваш адрес | Нужен приёмник, доступный из интернета круглосуточно, и его сопровождение. Это хостинг, сертификат и дежурство — 3 000–8 000 ₽/мес сверх поддержки |
| Ключ доступа (токен) | Пароль машины к машине, по которому чужая система понимает, что запрос от вас | Кто-то должен его хранить, продлевать и отзывать при увольнении администратора. Это строка регламента, а не строка кода. Утёкший ключ — это доступ ко всем заказам сразу |
| Лимит (rate limit) | Сколько запросов в минуту чужая система соглашается принять от вас | Определяет длительность первой загрузки и то, можно ли вообще обещать «в реальном времени». При жёстком лимите первичная выгрузка 5 000 позиций занимает не час, а двое суток |
| Очередь | Буфер, куда складываются сообщения, пока получатель недоступен | 25 000–60 000 ₽ разово плюс своя инфраструктура. Взамен часовой сбой учётной системы перестаёт означать потерю заявок — они просто разберутся позже |
| Повтор (retry) | Правило «не получилось — попробовать снова через 5 секунд, потом через минуту, потом через пять» | 45 000–55 000 ₽ вместе с защитой от дублей. Без защиты повторы становятся не решением, а источником задвоенных заказов |
| Идемпотентность | Свойство операции: повторная отправка того же самого не создаёт второй документ | 5–10% работ, если заложить сразу. Разбор уже возникших дублей и склейка оплат стоит в разы дороже и делается вручную |
Найдите в коммерческом предложении слова «очередь», «повтор» и «журнал». Если ни одного из трёх нет, вам посчитали обмен для идеального мира, в котором обе системы всегда доступны. В реальном мире такой обмен встаёт молча, и вы узнаёте об этом от клиента.
Что ручной мост стоит в месяц
Пока интеграции нет, её работу делает человек: открывает заказ на сайте, переносит позиции в учёт, копирует контакт, ставит резерв. Это и есть точка отсчёта — с этим числом надо сравнивать смету, а не с нулём. Возьмём модельную компанию: 260 заявок в месяц, один менеджер держит перенос, ставка с налогами 1 100 ₽ за час.
Теперь сравним со сметой. Двусторонний обмен для такого объёма — 240 000 ₽ разово и 15 000 ₽/мес на поддержку. Чистая экономия составляет 43 730 − 15 000 = 28 730 ₽ в месяц, вложение окупается за 240 000 / 28 730 = 8,35 месяца, то есть на девятом. Это нормальная окупаемость: ориентир рынка при верно выбранном процессе — 3–6 месяцев для узких задач и до года для инфраструктурных, а обмен между системами относится ко вторым.
Дальше считается порог. Экономия на одной заявке — 168 ₽. Чтобы обмен окупал хотя бы собственную поддержку в 15 000 ₽/мес, нужно 15 000 / 168 ≈ 89 заявок в месяц. Чтобы он за два года окупил ещё и вложение — это 240 000 / 24 = 10 000 ₽ в месяц амортизации, — нужно 25 000 / 168 ≈ 149 заявок. Ниже 89 заявок интеграция не окупается никогда, между 89 и 149 окупается дольше двух лет, выше 149 — начинает приносить деньги.
Двухосевой график. Горизонтальная ось — число заявок в месяц от 0 до 300, вертикальная — расходы в рублях в месяц от 0 до 55 000. Растущая прямая подписана «ручной перенос, 168 ₽ за заявку» и в точке 260 заявок помечена значением 43 730 ₽. Горизонтальная прямая на уровне 25 000 ₽ подписана «интеграция: поддержка 15 000 ₽ плюс амортизация вложения 10 000 ₽». Точка пересечения на 149 заявках выделена и подписана «порог окупаемости». Вторая, пунктирная горизонталь на 15 000 ₽ подписана «только поддержка» с отметкой пересечения на 89 заявках. Оси и подписи по-русски.
«У них есть API» — ещё не значит, что будет дёшево
Фраза «у них открытый API» обычно произносится как аргумент в пользу дешевизны. На практике она гарантирует только одно: обходной путь через экраны и файлы не понадобится. Всё остальное остаётся открытым, и вот четыре причины, по которым наличие API не делает интеграцию дешёвой.
- 1API есть, но не на то, что вам нужно
Метод отдаёт остатки по складу целиком, а вам нужен остаток по одной позиции в момент оформления заказа. Приходится тянуть весь справочник и фильтровать у себя — а это упирается в лимит запросов и превращает «мгновенный остаток» в «остаток пятиминутной давности». Работа по обходу таких ограничений — 15–30% сметы.
- 2Не хватает полей
В чужом API нет поля «скидка по акции», «серия» или «код маркировки». Его либо кладут в комментарий и потом разбирают текстом, либо дорабатывают на стороне отправителя. Второе честнее и дороже: это отдельная задача у другого подрядчика и отдельное согласование сроков.
- 3Справочники не совпадают
Артикул на сайте и код номенклатуры в учёте — разные строки, названия складов написаны по-разному, у одного клиента три карточки контрагента. Сопоставление справочников на 5 000 позиций занимает 15–25% работ проекта и почти всегда требует участия ваших людей: подрядчик не знает, какие две карточки — один и тот же клиент.
- 4Обмен надо не написать, а эксплуатировать
Сам вызов метода пишется за день. Очередь, повторы, журнал обменов, мониторинг и тестовый контур — это остальные 60–70% сметы. Именно они отличают связку за 68 000 ₽ от интеграции за 398 000 ₽, и разницу мы разбираем построчно в соседнем материале про надёжную интеграцию.
Приёмник: третья система, о которой не говорят на первой встрече
В схеме «сайт и 1С» систем на самом деле три. Между ними стоит приёмник — небольшая программа, которая принимает события, ходит по чужим API, держит очередь, пишет журнал и следит за собой. Её не видно на демонстрации, о ней не спрашивают на первой встрече, и именно она чаще всего оказывается неучтённой строкой бюджета.
Приёмник нельзя разместить внутри учётной системы, и причина простая: он должен работать именно тогда, когда учётная система не работает. Обновление конфигурации, закрытие месяца, регламентные работы, перезагрузка сервера — во все эти моменты 1С недоступна, а заказы на сайте продолжают оформляться. Если приёмник живёт внутри неё, то в момент недоступности вебхуки просто некому принять, и события теряются безвозвратно: чужая система повторит отправку три-пять раз и перестанет.
Практическая часть выглядит так. Приёмнику нужен отдельный сервер — свой или арендованный в российском дата-центре, 3 000–8 000 ₽ в месяц в зависимости от нагрузки. Нужен адрес, доступный из интернета, и сертификат для него. Нужны обновления системного программного обеспечения — это часы работы администратора, а не разработчика. Развёртывание и настройка контура — 45 000–90 000 ₽ разово, и эта строка в сметах регулярно отсутствует, потому что «сервер же у вас есть».
Два вопроса, которые стоит задать про приёмник до подписания договора. Первый — чья инфраструктура: если приёмник развёрнут у подрядчика, вы арендуете собственный обмен и при расставании теряете его целиком. Второй — персональные данные: через приёмник едут имя, телефон и адрес покупателя, а значит, сервер должен быть в России, а в договоре с подрядчиком — поручение на обработку по 152-ФЗ. Как мы устраиваем контур доступа и разграничение прав, описано на странице «Безопасность»; это не формальность, а то, что проверяется при первом же инциденте.
Три признака, что обмен ваш, а не арендованный: приёмник развёрнут на вашем сервере, исходный код передан по акту, доступы выпущены на ваши учётные записи. Если хотя бы одного признака нет, смена подрядчика означает переписывание интеграции заново.
Что решаете вы, а не подрядчик
Есть три вопроса, которые подрядчик не имеет права решать за вас, потому что это не технические вопросы, а управленческие. Если он решит их сам, он решит их так, как проще писать код, и вы узнаете об этом через полгода, когда цена в учёте разойдётся с ценой на сайте.
| Вопрос | Почему подрядчик не может решить это за вас | Что зафиксировать в задании |
|---|---|---|
| Какая система главная по каждому полю | Он не знает, кто в компании отвечает за цену и кто за остаток. Ему всё равно, откуда брать значение | Построчно: цена — из учёта, описание и фото — с сайта, контакт — из CRM, остаток — из учёта. По каждому полю ровно один хозяин |
| Что делать при конфликте данных | Конфликт — это не ошибка программы, а расхождение двух правд. Решение всегда стоит денег кому-то в компании | Одно из трёх на каждое поле: перезаписать значением главной системы, оставить как есть и записать в журнал, или остановить обмен и позвать человека |
| Кому уходит оповещение о сбое и кто обязан отреагировать | Он не знает вашего графика, отпусков и того, кто в компании имеет право остановить отгрузку | Имя и канал: письмо на общий ящик никто не читает. Плюс срок реакции в рабочее время и что делать в выходные |
Схема из трёх систем-прямоугольников — «Сайт», «CRM», «1С (учёт)» — расположенных треугольником. В центре список полей: цена, остаток, описание и фото, контакт покупателя, статус заказа, дата отгрузки. От каждого поля идёт одна сплошная стрелка к системе-хозяину: цена и остаток и дата отгрузки — к 1С, описание и фото — к Сайту, контакт — к CRM, статус заказа — к 1С. Пунктирные стрелки от полей к остальным системам подписаны «только чтение». Внизу врезка «Правило конфликта: перезаписать / записать в журнал / остановить и позвать человека». Чертёжный стиль, подписи по-русски.
Если и сайт, и учёт имеют право писать цену, они начнут перезаписывать друг друга. Внешне это выглядит как «цены скачут», внутри это бесконечный цикл обмена, который ещё и съедает лимиты. Разбор такой ситуации на живой базе стоит 60 000–150 000 ₽ и всегда включает ручную сверку части позиций.
Что происходит, когда система на том конце не ответила
Это главный вопрос всей темы, и именно ответом на него отличается инженер от исполнителя. Учётная система будет недоступна — на обновлении конфигурации, на регламентных работах, на закрытии месяца, на перезагрузке сервера. Вопрос не в том, случится ли это, а в том, что произойдёт с заказом в этот момент.
Правильное поведение выглядит так. Заказ уже лежит в очереди, поэтому он никуда не денется. Обработчик пробует записать его в учёт и получает отказ. Он не бросает попытку и не повторяет её мгновенно тысячу раз — он ждёт по нарастающей: 5 секунд, минута, 5 минут, 15 минут, час. После пятой неудачной попытки, примерно через пятнадцать минут, в канал дежурного уходит сообщение с номером заявки и текстом ошибки. Заказ при этом остаётся в очереди и уедет автоматически, как только учётная система вернётся.
Горизонтальная лента времени от нуля до полутора часов. На ней шесть отметок: «0 — первая попытка, отказ», «+5 секунд — вторая попытка», «+1 минута — третья», «+5 минут — четвёртая», «+15 минут — пятая, уходит сообщение дежурному с номером заявки A-10482», «+1 час — шестая попытка, учёт вернулся, заказ записан». Под лентой сплошная полоса подписана «заказ всё это время лежит в очереди и не потерян». Справа контрастная врезка «без очереди: отказ на нулевой секунде означает потерю заявки». Подписи по-русски.
Неправильное поведение выглядит проще и стоит дешевле в разработке: обработчик получил отказ, записал ошибку в файл и пошёл дальше. Заявка потеряна, никто об этом не знает, и обнаружится это через два дня, когда клиент позвонит спросить про отгрузку. Второй вариант «дешёвого» поведения хуже первого: обработчик повторяет попытку без ключа операции и, когда связь восстанавливается, создаёт три одинаковых заказа. Механику этого мы подробно разбираем в материале про задвоенные заказы.
Три вопроса подрядчику на первой встрече
Эти три вопроса не требуют технических знаний, но отличают инженера от продавца за десять минут. Важен не сам ответ, а его структура: в хорошем ответе есть механизм и число, в плохом — уверенность.
- 1«Что произойдёт с заявкой, если 1С будет недоступна сорок минут?»
Плохой ответ: «такого не бывает», «мы повторим», «ничего страшного». Хороший ответ содержит слово «очередь», число попыток, интервалы между ними и порог, после которого зовут человека. Если очереди в проекте нет, вам должны прямо сказать, что при недоступности заявки теряются, и назвать цену очереди — 25 000–60 000 ₽.
- 2«Как вы гарантируете, что повтор не создаст второй заказ?»
Хороший ответ содержит слова «ключ операции» или «идемпотентность» и объясняет, кто этот ключ формирует — отправитель или получатель. Плохой ответ: «мы проверяем по номеру заказа». Номер заказа не годится, если номера присваиваются в двух системах независимо или если заказ можно отправить повторно после редактирования.
- 3«Как я узнаю, что обмен встал, раньше клиента?»
Хороший ответ — три механизма: сигнал присутствия каждые несколько минут, суточная сверка количеств между системами и счётчик ошибок с порогом. Плохой ответ — «мы смотрим логи». Логи смотрят после звонка клиента, а не до. Мониторинг стоит 50 000–85 000 ₽ и это отдельная строка, а не бонус.
Сравнение в три колонки и три строки. Первая колонка — вопросы: «Что будет с заявкой при недоступности 1С сорок минут?», «Как повтор не создаст второй заказ?», «Как я узнаю о поломке раньше клиента?». Вторая колонка помечена серым «Ответ, после которого стоит насторожиться»: «такого не бывает», «проверим по номеру заказа», «мы смотрим логи». Третья колонка выделена «Ответ по существу»: «очередь, шесть попыток с нарастанием до часа, сообщение дежурному после пятой», «ключ операции, формирует отправитель», «сигнал присутствия, суточная сверка количеств, счётчик ошибок — 50 000–85 000 ₽». Чертёжный стиль, подписи по-русски.
Когда интеграция не нужна
Интеграция — инфраструктура, и как всякая инфраструктура она имеет минимальный объём, ниже которого содержать её дороже, чем не иметь. Ниже — четыре ситуации, в которых мы сами отговариваем от обмена, и что делать вместо него.
- 1Меньше 89 заявок в месяц. Экономия в 168 ₽ на заявке не покрывает даже поддержку в 15 000 ₽/мес. Здесь работает регламент: менеджер переносит заявки пакетом дважды в день, а не по мере поступления, — и тратит на это 10 часов в месяц вместо 30.
- 2Данные нужны раз в месяц для отчёта. Если единственный потребитель обмена — управленческая отчётность, вам нужна выгрузка, а не интеграция: файл по расписанию в общую папку или в таблицу стоит 20 000–40 000 ₽ вместо 240 000 ₽ и ломается заметно реже. Живые дашборды имеет смысл строить позже, когда данные уже собираются регулярно.
- 3Процесс изменится через квартал. Меняете CRM, переезжаете на другой склад, запускаете маркетплейс — обмен придётся переделывать целиком, потому что он строится под конкретную пару систем. Дешевле пережить квартал вручную и построить обмен один раз под новую схему.
- 4Одна из систем не имеет ни API, ни файлового обмена. Здесь любая связка идёт через работу с экранами и стоит в полтора-два раза дороже прямой, а ломается при каждом обновлении интерфейса. Иногда правильный ответ — не строить мост, а заменить систему.
Предметная сцена в чертёжном стиле. Рабочий стол сверху: слева аккуратная стопка распечатанных заявок с наклейкой «26 штук, разбор дважды в день», рядом раскрытая таблица с колонками «номер», «клиент», «сумма», «перенесено». Справа — монитор, на экране строгий список строк журнала обмена с временем и статусами. Между ними линейка с отметками «89 заявок» и «149 заявок в месяц», подписанная «порог, после которого мост выгоднее рук». Приглушённая палитра, подписи по-русски.
Отдельно про пятый случай, который в списке не значится, но встречается чаще всех: обмен не нужен, пока не описан процесс. Если заявки сейчас теряются не в проводе между системами, а в голове менеджера, который забыл перезвонить, интеграция ускорит доставку данных в систему, где их всё равно никто не разбирает. Мы регулярно отговариваем от обмена именно по этой причине и предлагаем начать с описания процесса и правил распределения заявок — это дешевле, быстрее и часто снимает половину боли без единой строки кода.
Во всех остальных случаях вопрос не «делать ли обмен», а «какой». И здесь стоит держать в голове простую мысль: разработка самого обмена — меньшая часть денег. Большая часть — это очередь, повторы, журнал, мониторинг и тестовый контур, то есть всё, что нужно исключительно для исключений. Именно поэтому две сметы на одну и ту же задачу законно отличаются в пять раз, и именно поэтому дешёвая связка через год становится дороже дорогой.
