Автоматизация сбора разрозненных данных для BI/DWH в фарме: архитектура, варианты реализации и практические детали

Краткий вывод для руководителей

Программа-минимум (2–3 месяца): автоматизируем «конвейер файлов» от входа (почта/папки/SFTP) до предобработки (Python) и автоприкрепления исходных/преобразованных файлов в 1С, со справочниками сопоставления и базовыми DQ-проверками.
База на 12 месяцев: строим мини-платформу данных: посадочная зона, слой «как есть», слой «нормализовано», мастер-данные (товары/аптеки), оркестратор, мониторинг, витрины и отчеты. 1С перестает быть «хранилищем», а становится потребителем витрин.
Готовность к росту ×10: ключевые решения — файловая/объектная посадочная зона, схемно-управляемый парсинг, словари сопоставления, идемпотентные загрузки и прозрачный мониторинг качества.

Исходные вводные и ограничения

Источники: отчеты от аптек и поставщиков (Excel, CSV, кросс-таблицы, «экзотические» форматы, вероятно vendor-specific), плюс собственная CRM.
Каналы доставки: email (вложения), выгрузки в папки/на сетевые шары, потенциально SFTP/Web-порталы.
Текущая обработка: ручной запуск Python-скриптов → загрузка в 1С → ручное сопоставление новых значений со справочниками 1С.
Объемы: ~30 ГБ/мес., ~135 тыс. файлов/мес.; горизонт планирования — хранение ~3 лет; целевой рост ×10.
Бизнес-характер: большое разнообразие форматов и «капризных» файлов; много справочников и соответствий (номенклатура, аптеки, адреса, контрагенты); высокий риск человеческих ошибок и рассинхронизации справочников.

Целевая модель: «конвейер данных» (DataOps)

Логическая архитектура слоев

Landing / Ingestion (посадочная зона)
Физически: объектное хранилище (S3/MinIO) или файловая шина (SMB/NAS) с четкой иерархией папок и меток (поставщик/дата/канал/оригинальное имя файла/хэш).
Задача — сохранять все входящие файлы неизменными, с метаданными (кто/когда/откуда/контрольные суммы).
Raw (как есть)
Файлы и их мета, плюс журналы приемки, попыток парсинга, извлеченные «как есть» таблицы (без бизнес-нормализации).
Bronze (нормализовано технически)
Приведение к плоским таблицам (one-row-per-event), снятие кросс-таблиц (unpivot), стандартизация типов, дат, кодировок, валют, единиц измерения.
Silver (бизнес-нормализация)
Применение справочников сопоставления (товар, аптека, адрес, производитель и др.), очистка дублей, дедупликация, агрегации, валидация бизнес-правил.
Gold (витрины/март-модели)
Фактовые таблицы продаж/закупок/остатков, измерения (товар/аптека/канал/поставщик/клиент/календарь), быстрые агрегаты под BI-отчеты и выгрузки в 1С.
Delivery (потребители)
- 1С: автоматическое прикрепление исходных/преобразованных файлов, запись агрегатов;
- BI (FineBI/Power BI/др.): прямой доступ к витринам;
- CRM: обратные интеграции (события/результаты).

Управляющие контуры

Оркестрация: планирование, зависимости, ретраи, чекпоинты, SLA (Airflow / Dagster / NiFi).
Data Quality (DQ): правила на входе, в процессе и на выходе (контроль схемы, дубли, пропуски, баланс «закупки=продажи+остатокΔ», дедлайны файлов).
Метаданные: каталог наборов, схем, маппингов, версионность правил парсинга и нормализации.
Мониторинг/алерты: дашборды по статусам задач, задержкам, ошибкам парсинга, аномалиям DQ.

Варианты реализации (три «лестницы» зрелости)

Вариант A — «Лайт» (закрыть программу-минимум)

Где: ваш текущий сервер + сетевые папки/SMB;
Чем: Python-скрипты + лёгкий оркестратор (Airflow Standalone/Windows Scheduler/Cron), простая БД (PostgreSQL) для журналов и словарей;
1С-интеграция: через OData/HTTP-сервисы/COM или обменный каталог — автоприкрепление исходных/преобразованных файлов к объектам 1С;
Справочники сопоставления: таблички в PostgreSQL (товары, аптеки, адреса; правила нормализации названий/единиц).
DQ-минимум: проверка схемы/обязательных столбцов, дубликатов файлов (md5), «скользящее окно» по дедлайнам.
Плюсы: быстро, дёшево, минимальные изменения;
Минусы: ограниченная масштабируемость/наблюдаемость; сложнее поддерживать рост ×10.

