Три уровня данных в системе розлива

Управляемый розлив удобно разделять на три уровня: коммерческий, логический и физический. Коммерческий уровень приходит из POS и описывает продажу. Логический уровень — цифровое право и его правила. Физический уровень — попытки и результаты операций на станции.

Если один из уровней отсутствует, отчётность становится неполной. Продажи без операций не показывают фактическое использование, а операции без продажи не дают коммерческого контекста.

Какие данные нужны от POS

Для связи с продажей обычно достаточно стабильного идентификатора заказа или позиции, идентификатора ресторана, типа продукта и времени события. Дополнительные поля зависят от сценария и архитектуры заказчика.

Важно не собирать данные «на всякий случай». Для каждого поля должно быть понятно, какое решение или проверку оно поддерживает.

Для сетевого проекта особенно важен единый справочник точек и продуктов. Если один и тот же напиток или ресторан имеет разные идентификаторы в нескольких системах, слой интеграции должен иметь понятное правило сопоставления.

Что хранить о цифровом праве

Право должно иметь собственный уникальный идентификатор, тип сценария, состояние и набор применяемых правил. Также нужна связь с исходным коммерческим событием и областью действия.

Состояние права меняется во времени: оно может быть создано, активно, исчерпано, просрочено или отозвано. История таких изменений помогает объяснять решения системы.

Полезно хранить версию политики, по которой право было создано или проверено. Если правила изменились, это позволяет корректно объяснить исторические операции и не применять новую конфигурацию задним числом к старым событиям.

Что фиксировать при каждой операции

Для попытки использования важны время, право, точка, станция и результат проверки. При отказе нужно хранить код или категорию причины: срок, лимит, интервал, неверная точка, неизвестное право или другое условие.

Успешная операция также должна иметь уникальный идентификатор. Это помогает защищаться от дублей при повторной доставке событий и связывать технические журналы с бизнес-отчётностью.

Время события следует трактовать аккуратно: полезно различать время фактического действия и время получения записи сервером. При кратковременном офлайне эти значения могут расходиться, и отчётность должна понимать эту разницу.

Какие технические данные полезны от станции

Для эксплуатации полезно отделять бизнес-отказы от технических проблем. Поэтому состояние связи, ошибки контроллера, недоступность станции и другие диагностические события лучше хранить отдельно от решения по праву.

Так операционная команда видит, где гость получил отказ из-за правила продукта, а где операция не состоялась из-за инфраструктуры.

Какие отчёты можно построить

Базовая отчётность показывает созданные права, использованные права, успешные и отклонённые операции, причины отказов и среднее число операций на право. Для сети добавляются сравнение ресторанов и динамика по периодам.

Следующий уровень — сверка продаж и использования, поиск нетипичных последовательностей и оценка влияния изменений правил на поведение гостей.

Для операционной команды отдельный отчёт по причинам отказов часто полезнее общего процента успешности. Рост категории «неверная точка» и рост технических таймаутов требуют совершенно разных действий.

Минимальная модель для первого запуска

На пилоте не обязательно строить полноценное хранилище данных. Достаточно обеспечить идентификаторы продажи, права и операции, журнал решения, привязку к точке и экспорт основных событий.

Если эти данные структурированы с первого дня, расширение аналитики не потребует пересобирать сам механизм розлива.

Минимальная модель должна быть расширяемой. Если идентификаторы и события определены правильно, позже можно подключить BI, централизованную отчётность или дополнительные источники данных без изменения QR-кода и гостевого сценария.

Не собирайте данные просто потому, что можете

У систем автоматизации есть соблазн логировать всё подряд. В итоге через год появляется огромное хранилище событий, которыми никто не пользуется, а нужный ответ всё равно приходится собирать вручную. Для QR CTRL полезнее начинать с вопросов бизнеса и эксплуатации.

Если задача — понять фактическое использование, нужны стабильные связи между продажей, правом и операцией. Если задача — диагностировать станцию, нужны технический статус, время и идентификатор устройства. Всё остальное имеет смысл добавлять только тогда, когда для него есть понятный сценарий использования.

Хорошая модель данных отличается не количеством полей, а тем, что по ней можно быстро ответить на реальный вопрос: почему этот гость получил отказ, что происходило на этой станции в 18:42 и совпадает ли использование права с тем, что продала касса.

Практический принцип: Данные должны позволять восстановить цепочку «продажа → право → проверка → результат». Всё остальное — расширение этой базовой модели.
← Все материалыОбсудить ваш проект →