Коротко: консультации по требованиям интеграции — это работа, на которой до начала разработки выясняют, что именно и как должно обмениваться данными между системами. Итог — документ с описанием систем, форматов, полей, частоты обмена, ошибок и ответственных. Без этого этапа интеграции «всплывают» на этапе запуска и стоят дорого.
Что должно быть в требованиях
| Пункт | Что описываем |
|---|---|
| Системы | что с чем связываем (сайт ↔ 1С и т.д.) |
| Данные | товары, цены, остатки, заказы |
| Направление | кто «отдаёт», кто «принимает» |
| Способ | API, файлы, выгрузка по расписанию |
| Частота | в реальном времени или раз в час |
| Ошибки | что делать, если обмен не прошёл |
| Ответственные | кто даёт доступы и отвечает за данные |
Вкладки: этапы консультации
- Какие системы уже используются и кто их ведёт?
- Какой процесс сейчас и что в нём болит?
- Что должно автоматизироваться?
- Есть ли у систем API и кто даёт доступы?
- Кто отвечает за корректность данных?
Это «интервью»: важно понять бизнес-процесс, а не только технические детали.
Сопоставляем поля «источник → приёмник»:
- артикул товара ↔ код номенклатуры;
- цена ↔ цена в каталоге;
- остаток ↔ наличие на сайте;
- номер заказа ↔ заказ в учётной системе;
- статус заказа ↔ статус на сайте.
Здесь часто выясняется, что «одно поле» на самом деле состоит из трёх, и нужно правило преобразования.
- нет API — придётся работать с файлами;
- разные кодировки и форматы дат;
- обмен раз в сутки — цены «устаревают»;
- нет тестового контура системы;
- никто не отвечает за доступы;
- не описано поведение при сбое (дубли, потеря заказа).
Каждый риск превращаем в вопрос с ответственным и сроком.
Итоговый документ содержит:
- Схему: какие системы, кто с кем, в каком направлении.
- Таблицу полей: источник, приёмник, правило преобразования.
- Сценарии ошибок и правила повтора.
- Частоту и окна обмена.
- Требования к логам и мониторингу.
- Список доступов и ответственных.
- План тестирования и приёмки.
Практика: провести консультацию
- Соберите заказчика, бухгалтера и технического специалиста вместе.
- Пройдите по процессу «от заказа до отгрузки».
- Зафиксируйте, какие данные где меняются.
- Составьте таблицу соответствия полей.
- Выпишите вопросы к администраторам систем.
- Оформите документ и согласуйте его подписью/e-mail.
- Согласуйте этапы внедрения и приёмки.
Частые ошибки: причина → решение
| Ошибка | Последствие | Решение |
|---|---|---|
| «Сделайте как-нибудь» | переделки | собрать требования письменно |
| Забыли про остатки | продажа того, чего нет | описать обмен остатками |
| Нет правил ошибок | потеря заказов | описать повтор и логирование |
| Нет тестового доступа | тест «в бою» | запросить копию системы |
Проверьте себя
Вопросы и ответы
Владелец процесса, бухгалтер/операционист, администраторы систем и разработчик. Без «бизнеса» требования будут неполными.
Использовать обмен файлами (CSV/XML) по расписанию или промежуточную базу. Это медленнее, но работает без доступа к API.
По объёму: число сущностей, частота обмена, количество правил преобразования, объём логов и мониторинга. Чем больше сущностей, тем дороже.
Да. Люди уходят, память подводит, а спор «мы договаривались иначе» решается только письменными требованиями.
Итоги
- Консультация по интеграции — сбор требований до разработки.
- Нужны: системы, данные, направления, частота, ошибки, ответственные.
- Обязательна таблица соответствия полей.
- Тестовый контур и описанные сценарии ошибок — часть требований.
Комментарии
Пока комментариев нет — будьте первым, кто поделится мнением.