Вариант B — «Сбалансированный» (мини-платформа данных)

Где: объектное хранилище (MinIO/S3) + БД (PostgreSQL/ClickHouse) + контейнеризация (Docker/K8s по желанию);
Чем: Airflow (оркестрация) + NiFi (потоки/файлы/почта/SFTP) или один из них, dbt (трансформации SQL в Silver/Gold), Great Expectations (DQ);
1С: API/обменные папки/внешняя компонента — с идемпотентной записью и журналами вызовов;
Плюсы: промышленная наблюдаемость, гибкая масштабируемость, быстрые витрины (ClickHouse);
Минусы: выше сложность и стоимость владения.

Вариант C — «Расширенный Lakehouse»

Где: S3-совместимое хранилище + движок запросов (Trino/Presto/Spark SQL) + табличный формат (Apache Iceberg/Delta/HCatalog) + ClickHouse для витрин;
Чем: оркестрация (Airflow/Dagster), трансформации (Spark/dbt Trino), DQ/Lineage (OpenMetadata/Amundsen+GE);
Плюсы: лучшая масштабируемость/разделение storage-compute, версионность таблиц, time-travel, ACID в файлах;
Минусы: избыточно, если BI-нагрузка средняя и главная боль — не big data, а разнообразие файлов.

Для вашего профиля нагрузок в 2025 г. практически всегда «стреляет» Вариант B. Его можно реализовать итеративно, начиная с A и «поднимаясь» без выкидывания сделанного.

Конвейер файлов: как закрыть «программу-минимум»

Источники → посадочная зона

Email: подключение по IMAP/POP3, фильтры по «от кого/тема/домены», парсинг вложений; правила «один файл — один идентификатор партнера/магазина/даты».
Папки/шары: файловые вотчеры (inotify/FileSystemWatcher) → мгновенная приемка, переименование по шаблону.
SFTP/порталы: плановые опросы, протокол квитанций (ack), повторные попытки.
Идентификация файла: partner_id + source_channel + yyyymmdd + original_name + md5; все в журнал приемки (PostgreSQL таблица ingestion_log).

Ключ: никогда не трогаем оригинал — только копия → hash → карантин (вирус/макросы) → Raw.

Нормализация Excel/CSV/кросс-таблиц

Excel-«зоопарк»: openpyxl/xlrd/pyxlsb (xlsb), распознавание заголовков, диапазонов, скрытых листов, auto-detect листа с максимальной плотностью табличных ячеек.
Кросс-таблицы: алгоритм unpivot: столбцы-признаки остаются, пересечения «товар×месяц» разворачиваются в строки (month, metric, value).
Приведение типов: даты → ISO, валюты/ЕИ → к базовым, числа → десятичные (точка), локали → ru_RU/en_US обработка.
Валидаторы: обязательные поля, набор допустимых значений, регулярки для кодов, проверка дубликатов строк по составному ключу.

Справочники сопоставления («MDM-лайт»)

Таблицы:
- dict_product (id_product, наименования и синонимы, производитель, ЕИ)
- dict_pharmacy (id_pharmacy, сеть, юрлицо, адрес, GLN/ИНН/внутренние коды)
- dict_supplier (id_supplier, ИНН, бренд-группа)
- map_product_alias (alias_text → id_product, confidence, источник, дата)
- map_pharmacy_alias (alias_text → id_pharmacy, адресное сопоставление с гео-нормализацией)
Механизм пополнения:
Автогенерация кандидатов сопоставления (fuzzy match, trigram, Jaro-Winkler, адресный нормализатор);
Веб-формы/тонкий UI для оператора: принять/отклонить → запись в map_*;
Версионность правил (чтобы можно было воспроизвести прошлые загрузки).

Идемпотентность, ретраи и чекпоинты

Идемпотентность: один и тот же файл с тем же md5 никогда не приводит к повторной загрузке фактов; статус «уже загружен».
Ретраи: падение шага → повтор через backoff (например, 5 мин/15 мин/60 мин) с лимитом попыток.
Чекпоинты: после каждой фазы — запись «чего выполнено» (ingested → parsed → normalized → mapped → loaded).
Единица работы: файл ≈ батч; для партнеров с «пачками» файлов — набор батчей с общей корреляцией (correlation_id).

