DWH в сетях ресторанов Доставка и цифровые каналы - Консолидация данных заказов из собственных приложений агрегаторов и POS

Современная сеть ресторанов с множеством точек обслуживания и различными каналами продаж сталкивается с необходимостью единого видения заказов. Заказы приходят из собственных мобильных приложений и веб-сайтов, через агрегаторы доставки, через POS-терминалы в зале и на вынос, а иногда - через партнерские программы лояльности. Без консолидации этих источников данные о выручке, времени исполнения заказа, эффективности доставки и JJ-компонентах становятся раздробленными, что приводит к угрозам точности аналитики и неэффективной операционной эксплуатации. В этой главе рассматривается архитектура DWH, которая обеспечивает единый источник истины для заказов по всей сети, описываются подходы к моделированию данных, процессам интеграции и качеству данных, а также приводится практический набор паттернов внедрения.

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

Архитектура DWH для Delivery и цифровых каналов обеспечивает единый источник фактов заказов, агрегирует данные по ресторанам и каналам и поддерживает реальные сценарии аналитики: от операционных KPI до бизнес-инсайтов по клиентскому пути.
Модель данных в виде звездной схемы упрощает агрегацию по каналам, времени и статусам, позволяет быстро разворачивать витрины продаж по ресторанам, регионам и сетям.
Интеграции источников требуют строгой стратегии идентификаторов и сопоставлений, чтобы обеспечить идемпотентность и корректность сопоставления заказов между собственными приложениями, агрегаторами и POS.
Конвейеры и контроль качества данных обеспечивают своевременность и точность загрузок, мониторинг линий данных и управление изменениями без прерываний в пользовательской аналитике.
Безопасность и соответствие требованиям важны для обработки платежной информации и персональных данных клиентов, а также для соблюдения регламентов отрасли и региональных норм.

Архитектура и данные источников

Архитектура DWH в сетях ресторанов должна отражать многоканальность и различие в требованиях к данным по источникам. Основной принцип - централизованный консолидированный слой, который обеспечивает единый набор бизнес-метрик и единое определение сущностей заказа. В реальной практике это означает наличие трех основных слоев: источники данных, слой интеграции и консолидации (staging и canonical моделирование), и аналитический слой (DWH/март).

Источники данных
- Собственные приложения и веб‑платформы ресторана: заказ в приложении, онлайн-оплата, привязка лояльности, промо‑коды, программы вознаграждений.
- Агрегаторы доставки: DoorDash, Uber Eats, Яндекс Еда и другие локальные игроки. Они предоставляют детализированные данные по каждому заказу, но с различной структурой и временем задержки.
- POS‑системы: кухонная POS‑терминология и TSE (table service) для учета dine‑in заказов, а также кассовые аппараты и интеграции с электронными платежами.
- Внешние данные и аналитика: платежные провайдеры, отзывы, лояльность и маркетинговые платформы.
Архитектурная модель
- Каноническая модель данных и звездная схема, где факт-заказы связан с измерениями ресторана, канала продаж, времени, статуса заказа, клиента, способа оплаты и продукта.
- Архитектура ELT/ETL в связке с конвейерами потоков данных (CDC и stream processing) обеспечивает как точность, так и своевременность. Данные из источников попадают в landing/staging‑слой, затем нормализуются и загружаются в канонический слой и далее в аналитическую витрину.
Инфраструктура хранения
- В условиях сетей ресторанов часто применяют гибридные решения: облачное хранилище (data warehouse) плюс data lake или lakehouse для сырых данных и машинного обучения. Такой подход позволяет быстро организовать пилоты, а затем масштабировать в сеть.
- Важно поддерживать версионирование схем, обеспечить хранение временных копий источников для аудита и снижения рисков потери данных.
Интеграция и конвейеры
- Реализация событийно-ориентированной архитектуры: события заказов из приложений и агрегаторов публикуются в брокер сообщения (Kafka/PKI‑пулы) и обрабатываются на этапе интеграции.
- CDC‑потоки с POS и онлайн‑платежами позволяют минимизировать задержки и сохранять консистентность между источниками и хранилищем.
- Уровень трансформации в ELT‑порядке позволяет сохранять детальные данные в staging, а затем использовать SQL‑операторы для их агрегации и построения факт‑таблиц и размерностей.

