Коммерческое предложение на интеграцию систем: что писать и как считать
Интеграция отличается от обычной разработки тем, что обе стороны обмена уже существуют и менять их, как правило, нельзя. Есть учётная система с одним набором полей, есть сайт или сторонний сервис с другим, и задача — заставить их обмениваться данными без ручного переноса. Поэтому предложение строится вокруг того, что именно передаётся: какие сущности, в какую сторону, в каком формате, с какой частотой и что считается признаком успешной передачи. Формулировка «настроить обмен между системами» не задаёт ни одного из этих параметров, и обсуждение объёма после неё неизбежно расходится.
Вторая особенность — зависимость от чужой стороны. Доступ к API, документация, тестовый контур, лимиты на число запросов и сроки ответа поставщика системы находятся вне контроля команды разработки. Отдельная сложность — справочники: у номенклатуры, контрагентов и статусов заказов в двух системах свои коды и наименования, и без правил сопоставления обмен превращается в дубли записей. В предложении стоит заранее зафиксировать, кто получает доступы, кто отвечает за приведение справочников в порядок и как ведут себя системы, когда одна из них недоступна.
Из каких блоков собрать предложение
Перечислите участвующие системы с версиями и способом размещения: коробочная на сервере заказчика, облачная, самописная. Укажите, кто владеет каждой стороной и у кого есть доступ к её настройкам. Отдельно назовите системы, которые в обмен не входят, чтобы граница проекта не расширялась по ходу работ.
Опишите обмениваемые сущности по отдельности: товары, остатки, цены, заказы, оплаты, контрагенты, статусы. Для каждой укажите направление передачи и перечень полей. Односторонняя выгрузка и двусторонняя синхронизация — разные по трудоёмкости задачи, и это должно быть видно в предложении.
Зафиксируйте метод обмена для каждой стороны: обращение к готовому API, обмен файлами по расписанию, промежуточная очередь, вызовы по событию. Назовите форматы данных и способ авторизации. Если у стороннего сервиса есть ограничения по числу запросов за период, укажите их — они влияют на выбранную схему.
Опишите, по какому признаку записи двух систем считаются одной и той же: артикул, внешний идентификатор, код контрагента. Укажите правила сопоставления статусов и единиц измерения, а также порядок действий, когда соответствие не найдено. Отдельно назовите, кто со стороны заказчика отвечает за чистоту справочников.
Задайте частоту обмена для каждой сущности и порядок действий при сбое: число повторных попыток, интервал между ними, журнал ошибок, уведомление ответственного. Опишите, что происходит при недоступности одной из систем и как данные догружаются после восстановления связи.
Считайте от числа интеграций, направлений обмена и сопоставляемых справочников, добавляя часы на разбор чужой документации и тестирование. Отдельно вынесите работы, объём которых заранее не известен: приведение справочников в порядок, доработку стороны заказчика, поддержку изменений в чужом API.
Опишите, как проверяется результат: тестовый контур, контрольный набор данных, сверка итогов за период. Зафиксируйте сроки предоставления доступов заказчиком и порядок сопровождения после запуска, включая реакцию на изменения на стороне сторонних сервисов.
Что обычно входит в смету
- Обследование систем и анализ документации APIсистема
- Описание состава и направлений обменасущность
- Проектирование схемы обменаинтеграция
- Реализация выгрузки и загрузки данныхметод обмена
- Правила сопоставления записейсправочник
- Преобразование форматов и единиц измеренияполе
- Настройка расписания обменасценарий
- Обработка ошибок и повторные попыткисценарий
Блоки, смета с расчётом и условия уже готовы — останется вписать свои цены. Клиент открывает ссылку в браузере, а вы видите, кто её открыл и докуда дочитал.