Интеграция с 1С

Способы:
1. HTTP-сервисы/REST/OData 1С: регистрация документа/объекта + автоприкрепление файла (исходный и нормализованный);
2. Обменные каталоги: 1С «подбирает» из папки;
3. COM-автоматизация/внешняя компонента (если 1С-сервер на Windows).
Практика:
- Протоколируем каждый вызов (request/response, latency, payload size);
- Повторяемые попытки при 5xx/timeout;
- Контроль консистентности: если файл прикреплен, но запись витрины не создана → событие компенсации.

Модель данных (пример Silver/Gold)

Серебро (нормализовано, но «сыровато»)

silver_sales_raw

file_id, row_num, partner_id, pharmacy_alias, product_alias, date, qty, amount, uom, currency, loaded_at

Нормализованное серебро

silver_sales_norm

file_id, row_num, id_pharmacy, id_product, date, qty_base_uom, amount_local, amount_rub, fx_rate, loaded_at

Золото (витрины фактов/измерений)

dim_product, dim_pharmacy, dim_supplier, dim_date
fact_sales_daily

date_id, product_id, pharmacy_id, supplier_id, qty, revenue_rub, files_count, src_cov_pct

src_cov_pct (coverage %) — доля торговых точек/партнеров, приславших данные в срок; ключевая метрика качества источников.

Data Quality и мониторинг

Схема и типы: соответствие ожидаемым столбцам/типам, доля null, «хвосты» в числовых полях, отрицательные продажи и пр.
Временная полнота: SLA на приход файлов (например, до 10:00 следующего дня), тревоги при провале.
Бизнес-правила: суммы по справочникам, балансировки (остаток на конец = остаток на начало + приход − расход ± корректировки).
Аномалии: week-over-week отклонения, внезапные нули/пики по SKU/точке.
Дашборды платформы:
- «Тепловая карта» поставщиков/сетей vs дни — что пришло/не пришло;
- Очередь/статусы DAG’ов;
- TOIL оператора (сколько маппингов в очереди на подтверждение).

Выдача аналитики

В 1С:
- Прикрепленный исходник и «плоский» нормализованный файл;
- Запись агрегатов (например, продажи по SKU×день×аптека) для внутренних актов/печатных форм.
В BI:
Прямые подключения к Gold (PostgreSQL/ClickHouse);
Слои: «Оперативные продажи», «Остатки», «Покрытие источников», «Качество данных»;
Ролевой доступ (коммерция, операции, финансы, IT).

Технологический стек (практичные подборки)

«Импортонезависимый» ядро

Хранилище файлов: MinIO (on-prem), S3-совместимое облако;
БД журналов/словари: PostgreSQL;
Быстрые витрины: ClickHouse;
Оркестратор: Apache Airflow (с формализованными DAG’ами) или Dagster;
Потоки/файлы/почта: Apache NiFi (IMAP/SFTP/File/HTTP Listen → Route → PutS3/PutFile);
Трансформации SQL: dbt (Silver/Gold);
DQ: Great Expectations;
Каталог/Метаданные: OpenMetadata/Amundsen (по желанию, на 2-й волне).

«Только Python» (самый быстрый старт)

Watchdog (файлы), imaplib (почта), paramiko (SFTP), pandas/openpyxl, fastapi (микро-API), APScheduler, SQLAlchemy (в PostgreSQL), loguru.
Плюс тонкий UI (FastAPI + React) для подтверждения сопоставлений.

Эксплуатация, безопасность, аудит

Журналы неизменяемы (append-only), события храним ≥ 90 дней в БД и ≥ 1 год в объектном хранилище.
Конфиденциальность: шифрование at-rest (SSE-S3/KMS) и in-transit (TLS), секреты в Vault/диспетчере секретов, маскирование PII в логах.
Доступы: сервисные учетные записи, principle of least privilege, аудит всех действий оператора по маппингам.
Бэкапы: политики версионирования бакета, PITR для PostgreSQL, snapshot’ы для ClickHouse.

Производительность и сайзинг (оценочно)

