Сам обмен данными — ещё не результат для бизнеса. Результатом может стать заказ, который дошёл до обработки без повторного ввода, или статус, на основании которого сотрудник понимает, что делать дальше.
Начните с одного сценария
Условный пример: оптовый покупатель отправляет заказ через сайт, затем менеджер переносит состав заказа в CRM и уточняет наличие на складе. Предположим, повторный ввод занимает время и иногда требует исправлений.
Пройдите этот путь вместе с сотрудником: что он получает и дополняет, где ждёт ответа, кому передаёт результат. Возможно, ввод данных стоит автоматизировать. А возможно, задержка возникает потому, что никто не отвечает за подтверждение наличия. Тогда одного обмена недостаточно.
Определите вход и конечный результат
Для первой оценки нужны названия участвующих систем, пример входных данных и понятное описание результата. В случае заказа — какие сведения о товарах, количестве и покупателе передаются, где появляется запись и кто начинает с ней работать.
Важно определить, какая система отвечает за каждое значение. Например, сайт собирает пожелания покупателя, а наличие и окончательную цену подтверждает сотрудник в учёте. Интеграция не должна незаметно превращать предварительную заявку в подтверждённый заказ.
Назначьте ответственного со стороны бизнеса: он подтвердит, что результатом действительно можно пользоваться.
Проверьте готовые возможности
До собственной разработки стоит посмотреть штатные подключения, выгрузки и настройки действующих программ. Если нужный путь закрывается готовым решением или изменением порядка работы, нет смысла создавать ещё один модуль.
Для нестандартного обмена нужно выяснить, разрешает ли система получать и изменять необходимые данные, кто предоставляет доступ и какие ограничения действуют. Внешний обмен с 1С и изменение её внутренней конфигурации — разные работы.
Обсудите не только успешную передачу
Предположим, заказ сохранился, но сайт не получил ответ. При повторной попытке должна появиться не вторая заявка, а понятный результат по той же операции. Изменение заказа при этом нужно отличать от повтора.
До разработки согласуйте поведение при недоступности другой системы, неверных данных и изменении заказа. Сотруднику должно быть понятно, что обработано, что требует внимания и какое действие разрешено дальше. Эти ситуации включают в приёмку.
Сформулируйте проверяемую пользу
Гипотеза может звучать так: после изменения менеджер реже вводит одни сведения повторно, а заказ быстрее переходит к обработке. До начала работы фиксируют текущий путь и показатели: повторные действия, исправления, время между поступлением и принятием заказа.
После внедрения сравнивают тот же процесс на сопоставимых заказах. Если проверяется потеря заявок, нужно сверять поступившие и обработанные обращения, а не только число записей в CRM. Освободившееся время само по себе не равно экономии денег: важно, на какие задачи его сможет направить команда.
Согласуйте состав первого этапа
В предложении сначала фиксируется результат, затем этапы, состав работ и оценка. Отдельно указываются границы: что входит, что остаётся в действующей системе и по каким примерам принимается обмен. Поддержка, лицензии и регулярные расходы внешних сервисов обсуждаются отдельно.
«До результата — без доплат за наши ошибки».
Разрабатываем системы, кабинеты и интеграции. Если при приёмке наше решение не выполняет согласованную задачу — переделываем без доплаты. Новые требования согласуем отдельно.
Для начала достаточно описать один обмен: какие системы участвуют, что сейчас делает сотрудник и какой результат ему нужен. Пароли и полная база клиентов для первого разговора не требуются.