Концептуальная схема архитектуры может выглядеть так:

Источники данных -> Landing/Staging -> Канонический слой (канонические таблицы) -> Фактово‑измерительные слои -> Витрины и BI/аналитика
В приоритете - поддержка реального времени для KPI операционных дашбордов и пакетной загрузки для глубокого анализа.

Ниже приведен упрощенный пример DDL, отражающий базовую звездную схему канонической модели заказов. В реальных проектах синтаксис зависит от выбранной СУБД (Snowflake, BigQuery, Redshift и т. п.), однако концепция сохраняется.

CREATE TABLE dim_restaurant (
  restaurant_id BIGINT PRIMARY KEY,
  name VARCHAR(255),
  city VARCHAR(100),
  region VARCHAR(100),
  chain VARCHAR(100)
);

CREATE TABLE dim_channel (
  channel_id INT PRIMARY KEY,
  channel_name VARCHAR(50),
  description VARCHAR(255)
);

CREATE TABLE dim_time (
  date_key DATE PRIMARY KEY,
  year INT,
  month INT,
  day INT,
  day_of_week INT,
  quarter INT
);

CREATE TABLE dim_customer (
  customer_id BIGINT PRIMARY KEY,
  email_hash VARCHAR(64),
  phone_hash VARCHAR(64),
  segment VARCHAR(50),
  is_company BOOLEAN
);

CREATE TABLE dim_order_status (
  status_id INT PRIMARY KEY,
  status_name VARCHAR(50)
);

CREATE TABLE dim_payment_method (
  payment_method_id INT PRIMARY KEY,
  method_name VARCHAR(50)
);

CREATE TABLE dim_product (
  product_id BIGINT PRIMARY KEY,
  name VARCHAR(255),
  category VARCHAR(100),
  price DECIMAL(10,2)
);

CREATE TABLE fact_order (
  order_id BIGINT PRIMARY KEY,
  restaurant_id BIGINT REFERENCES dim_restaurant(restaurant_id),
  channel_id INT REFERENCES dim_channel(channel_id),
  customer_id BIGINT REFERENCES dim_customer(customer_id),
  date_key DATE REFERENCES dim_time(date_key),
  status_id INT REFERENCES dim_order_status(status_id),
  payment_method_id INT REFERENCES dim_payment_method(payment_method_id),
  order_total DECIMAL(12,2),
  tax_total DECIMAL(12,2),
  delivery_fee DECIMAL(12,2),
  discount_amount DECIMAL(12,2),
  service_fee DECIMAL(12,2),
  commission DECIMAL(12,2),
  created_at TIMESTAMP,
  delivered_at TIMESTAMP
);

## CREATE TABLE fact_order_item (
  order_id BIGINT REFERENCES fact_order(order_id),
  product_id BIGINT REFERENCES dim_product(product_id),
  quantity INT,
  unit_price DECIMAL(10,2),
  total_price DECIMAL(12,2),
  PRIMARY KEY (order_id, product_id)
);

Важная деталь: для идентификации и сопоставления заказов между источниками полезна единая таблица сопоставления идентификаторов, например:

canonical_order_id - основной идентификатор заказа в DWH
source_system - источник (own_app, aggregator_door, aggregator_ubereats, pos)
source_order_id - идентификатор заказа в источнике

Пример сопоставления может быть представлен так:

source_system	source_order_id	canonical_order_id	notes
own_app	OA-5678	ORD-202605-000123	связка через order_linking_id
aggregator_door	DD-4321	ORD-202605-000124	совпадение по времени и сумме

Такой подход позволяет устранить дубли и обеспечить идемпотентность загрузок.

Модель данных и схемы консолидации

Ключевая идея состоит в создании канонической модели, которая служит единой точкой сопоставления для всех источников. Это обеспечивает сопоставление и сравнение показателей across sources, что в свою очередь позволяет корректно рассчитывать общую выручку сети и проводить cross-channel анализ.