135 тыс. файлов/мес. ≈ 4 500/сутки. При средней обработке 50–200 мс/файл на этап «приемка/мета/складирование» достаточно 2–4 воркеров.
Нормализация Excel: «дорогой» этап — распараллеливание по файлам и/или по листам; при 8–16 воркерах время окна загрузки укладывается в ночное окно.
ClickHouse для витрин легко тянет десятки миллионов строк в сутки при умеренной аппаратуре (NVMe + 64–128 ГБ RAM).
Рост ×10: горизонтальное масштабирование воркеров/потоков; разделение очередей по партнерам/сегментам; вынос CPU-емких операций (Excel→CSV) на отдельный пул.

План внедрения (пошагово)

Волна 0 (2–3 недели): Прояснение и PoC

Биение форматов (собираем «топ-20» типовых отчетов и «самые злые»), целевая номенклатура, карта справочников.
PoC: приемка email+папки → нормализация 3 типов → запись в PostgreSQL/ClickHouse → автоприкрепление в 1С → базовый DQ-дашборд.

Волна 1 (2–3 месяца): «Программа-минимум» в проде

Конвейер приемки, нормализация, словари сопоставления с UI, автоприкрепление файлов, журналы и алерты.
Витрина «Продажи по дням» и «Качество источников». Обучение операторов.

Волна 2 (3–6 месяцев): Мини-платформа

Объектная посадочная зона, оркестратор (Airflow/NiFi), dbt-слой (Silver/Gold), Great Expectations, расширенный мониторинг, SLA.
Мастер-данные (товары/аптеки) с процессом гашения дублей и версионностью.

Волна 3 (6–12 месяцев): Расширение

Новые источники/каналы, обратные интеграции в CRM, аналитика качества партнеров, экономические модели (LFL, эластичности).

Команда и роли

Product Owner (бизнес-заказчик) — приоритизация правил/отчетов/SLA.
Data Architect — слои/модель/паттерны загрузки/идемпотентность.
Data Engineer — пайплайны, парсеры, оркестратор, DQ.
MDM/Data Steward — справочники/маппинги/качество мастер-данных.
1С-разработчик/интегратор — API/обмен/права/прикрепления.
DevOps — контейнеры, CI/CD, секреты, мониторинг.
Аналитик BI — витрины, KPI, отчеты, роли.

Примеры реализации (псевдо)

Шаблон распознавания кросс-таблиц (идея)

По каждому листу считаем «плотность» табличного блока;
Ищем заголовочную строку (max доля строковых+дата столбцов в верхней трети);
Столбцы с месяцами/периодами переводим в period;
Значение — в value; остальные колонки — признаки.

Идемпотентная загрузка (SQL-скелет)

-- Стол записей файлов
CREATE TABLE staging.files (
  file_id uuid primary key,
  partner_id text,
  md5 char(32) unique,
  received_at timestamptz,
  status text
);
-- При попытке загрузить повторно тот же md5 — конфликт и early exit
INSERT INTO staging.files(file_id, partner_id, md5, received_at, status)
VALUES (:file_id, :partner_id, :md5, now(), 'received')
ON CONFLICT (md5) DO NOTHING;

DQ-правило «обязательные поля»

SELECT file_id, count(*) AS bad_rows
FROM silver_sales_raw
WHERE product_alias IS NULL OR pharmacy_alias IS NULL OR date IS NULL
GROUP BY file_id
HAVING count(*) > 0;

Риски и как их гасить

«Зоопарк» форматов меняется без уведомлений → версионируемые профили парсинга по партнеру, Canary-проверка первых n файлов.
Ошибки маппинга → неверная аналитика → «чёрные ящики» правил запрещены: все маппинги видимы, трассируются и одобряются стюардами.
Задержки поставщиков → мониторинг coverage, публикуемые SLA и еженедельные отчеты с «красными» сетями.
Зависимость от 1С → 1С только потребляет/прикрепляет; первичное хранилище — вне 1С (S3+БД).
Рост ×10 → ранняя горизонтализация воркеров и очередей, статeless-подход, изоляция CPU-тяжелых задач.

Бюджетные ориентиры (порядки, не сметы)

Вариант A (минимум): усилия 2–3 чел.-мес., инфраструктура — существующие сервера, open-source;
Вариант B (мини-платформа): 6–10 чел.-мес. первый год (с построением MDM-лайт/DQ/оркестрации/витрин) + 1–2 FTE сопровождение;
Вариант C (lakehouse): имеет смысл лишь при кратном росте задач и команды (данные ≫ 100 ГБ/мес., много типов аналитики/ML).

