Одна операция вместо сотен
Спроектировала единый центр управления ЭДО для сети ресторанов с массовой привязкой и контролем состояния подключений
О проекте
У сети ресторанов (до 600 заведений) настройка ЭДО осуществлялась в каждом ресторане отдельно: одно действие повторялось сотни раз, а проверить, все ли заведения получают документы, было нечем.
Я спроектировала единую страницу настроек ЭДО для сети и окно массовой привязки. Организация ЭДО назначается сразу группе ресторанов, а не по одному. Отдельный контролл показывает пропуски: ресторан без "ящика" не получает документы, а это расхождения с поставщиками, потерянные время и деньги.
Контекст
iikoWeb — система автоматизации ресторанного бизнеса. Развитие ЭДО - стратегически важное направление, так как «90% документооборота в ресторане осуществляется через ЭДО» (цитата из спеки)
Бизнес-процесс
Каждый шаг процесса упирается в ограничение системы:
| Что делает пользователь | Ограничение, с которым это связано |
|---|---|
| Регистрирует аккаунт у оператора ЭДО — Saby, Контур.Диадок или Астрал, чтобы документы приходили в iiko | Аккаунтов у одного ресторана может несколько: их заводят разные сотрудники. Сейчас к ресторану можно подключить только один аккаунт |
| Создаёт внутри аккаунта юрлицо — почтовый ящик, куда приходят накладные от поставщиков | В одном аккаунте может быть несколько юрлиц, и их названия не совпадают с юрлицом в iiko |
| Привязывает ящик к ресторану, чтобы накладные попадали в админку этого ресторана | У одного ресторана ящиков может быть несколько — отдельно бар, отдельно кухня. У одного ящика — тоже несколько ресторанов |
Проблемы
- К заведению подключался только один оператор ЭДО и одна организация внутри этого аккаунта: ресторан получал чужие документы, нужно было разбираться вручную, либо не получал их совсем
- Настройка повторялась в каждом заведении: для сети из 500 точек — 500 раз одно и то же
- Не было единой картины, какая организация к какому ресторану привязана
- Проверить полноту нечем: пропущенный ресторан находили только когда документы не приходили
Дискавери
- Изучила бизнес-процесс, терминологию, составила блок-схемы. Изучила пользовательский сценарий AS IS, посмотрела другие настройки ЭДО и структуру раздела
- Изучила обращения в поддержку: 0 обращений, т.к. проект в стадии пилотирования, клиентов мало
- Посмотрела аналитику в Matomo за 30 дней. В среднем пользователи находятся 106 секунд на странице (дольше, чем в настройках в соседних разделах), 31% отказов, 37% выходов (можно предположить, что пользователь не знает, как решить задачу)
- Сделала бенчмаркинг массовых операций: смотрела Jira (bulk change), Битрикс24 и прочие админки: там модель «выбрал много → применил одно значение», предусмотрен путь массовой отвязки, подтверждение только на разрушающем действии, фильтрация и поиск
Гипотезы
Предполагаю, что инструмент массовой привязки организаций ЭДО сократит время подключения сети ресторанов как минимум в два раза, потому что пользователю больше не нужно повторять одну и ту же настройку в каждом заведении вручную
Что измеряем:
- Время настройки новой сети: от входа в раздел до готовой привязки всех заведений. Цель — минимум вдвое быстрее ручной привязки
- Возвраты на страницу в течение недели (сигнал, что настройку не закончили)
- Matomo: время на странице и отказы должны упасть
Предполагаю, что единый интерфейс управления настройкой ЭДО снизит число ситуаций, когда ресторан остаётся без привязанной организации и не получает документы, потому что пропуск видно до сохранения, а не после того, как документ не пришёл
Что измеряем:
- Доля заведений без привязанной организации. Цель — ноль
- Сколько сетей, увидев предупреждение о пропусках, закрывают их сразу, а не сохраняют неполную настройку
- Обращения «не приходят документы»
Ограничения
- Одна и та же организация (ИП «Ресторан») может быть доступна через двух операторов ЭДО - нужно показывать как одну сущность
- Юрлицо в iiko и организация у оператора — разные сущности
- Снятие привязки останавливает поступление документов — разрушающее действие, нужно предупреждать
- В таблице до 600 строк: без поиска и фильтров работать нельзя
Решение
В начале работы я выделила три основных ветки пользовательских сценариев:
- подключение операторов ЭДО
- привязка для небольшой сети или единичного ресторана (1-5)
- привязка для большой сети (от 5 и больше)
Что спроектировала
-
Пустое состояние страницы настроек ЭДО
-
Контроль состояний подключений (какие операторы подключены, аккаунты внутри, статус подключения). Если у части ресторанов нет почтовых ящиков — сверху предупреждающий баннер
-
Массовое назначение. Отмечаем рестораны чекбоксами или выбираем все отфильтрованные, нажимаем кнопку, выбираем организации из общего списка, подтверждаем: «Назначить 6 ресторанам»
-
Точечное назначение прямо из ячейки. Правка одного ресторана без массовых операций: открыл ячейку, выбрал организацию, назначил
-
Отвязка всегда через диалог. Подтверждение называет рестораны, организацию и последствие. Молча снять привязку нельзя
-
Фильтры и поиск по ресторанам
-
Тоггл «Без привязки организации»: оставляет в таблице только рестораны без ящика
-
Одна организация из двух операторов не задваивается (единая сущность)
-
Слетевшая авторизация видна в таблице, а не только на экране подключений
Результаты
Функционал в разработке. Ожидаем, что внедрение нового функционала позволит продавать модуль ЭДО для крупных сетей, что привлечет дополнительный источник прибыли для бизнеса
Рефлексия
- Самое сложное — не спроектировать массовую операцию, а договориться, что делать с частичными ошибками: откатывать прогон целиком или оставлять успешные привязки. Выбрали второе и показали это в интерфейсе явно.
- Что изменилось в понимании — в массовых действиях дизайн отвечает за предсказуемость, а не за скорость. Одна непонятная ошибка в прогоне на 300 строк дороже, чем десять ручных шагов.
- Что сделала бы лучше — раньше подключила бы поддержку к исследованию. Их контекст про реальные ошибки оказался точнее, чем отчёты аналитики.
Следующий кейс