Каноническая модель
- Факты: фактические заказы, детали предметов заказа, доп. услуги (упаковка, чаевые, сбор за доставку и т. д.).
- Измерения: ресторан, канал продаж, время, статус заказа, способ оплаты, клиент.
Зачем звезда?
- Упрощает агрегацию по различным уровням: по точкам продажи, по каналам, по регионам.
- Обеспечивает гибкость для анализа за периоды (месяц, квартал) и сегментов клиентов.
Важность временной размерности
- Реализация размерности времени с правильными атрибутами: дата, год, месяц, день недели, праздники, сезонность.
- Поддерживает анализ задержек: от создания заказа до доставки, между статусами.

Пример сопоставления источников и канонических сущностей ниже иллюстрирует принципы:

Путь от источника к канону
- own_app → CANON_ORDER
- aggregator_door → CANON_ORDER
- pos → CANON_ORDER
- доставочные статусы и оплаты - через каноническую размерность.

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

Интеграции источников: идентификаторы, сопоставление и согласование

Ключевым вызовом является выравнивание идентификаторов между различными источниками. В рамках консолидации заказов важно:

Определить единый канонический идентификатор заказа (canonical_order_id), который будет использоваться во всех последующих слоях. Для этого необходима строгая политика сопоставления:
- Уникальные сочетания: restaurant_id, time, customer_id, сумма заказа, и источник.
- В случаях несовпадения времени - применяем окна допуска (например, +/- несколько секунд/минут) и дополнительные проверки по полям order_total, delivery_address и статусу.
Определить shadow‑идентификаторы для каждого источника:
- source_system, source_order_id - идентификатор в исходной системе.
- Механизм маппинга: периодическая сверка между canonical_order_id и источниками, чтобы выявлять несоответствия и исключения (например, отмены, возвраты, дубликаты).
Обрабатывать дубликаты и идемпотентность:
- При повторной загрузке тех же данных система должна игнорировать дубликаты, не меняя итоговую информацию.
- Вводим "deduplication key" на уровне staging/ETL, основанный на сочетании source_order_id и source_system и дополнительной валидации.

Ниже приведена упрощенная таблица сопоставления и пример стратегии сопоставления для визуализации процессов:

source_system	source_order_id	canonical_order_id	notes
own_app	OA-5678	ORD-202605-000123	связывается через order_linking_id
aggregator_door	DD-4321	ORD-202605-000124	совпадение по времени и сумме
pos	POS-7890	ORD-202605-000125	перепроверка статуса через API

Процедура сверки может включать этапы:

сбор и нормализация полей заказа (order_total, delivery_fee, taxes, discounts).
расчёт времени выполнения (turnaround_time) как разности между created_at и delivered_at.
проверку константности между canonical_order_id и источниками (соответствие сумм и статусов).

Для кодируемого примера можно рассмотреть следующий упрощенный механизм вставки/обновления в staging и далее в факты:

-- пример упрощённого синтаксиса MERGE (диалект зависит от СУБД)
MERGE INTO fact_order AS f
USING staging_orders AS s
ON f.order_id = s.canonical_order_id
WHEN MATCHED THEN
  UPDATE SET
    f.order_total = s.order_total,
    f.delivery_fee = s.delivery_fee,
    f.commission = s.commission,
    f.status_id = s.status_id,
    f.delivered_at = s.delivered_at
## WHEN NOT MATCHED THEN
  INSERT (order_id, restaurant_id, channel_id, customer_id, date_key,
          status_id, payment_method_id, order_total, delivery_fee,
          discount_amount, service_fee, created_at, delivered_at)
  VALUES (s.canonical_order_id, s.restaurant_id, s.channel_id, s.customer_id,
          s.date_key, s.status_id, s.payment_method_id, s.order_total,
          s.delivery_fee, s.discount_amount, s.service_fee, s.created_at, s.delivered_at);

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

Конвейеры данных, качество и управление изменениями

Эффективная архитектура требует не только точности, но и управляемости. Основные принципы:

Выбор подхода к конвейеру
- Реал‑тайм конвейер на базе потоковых технологий (Kafka/Spark Streaming) позволяет обновлять витрины и дашборды в реальном времени или близи реального времени. Это полезно для мониторинга SLA и оперативной реакции.
- Пакетные конвейеры (Airflow, Dagster) используются для глубокой аналитики и обработки больших объёмов данных, когда скорость не критична и требуется сложная обработка.
Управление качеством данных
- Проверки полноты: наличие обязательных полей (order_id, restaurant_id, date_key, total).
- Проверки уникальности и идемпотентности: отсутствие дубликатов заказов в фактах и деталях.
- Проверки согласованности: корректность сумм, соответствие между фактом и деталями по станциям оплаты и доставки.
- Метрики качества данных: доля пропусков, задержка (latenсy), процент некорректных записей, время жизни конвейера, статистика ошибок.
Прослеживаемость и аудит
- Логирование трансформаций, версионирование схем и аудит изменений.
- Инструментарий каталога данных и линейности (lineage): кто залил данные, какие процессы переработали их, какие зависимости между конвейерами.
Репликация и консистентность
- Использование паттернов консистентности по источникам, частотность обновления, обработка окон времени, компенсационные процедуры при сбоях.
- Поддержка откатов и восстановления после ошибок, тестирование конвейеров на синтетических данных и регрессионное тестирование.

Ниже приведен пример набора качественных SQL‑правил, применяемых на этапе ETL/ELT:

-- базовые правила качества данных
SELECT COUNT(*) AS total_rows FROM staging_orders;
SELECT COUNT(DISTINCT order_id) AS unique_orders FROM staging_orders;
SELECT COUNT(*) FILTER (WHERE order_total Мониторинг конвейеров и ошибок - обязательная часть операционной практики. Рекомендовано хранить дашборды по SLA конвейеров, времени отгрузки в витрины, доли успешных загрузок в течение суток и т. д. Кроме того, следует реализовать процедуры уведомления при достижении пороговых значений, чтобы оперативно реагировать на проблемы с источниками данных или задержки в каналах.
 
Безопасность, консолидация и соответствие требованиям
Консолидация заказа в рамках DWH требует соблюдения вопросов конфиденциальности и безопасности данных. В контексте сетей ресторанов это особенно актуально из-за обработки PII клиентов, финансовых транзакций и данных платежей.

Безопасность и доступ
- Реализация принципа наименьших привилегий через RBAC и абонентские политики.
- Шифрование данных на месте хранения и в движении (TLS/SSL, Transparent Data Encryption).
- Разграничение доступа к данным по ролям: аналитики, операционные пользователи, менеджеры по маркетингу.
Конфиденциальность и правовые требования
- Защита персональных данных клиентов: маскирование, токенизация и минимизация хранения PII там, где это возможно.
- Соблюдение PCI DSS и локальных регламентов платежной отрасли для полей оплаты и транзакций.
- ПолитикаRetention: сроки хранения отдельных слоёв данных, архивирование и безопасное уничтожение.
Управление данными и консолидация
- Контракты данных между командами: какие поля передаются из источников, какие данные перерабатываются внутри DWH, какие витрины доступны для аналитиков.
- Валидация и аудит: журнал изменений, метаданные источников, версии схем, аудиторские трассы для соответствия требованиям аудита.
Механизмы обеспечения защиты от ошибок
- Шифрование ключей и секретов, хранение в секрет‑менеджерах.
- Многофакторная аутентификация для доступа к критическим системам.
- Регулярные проверки на соответствие политик и обновления безопасности.

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

Реализация и операционная практика: паттерны внедрения

Эффективное внедрение DWH дляDelivery и цифровых каналов требует пошаговой стратегии и нормативов. Рекомендованы следующие элементы:

Этапность внедрения
- Этап 1: пилот на ограниченном наборе ресторанов и каналов (например, 2-3 ресторана, 2 агрегатора) с минимальным охватом источников.
- Этап 2: расширение на сеть и добавление новых каналов, внедрение канонической схемы и базовых витрин.
- Этап 3: полноценная аналитика на уровне всей сети, включая модель прогноза спроса и оптимизацию операционных процессов.
Организация данных
- Контракт данных: определение источников, полей, ошибок и процессов обновления.
- Соглашение об уровне качества (SLA) для загрузок и обновлений.
Нормализация процессов
- Единая логика обработки платежей, времени и статусов заказа.
- Единая бизнес‑логика для расчета такс, сборов, чаевых и комиссий агрегаторов.
Управление изменениями
- Контроль версий схем и конвейеров, регрессионное тестирование, управление зависимостями.
- Регулярные ревью дайн-сетей и обновления канонической модели в рамках бизнес‑потребностей.
Команды и роли
- Data Architect, ELT/ETL Инженеры, Data Quality Engineer, DataOps/Platform Engineer, Data Analysts, Product Owners.
- Взаимодействие между IT, бизнес-подразделениями и командами по маркетингу для своевременного получения требований и проверки результатов.

Практически, успешная реализация требует наличия повторяемых шаблонов: data contracts, шаблоны загрузок, конвейеры, набора тестов и концепций жизненного цикла схем. Эти паттерны обеспечивают ускорение внедрения в рамках сети ресторанов и снижают риски при добавлении новых каналов и источников.

Key takeaways

Единая каноническая модель заказов позволяет синхронизировать данные из собственных приложений, агрегаторов и POS, обеспечивая аналитическую сопоставимость по всей сети.
Архитектура DWH должна балансировать между реальным временем и глубокой аналитикой: использовать потоковую обработку для операционных KPI и пакетные конвейеры для углубленного анализа.
Ключ к успеху - грамотное сопоставление идентификаторов заказов между источниками, идемпотентные загрузки и качественная обработка дубликатов.
Стратегии качества данных и мониторинга конвейеров критичны для устойчивости аналитических витрин и доверия к ним.
Безопасность и соответствие требованиям должны охватывать PII, платежные данные и регуляторные нормы; политики доступа и анонимизации должны быть встроены в архитектуру.
Внедрение DWH - поэтапный процесс: пилот, масштабирование, выверенная операционная практика и четкие data contracts между участниками процесса.
Эффективная DWH‑практика требует взаимодействия между бизнес‑подразделениями и IT: общая языковая база, прозрачные правила загрузки и четкая роль ответственности.

FAQ

Что такое каноническая модель данных и зачем она нужна в DWH для сетей ресторанов?

Каноническая модель - это единый набор сущностей и связей, который используется как общая основа для всех источников заказов: собственных приложений, агрегаторов и POS. Она обеспечивает единое определение заказов, клиентов, времени и продуктов вне рамок конкретной платформы. Это упрощает агрегацию, сравнение и аналитическую работу, снижает дублирование логики преобразования и обеспечивает консистентность показателей между каналами. Без канонической модели аналитика по сети становится раздробленной, что затрудняет принятие решений и повышает риск ошибок в KPI.

Как выбрать подход ETL vs ELT в проекте DWH для ресторанной сети?

Выбор зависит от требований к времени обработки, объема данных и доступности вычислительных ресурсов. ETL целесообразен, когда нужна строгая предобработка данных на стороне источников и ранняя фильтрация, а также когда инфраструктура ограничена. ELT - предпочтителен в среде облачных хранилищ с мощными вычислительными возможностями: данные сначала загружаются сырыми в Data Lake/Stage, затем выполняются трансформации прямо в хранилище. В DWH дляDelivery и цифровых каналов обычно применяется гибрид: критически важные поля и сопоставления - через ELT, а специфические бизнес‑правила - через ETL на стадии подготовки.

Какие источники данных являются наиболее критическими для консолидации?

Основные три блока: собственные приложения (заказы через веб/мобильное приложение), агрегаторы (партнерские платформы для доставки) и POS‑системы (кухня и оффлайн‑обслуживание). Также важны платежные данные и программы лояльности. Критичность зависит от масштаба сети и частоты обновления: агрегаторы могут предоставлять данные с задержкой и частично неоднозначно, поэтому необходимы строгие процедуры согласования и повторной загрузки. В сумме, для аналитики оперативной эффективности и финансовых KPI критически важны все три источника.

Как решить задачу согласования идентификаторов заказов между собственным приложением, агрегаторами и POS?

Необходимо определить единый канонический идентификатор и поддерживать таблицу сопоставления, где каждому источнику сопоставляются его source_order_id и status, а также связь с canonical_order_id. Важны строгие правила обработки дубликатов, а также процедуры для отмен и повторной подачи заказов. Пример: при загрузке данных из разных источников проверяем уникальность по парам (source_system, source_order_id) и связываем запись с canonical_order_id через правила в staging/ETL. Регулярно запускаем сверку сумм и статусов для выявления расхождений.

Как обеспечить корректную временную координацию между заказами из разных источников?

Временны́е размерности должны учитывать часовой пояс источника, задержки в ETA и фактическое время доставки. Часто применяют универсальное время (UTC) в канонической модели и хранят в dim_time атрибуты локальных по каждому рынку, чтобы корректно отображать графики вовлеченности и сезонные паттерны. Для передачи данных между системами важно соблюдать единый формат времени и единые правила нормализации временных зон.

Какие показатели стоит держать в BI‑слое для Delivery и цифровых каналов?

KPI по каналу: общая выручка, средний чек, валовая прибыль, комиссии агрегаторов; KPI по времени: среднее время обработки заказа, время ожидания курьера, время доставки; операционные KPI: доля успешных доставок, процент вовлечения клиентов, конверсия по каналам; качество и полнота данных: доля пропусков и ошибок, SLA загрузок. Кроме того, следует контролировать равномерность посылок по ресторанам и регионам и проводить cross-channel анализ для выявления перекрытий и оптимизации ассортимента.

Как обеспечить безопасность и соответствие требованиям в DWH?

реализуется RBAC, шифрование данных в покое и в движении, маскирование PII, токенизация, управление секретами, а также механизмы аудита и журналирования. Важно определить политику хранения данных и регламент по удалению данных, чтобы обеспечить соответствие GDPR, PCI DSS и локальным регуляциям. Регулярно проводятся аудиты и обновления по безопасности, а данные выделяются в защищенных пространствах и доступ к ним предоставляется только уполномоченным ролям.

Какие технологии лучше применить для реализации конвейеров?

Для потоковой передачи данных - Kafka (или альтернативы) в сочетании с Spark Streaming/Apache Flink для реального времени; для оркестрации - Airflow или Dagster. Для хранения и аналитики - Snowflake, BigQuery или Redshift в зависимости от предпочтений по облаку. В качестве инструментов мониторинга - Prometheus/Grafana, Data Observability платформы. Важно выбрать экосистему, которая обеспечивает хорошую интеграцию со стыковками источников и простоту поддержки и масштабирования.

Как выстроить дорожную карту внедрения DWH для сетей ресторанов?

Рекомендована пошаговая дорожная карта: начальный пилот на ограниченном наборе источников и сценариев; детальная настройка канонической модели и базовых витрин; расширение на сеть и добавление новых каналов; внедрение расширенных витрин и аналитики (прогнозы спроса, оптимизация маршрутов доставки); постоянное совершенствование процессов управления данными, обеспечение безопасности и соответствия требованиям; формирование команды и владельцев данных, а также развитие data contracts. Важно устанавливать конкретные KPI для каждой стадии внедрения и проводить регулярные ретроспективы по качеству данных и бизнес-эффекту.

Какие метрики качества данных полезно отслеживать в контексте DWH для ресторанной сети?

Доля пропусков по ключевым полям (order_id, restaurant_id, channel_id, date_key); доля дубликатов и некорректных записей; соответствие между суммами заказов и суммами детализации; задержки обновления между источником и витриной; точность категорий и названий продуктов в витрине; консистентность между фактом заказа и фактами item‑деталей. Регулярные сверки и автоматизированные тесты данных помогают своевременно выявлять проблемы и минимизировать риск ошибки в бизнес‑показателях.

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

← Предыдущая статья

DWH в сетях ресторанов Управление персоналом - Создание базы для оптимизации планирования смен и нагрузки персонала

Следующая статья →

DWH в сетях ресторанов Доставка и цифровые каналы - Хранение детальных статусов заказов для анализа времени сборки доставки и отмен