Что вы получите на каждом этапе

После Волны 1: безлюдный конвейер приемки/нормализации, автоприкрепление в 1С, первый DQ-дашборд, снижение ручного труда на 60–80 %.
После Волны 2: повторяемая, документированная платформа с витринами под BI, отчетность о качестве партнеров, прозрачные SLA.
После Волны 3: масштабирование по источникам и анализам без «ломки» основы.

Приложение: чек-лист запуска PoC на ваших данных

Топ-20 файлов от 10 разных партнеров (с «плохими» кейсами)
Справочник товаров и аптек (как есть) + все известные «синонимы»
Учетные данные тестовой почты/папки/каталога обмена
API-эндпоинт 1С на тестовом контуре (или каталог обмена)
Согласованный SLA (например, «файлы до 10:00; отчеты до 12:00»)
KPI PoC: процент авто-парсинга, доля строк без ручного маппинга, латентность E2E, число алертов/1000 файлов

Когда файлы очень разные

1) Профили источников (контракты на вход)

На каждый канал/партнера — свой профиль: ожидаемые листы/разделители, кодировка, ключевые поля, типы, паттерны заголовков, правила unpivot.
Версионирование: profile_id=partner_123_v4. При смене шаблона у партнера вы добавляете v5, а старые файлы продолжают разбираться по v4.
Мини-DSL/конфиг (yaml/json), без правки кода:
- где искать заголовок,
- какие столбцы обязательны,
- как маппить «Янв/Фев/…» → month,
- локаль чисел/дат,
- регулярки для артикулов/ИНН и т.д.

2) Авто-распознавание (когда профиля нет или он «промахнулся»)

Эвристики: ищем самый «плотный» табличный блок, определяем строку заголовка, распознаём месяцы/даты, «кросс-таблицы» → в строки (unpivot).
Сигнатуры: по нескольким прошлым файлам строим признаки (набор названий столбцов, частоты, типы) и пытаемся «узнать» источник.
Результат: либо выбираем существующий профиль, либо создаём черновик нового и отправляем на подтверждение стюарду (человеку).

3) Адаптеры форматов

Excel/CSV — штатно.
Редкие форматы (xlsb, многолистовые отчёты, zip во вложениях) — через специализированные парсеры.
PDF-отчёты — по возможности избегаем; если нельзя, отдельный OCR-поток с ярлыком «низкое доверие» и обязательной верификацией.

Классы ошибок и что с ними происходит

Делите ошибки на 5 классов — так проще автоматизировать реакцию:

Структурные (не читается файл/лист, нет заголовка, «сломанная» кодировка).
- Действие: файл → карантин, тикет с логом парсера, ретрай N раз (экспоненциально), уведомление поставщику (если есть контракт) и стюарду.
Схемные (нет обязательных колонок, неожиданное имя колонки, тип не совпал).
Действие: проверка «мягкого» маппинга заголовков (синонимы), если не удалось — карантин с классом «schema_mismatch» и предложением создать/обновить профиль.
Действие: DQ-ошибка в Silver-слое: строки помечаем флагом, весь файл не валим, а пропускаем «хорошие» строки, «плохие» — в репорт. Порог допустимой доли брака — настраиваемый (например, ≥95% валидных строк — грузим).
Действие: авто-генерация кандидатов сопоставления (fuzzy-поиск), запись в «очередь маппинга». При подтверждении человеком — перезагрузка только «подвисших» строк (чекпоинт).
Действие: алерт «coverage» (покрытие источников), политика дубликатов по (partner_id, period, md5): повторно не грузим.
Содержательные (пустые ключи, отрицательные количества, несуществующие коды).
Справочные/ссылочные (новые товары/аптеки, которых нет в справочниках).
Временные/SLA (файл не пришёл в срок, пришёл «задним числом», дубликаты).

Поток обработки с защитой от «плохой погоды»

Приёмка: кладём оригинал в «посадочную» зону, считаем md5, пишем мета в ingestion_log.
- Если md5 уже видели — идемпотентно выходим (никаких повторных фактов).
Определение профиля: известный профиль → парсим; нет — авто-детект → черновик профиля → на утверждение.
Нормализация: приводим к плоской таблице, типы, локали, unpivot; пишем в silver_raw и протоколируем процент успешно нормализованных строк.
DQ-проверки: обязательные поля, типы, диапазоны, бизнес-правила (например, revenue >= price*qty*0.8).
Если провалено «жёсткое» правило (нет ключевого поля) → файл в карантин.
«Мягкие» — помечаем строки, грузим «здоровую часть».
Не нашли — в очередь ручного подтверждения с авто-кандидатами. После утверждения — догружаем недостающее (чекпоинт «mapping_complete»).
Справочники: маппим алиасы (товары/аптеки) к внутренним id.
Загрузка в витрины (Gold) и прикрепление в 1С: и исходник, и нормализованный файл — через API/обменник, с логированием и ретраями.
Мониторинг и алерты: статус DAG’ов, процент брака, латентность, покрытие по партнёрам/датам. Линейки метрик уходят в дашборд + e-mail/Telegram.

Как выглядит «протокол ошибок» (пример)

Состояния файла: received → parsed → normalized → dq_checked → mapped → loaded
Терминальные статусы: loaded_ok, quarantine_schema, quarantine_content, quarantine_security, duplicate_ignored.
Политика ретраев: 3 попытки с backoff 5/15/60 минут для технических сбоев (I/O, API 1С, сетевые ошибки).
SLA: «Файлы за D приходят до D+1 10:00; витрины обновлены до 12:00». Нарушение → алерт.
Карантин: отдельный бакет/каталог с метками причины и ссылкой на лог; авто-очистка по TTL (например, 60 дней).

«Человек-в-петле», но по минимуму

Очередь маппинга (товар/аптека/адрес): оператор видит список «новых строк» + 3–5 лучших кандидатов сопоставления → один клик «принять».
Правила версионируются: каждая правка фиксируется (кто/когда/из чего → во что), чтобы воспроизвести прошлые расчёты.
Порог вмешательства: настройка «если доля немаппленных > X% — стоп загрузку и зови оператора».

Примеры проверок и реакций

Проверка схемы (обязательные колонки):

SELECT file_id, count(*) AS bad_rows
FROM silver_raw
WHERE date IS NULL OR product_name IS NULL OR qty IS NULL
GROUP BY file_id
HAVING count(*) > 0;
Если bad_rows/total_rows > 0.2 — статус quarantine_schema.

Дубликаты файлов (идемпотентность):

INSERT INTO ingestion_files(md5, partner_id, received_at)
VALUES (:md5, :partner_id, now())
ON CONFLICT (md5) DO NOTHING;  -- вторичную загрузку пресекаем

Бизнес-правило (значение неотрицательно):

SELECT file_id
FROM silver_norm
WHERE qty < 0 OR amount < 0
GROUP BY file_id;

Если встречается — помечаем строки is_suspect=1, агрегаты считаем по «чистым».

Скользящие форматы и «падения» на практике

Когда партнёр внезапно меняет шапку: авто-детект создаёт черновик профиля v{n+1} и шлёт алерт «нужна валидация новой версии».
Когда Excel с макросами/вирусами: проверка в песочнице; при срабатывании — quarantine_security, уведомление без попыток распаковки.
Когда прошёл дубликат с новым именем: спасает md5 + бизнес-ключ (partner, period); дубликат не загрузится вторично.
Когда 1С не отвечает: ретраи с backoff; после 3 неудач — статус «partial_loaded», задача компенсации (повторить только шаг 6).

Показатели «здоровья» процесса (что вы видите в дашборде)

Coverage % по партнёрам/дням/сетям (кто прислал вовремя).
Auto-parse % (доля файлов разобрались без участия).
Mapping backlog (сколько сущностей ждёт подтверждения, SLA закрытия).
Bad rows % по классам ошибок.
Latency E2E (приёмка → витрина → 1С).
Source scorecard (по каждому партнёру: регулярность, качество, скорость реакции).

«Совсем разные» файлы — решается профилями источников + авто-распознаванием и версионированием.
Ошибки не «роняют» процесс: есть карантин, ретраи, чекпоинты, частичная загрузка «здоровых» строк и человек-в-петле только там, где нужен.
Всё измеримо: покрытие, брак, бэклог маппингов, латентность, отчёт по поставщикам.

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

Корпоративный стандарт Sell-In / Sell-Out

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

Планирование промо в FMCG