От данных к решению: что происходит до дашборда

АНАЛИТИКА // DATA_PIPELINE_FLOW

Когда руководитель открывает дашборд и видит выручку, остатки, количество заказов или эффективность подразделения, кажется, что данные просто «подтянулись» из нескольких систем.

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

Данные могут прийти из 1С, CRM, сайта, складской системы, производственного оборудования, Excel-файлов или внешнего API. В каждом источнике свои идентификаторы, форматы, правила обновления и представление одних и тех же сущностей. Один источник может считать заказ созданным в момент оформления, другой — после подтверждения, а третий вообще работать только с проведёнными документами.

[ ФУНДАМЕНТ АНАЛИТИКИ ]

Поэтому дашборд начинается не с визуализации.

Он начинается с ответа на гораздо более важный вопрос:
Каким данным можно доверять и как превратить разрозненные записи в единую картину бизнеса?

Упрощённо путь выглядит так:

И чем серьёзнее аналитика, тем важнее каждый этап до последнего блока.

ПРОЕКТИРОВАНИЕ // BI_METRICS_VALIDATION

Почему дашборд не является источником аналитики

Самая распространённая ошибка — начинать проект с визуальной части.

Выбирается BI-система, рисуется несколько графиков, добавляются фильтры, карточки показателей, диаграммы. На встрече всё выглядит убедительно.

[ КОЛЛИЗИЯ ДАННЫХ ]

«Почему здесь 14 820 заказов, а в CRM 14 391?»

И начинается настоящее расследование.

Оказывается, одна система считает отменённые заказы, другая — нет. Где-то учитываются тестовые записи. Где-то дата заказа берётся по времени создания, а где-то по времени оплаты. Один клиент может существовать под двумя идентификаторами.

Визуально всё может быть идеально.

Но если исходные данные и правила расчёта не определены, BI просто красиво показывает проблему.

Поэтому правильная последовательность выглядит иначе:

Дашборд — это последний слой, а не место, где должна решаться проблема качества данных.

КАРТИРОВАНИЕ // DATA_SOURCES_MAPPING

Первый вопрос: откуда вообще берутся данные

До построения аналитического контура нужно составить карту источников.

Источник	Что содержит	Особенность
CRM	клиенты, сделки, менеджеры	операционные данные
1С	документы, оплаты, остатки	бухгалтерская логика
Сайт	заказы, заявки	события в реальном времени
WMS	складские операции	движение товара
Excel	планы, корректировки	ручное изменение
API	внешние показатели	сторонний источник

На этом этапе важно не просто перечислить системы.

Нужно понять, какая система является владельцем каждого типа данных.

Это принципиально важно.

Если один показатель можно получить из пяти мест, ещё не значит, что все пять источников равноправны.

СТАНДАРТИЗАЦИЯ // SINGLE_SOURCE_OF_TRUTH

Источник истины должен быть определён заранее

Представим, что company хочет вывести показатель «Выручка».

Где её брать?

[ СИСТЕМА CRM ]

В CRM есть сумма сделки.

[ E-COMMERCE ]

В интернет-магазине есть стоимость заказов.

[ УЧЕТ 1С ]

В 1С есть проведенные документы.

[ ЭКВАЙРИНГ ]

В платёжной системе есть фактически полученные деньги.

Все значения могут отличаться — и каждое при этом может быть правильным.

Проблема не в данных.

Проблема в том, что под словом «выручка» разные системы понимают разные вещи.

Поэтому перед построением отчёта необходимо определить:

Например:

Выручка = сумма проведённых документов за период без НДС, с учётом возвратов.

После этого становится понятно, какие данные нужны и какая система должна использоваться как основной источник.

Без такого определения аналитика превращается в спор о цифрах.

ОБЪЕДИНЕНИЕ // MASTER_DATA_MAPPING

Один и тот же клиент может оказаться несколькими клиентами

Особенно сложная задача возникает при объединении данных.

[ СИСТЕМА CRM ]

ID: 1842

ООО «Ромашка»

[ УЧЕТ 1С ]

Код: 00001842

ООО "Ромашка"

[ БАЗА САЙТА ]

customer_id: 57291

[ ФАЙЛ EXCEL ]

Таблица:

Ромашка ООО

Человек понимает, что это одна организация.

Компьютер — нет.

[ ДУБЛИРОВАНИЕ ИЗ-ЗА НАПИСАНИЯ ]

Если просто объединить таблицы по названию, быстро появятся ошибки:

ООО «Ромашка»
Ромашка ООО
Ромашка
ООО Ромашка

Для аналитики это могут оказаться четыре разных клиента.

Поэтому интеграционный контур должен иметь механизм сопоставления сущностей — master data или mapping.

И только после такого сопоставления можно уверенно анализировать клиента во всех системах.

ИНЖЕНЕРИЯ_ДАННЫХ // DATA_INGESTION_LAYER

Сбор данных — это отдельная инженерная задача

Источники редко отдают данные одинаково.

ПРОТОКОЛЫ_ПЕРЕДАЧИ // INGESTION_PROTOCOLS

› Одна система предоставляет REST API.
› Другая позволяет выгружать CSV.
› Третья отдаёт данные через SQL.
› Четвёртая присылает события через webhook.
› Пятая вообще не имеет нормального механизма интеграции.

Поэтому слой сбора должен уметь работать с разными способами получения данных.

При этом важно не смешивать получение данных с их бизнес-обработкой.

Источник должен отвечать за передачу. А последующие слои — за преобразование и интерпретацию.

СТРАТЕГИЯ_ETL // DATA_LOADING_STRATEGY

Полная загрузка и инкрементальная загрузка — разные вещи

Допустим, в CRM уже находится 10 миллионов записей.

Каждую ночь выгружать все 10 миллионов ради того, чтобы получить 5 000 новых и изменённых, — далеко не всегда разумно.

Поэтому применяют инкрементальную загрузку:

[ ПЕРВЫЙ ЗАПУСК ]

› 10 000 000 записей
› Полная загрузка

[ СЛЕДУЮЩИЙ ЗАПУСК (ИНКРЕМЕНТ) ]

› Изменения после 02:00
› 5 000 записей

Но и здесь есть нюансы.

РИСКИ_ИДЕНТИФИКАЦИИ // INCREMENTAL_RISKS

› Не каждая система корректно хранит дату изменения.
› Иногда запись может измениться без обновления нужного поля.
› Иногда удаление вообще не передаётся.

Поэтому стратегия загрузки должна учитывать поведение конкретного источника.

ОЧИСТКА_ДАННЫХ // DATA_CLEANSING_STAGE

Данные редко приходят чистыми

После получения информации начинается этап, который часто недооценивают.

Например, одна система передала:

[ ФОРМАТ 1 ]

+7 999 123-45-67

[ ФОРМАТ 2 ]

89991234567

[ ФОРМАТ 3 ]

79991234567

Для человека это один номер.

Для системы — разные строки.

Такие различия возникают постоянно:

КЛАССИФИКАЦИЯ_КОЛЛИЗИЙ // ANOMALY_TYPES

› даты записаны в разных форматах;
› валюты представлены по-разному;
› названия имеют разные варианты;
› единицы измерения отличаются;
› номера документов имеют разные шаблоны;
› пустые значения представлены как NULL, 0, - или пустая строка.

Поэтому данные необходимо нормализовать до аналитических расчётов.

СЕМАНТИКА_ДАННЫХ // DATA_CLEANSING_SEMANTICS

Очистка — это не просто удаление пустых строк

Хорошая очистка данных — это не команда «удалить всё подозрительное».

Иногда пустое значение означает отсутствие информации.

А иногда ноль является реальным бизнес-значением.

[ КЕЙС: АНОМАЛИЯ ЗНАЧЕНИЯ ]

Цена = 0

может означать:

› товар бесплатный;
› цена ещё не установлена;
› ошибка загрузки;
› специальный тип позиции.

Автоматически заменить всё на NULL нельзя.

Нужно понимать семантику поля.

Именно поэтому качество данных — это не только техническая проверка формата.

Это ещё и понимание бизнес-смысла каждой сущности.

МОДЕЛИРОВАНИЕ // UNIFIED_DATA_MODEL

После очистки данные нужно привести к общей модели

Допустим, три системы называют один показатель по-разному:

[ CRM ]

deal_amount

[ 1С ]

СуммаДокумента

[ САЙТ ]

total_price

[ АНАЛИТИЧЕСКАЯ МОДЕЛЬ ]

order_amount

Но здесь важна не сама смена названия.

Нужно определить:

СПЕЦИФИКАЦИЯ_ПОКАЗАТЕЛЯ // METRIC_SPECIFICATION

› тип данных;
› валюту;
› налоговую составляющую;
› единицу измерения;
› источник;
› правила пересчёта;
› момент фиксации значения.

Именно здесь формируется единая модель данных, с которой дальше работает аналитика.

АРХИТЕКТУРА // DATA_WAREHOUSE_JUSTIFICATION

Хранилище нужно не ради хранения

Когда данных становится много, возникает вопрос: где их держать?

Можно напрямую подключить BI к нескольким источникам. Иногда это допустимо.

Но по мере роста системы такой подход начинает создавать проблемы:

Теперь BI должен сам разбираться:

ПРОБЛЕМЫ_ОБРАБОТКИ // TRANSFORMATION_OVERHEAD

› как объединить клиентов и исправить даты;
› как исключить тестовые записи и считать возвраты;
› как сопоставить товары и соединить заказы с оплатами.

Это быстро превращает отчётность в набор скрытой бизнес-логики.

Гораздо устойчивее:

В этом случае BI получает уже подготовленные данные.

ЛОГИКА // BUSINESS_LOGIC_PLACEMENT

Где должна находиться бизнес-логика

Это один из главных архитектурных вопросов. Допустим, показатель:

«Активные клиенты»

[ ОПРЕДЕЛЕНИЕ МЕТРИКИ ]

клиенты, совершившие хотя бы один оплаченный заказ за последние 90 дней.

Где должна находиться эта формула?

Если она спрятана внутри конкретного дашборда, завтра другой аналитик может создать второй отчёт и посчитать «активного клиента» иначе.

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

Тогда разные отчёты используют одну логику.

ТАЙМСТЕМПЫ // TIME_DIMENSION_COMPLEXITY

Время в аналитике сложнее, чем кажется

Представим заказ:

[ СОЗДАН ]

10:02

[ ОПЛАЧЕН ]

10:15

[ ОТГРУЖЕН ]

14:30

[ ДОСТАВЛЕН ]

следующий день

К какой дате отнести продажу?

ВАРИАНТЫ_ОТНЕСЕНИЯ // TIME_INTERPRETATIONS

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

Поэтому одна сущность может иметь несколько временных характеристик.

И если не определить это заранее, два отчёта по «продажам за день» могут показывать разные результаты и оба формально быть корректными.

ИСТОРИЧНОСТЬ // SLOWLY_CHANGING_DIMENSIONS

Что делать с изменениями и историей

Допустим, сегодня у товара категория:

«Электроника»

Через месяц его перенесли в:

«Аксессуары».

Если просто обновить значение, исторический отчёт может внезапно пересчитаться.

Продажи прошлого месяца окажутся в новой категории, хотя в тот момент товар относился к другой.

Поэтому для некоторых данных необходимо хранить историю изменений.

Упрощённо:

Тогда аналитика может ответить не только:

ВАРИАНТЫ_ЗАПРОСОВ // ANALYTICAL_CAPABILITIES

› «К какой категории относится товар сейчас?»
› «К какой категории он относился на дату продажи?»

Это уже вопрос качества аналитической модели, а не дизайна дашборда.

АРХИТЕКТУРА_МЕТРИК // METRIC_CENTRALIZATION

Расчёты должны выполняться там, где им место

Не каждый показатель нужно вычислять непосредственно в BI.

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

БАЗОВЫЕ_KPI // CORE_BUSINESS_METRICS

› Количество заказов
› Выручка
› Маржа
› Средний чек
› Доля возвратов
› Конверсия

можно рассматривать как часть единого аналитического слоя. Тогда:

Все пользователи видят одну и ту же методологию.

ПРОЕКТИРОВАНИЕ // AGGREGATION_BALANCING

Но не всё нужно заранее агрегировать

Здесь существует обратная крайность.

Если сохранить только готовые показатели:

[ ИЗБЫТОЧНАЯ АГРЕГАЦИЯ ]

Январь → Выручка
Февраль → Выручка
Март → Выручка

потом будет сложно ответить на новые вопросы.

Например:

«А покажите выручку по товарам, клиентам и менеджерам одновременно».

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

Это один из компромиссов при проектировании хранилища.

ВАЛИДАЦИЯ // DATA_QUALITY_ASSURANCE

Как понять, что данные действительно готовы для BI

Перед передачей в визуализацию полезно пройти несколько уровней контроля:

[ ТЕСТОВЫЙ ПРИМЕР СБОЯ ]

Например, если вчера было 12 000 заказов, а сегодня загрузилось только 8 000, это не обязательно проблема BI.

Скорее всего, её нужно обнаружить значительно раньше — на этапе контроля загрузки.

МОНИТОРИНГ // AUTOMATED_DATA_QUALITY

Контроль качества должен работать автоматически

Нельзя рассчитывать, что аналитик каждое утро будет вручную искать аномалии.

Можно задавать проверки:

[ КОЛИЧЕСТВО ЗАКАЗОВ ]

Сегодня: 14 281

Вчера: 14 050

→ OK

[ ЗАГРУЗКА КЛИЕНТОВ ]

Сегодня: 0

Вчера: 3 821

→ ОШИБКА

[ ОСТАТОК ТОВАРA ]

Сегодня: -84 231

→ ПОДОЗРИТЕЛЬНО

При критическом отклонении процесс может:

СЦЕНАРИИ_РЕАГИРОВАНИЯ // INCIDENT_RESPONSE_FLOW

› остановить публикацию;
› отправить уведомление;
› пометить данные как неполные;
› запустить повторную загрузку;
› передать проблему ответственному.

Это намного лучше, чем обнаружить проблему после того, как руководитель уже посмотрел неправильный отчёт.

ПРОИСХОЖДЕНИЕ_ДАННЫХ // DATA_LINEAGE_PROVENANCE

Важно знать не только цифру, но и её происхождение

Для серьёзной аналитической системы полезно иметь lineage — возможность понять путь показателя от источника до отчёта.

Например:

Если руководитель спрашивает:

«Откуда взялась эта цифра?»

аналитик должен иметь возможность пройти этот путь обратно.

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

ОТКАЗОУСТОЙЧИВОСТЬ // SOURCE_AVAILABILITY_EXCEPTIONS

А что происходит, если источник временно недоступен?

В реальной инфраструктуре системы иногда не работают.

ТИПЫ_СБОЕВ // INFRASTRUCTURE_ERRORS

› API может вернуть ошибку.
› 1С может быть недоступна.
› Сетевое соединение может оборваться.
› Файл может прийти позже обычного.

Поэтому аналитический контур должен понимать разницу между:

[ СБОЙ СВЯЗИ // NULL_STATE ]

Данных нет

[ БИЗНЕС-ФАКТ // ZERO_VALUE ]

Данные равны нулю

— Это совершенно разные ситуации.

Если вчера было 100 заказов, а сегодня источник не ответил, нельзя просто записать:

Заказы = 0

Иначе BI честно покажет ноль.

И это будет полностью неправильный вывод.

ОБНОВЛЕНИЕ // DATA_FRESHNESS_SLA

Свежесть данных тоже является частью показателя

Для разных процессов допустима разная задержка.

РЕГЛАМЕНТ_СВЕЖЕСТИ // PROCESS_LATENCY_SLA

[ ОПЕРАТИВНЫЙ СКЛАД ]

→ несколько минут

[ ПРОДАЖИ ]

→ 15–60 минут

[ УПРАВЛЕНЧЕСКИЙ ОТЧЕТ ]

→ несколько часов

[ ФИНАНСОВАЯ АНАЛИТИКА ]

→ раз в сутки

Поэтому при проектировании нужно заранее определить SLA данных:

насколько свежей должна быть информация для конкретного пользователя и конкретного решения?

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

И наоборот: для оперативного склада данные вчерашнего дня бесполезны.

ВИЗУАЛИЗАЦИЯ // BI_INTEGRITY

И только после этого появляется BI

Когда предыдущие уровни работают, BI становится действительно сильным инструментом.

Он получает не набор разрозненных таблиц, а подготовленную аналитическую модель:

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

УПРАВЛЕНИЕ // BI_DECISION_MAKING

Хороший дашборд должен отвечать на вопрос

Самая важная проверка аналитического отчёта:

Какое решение человек сможет принять после его просмотра?

Если на экране 25 графиков, это ещё не аналитика.

Вот здесь дашборд превращается из красивой картинки в инструмент управления.

Он не просто сообщает:

«Что-то изменилось».

Он помогает двигаться к ответу:

«Что изменилось, почему это произошло и что с этим делать?»

ПРЕДСТАВЛЕНИЕ // VISUAL_MODEL_ALIGNMENT

Визуализация должна соответствовать модели данных

Если данные плохие, никакой график не спасёт ситуацию.

Но и обратная ситуация тоже возможна: данные хорошие, а визуализация мешает их понять.

[ СРЕЗ РУКОВОДИТЕЛЯ // СВОДНЫЙ КРI ]

Выручка
184,2 млн ₽
↑ 8,4%

[ СРЕЗ АНАЛИТИКОВ // ДЕТАЛИЗАЦИЯ ]

Выручка
├─ регион
├─ канал
├─ менеджер
├─ клиент
├─ товар
└─ период

Поэтому один и тот же аналитический слой может обслуживать разные представления.

АРХИТЕКТУРНЫЙ_КРИЗИС // ARCHITECTURAL_DEGRADATION

Что происходит, если пропустить подготовку

Тогда постепенно возникает знакомая картина:

[ СИСТЕМНЫЙ ХАОС ОТОБРАЖЕНИЯ ]

CRM → BI
1С → BI
Excel → BI
Сайт → BI
WMS → BI

Потом в каждом отчёте появляются собственные формулы.

РАСХОЖДЕНИЕ_МЕТОДОЛОГИЙ // МETRIC_DIVERGENCE

› Один аналитик считает выручку одним способом.
› Другой — другим.
› Третий добавляет ещё одну корректировку.

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

Это называется не проблемой визуализации.

Это проблема архитектуры данных.

АРХИТЕКТУРА_КОНТУРА // FULL_DATA_PIPELINE

Правильный аналитический контур строится вокруг единой модели

В зрелой системе каждый слой выполняет свою задачу:

Главное преимущество такой схемы — разделение ответственности.

МАТРИЦА_ОТВЕТСТВЕННОСТИ // BOUNDARIES_OF_RESPONSIBILITY

› Источник отвечает за свои данные.
› Интеграционный слой — за доставку.
› Подготовка — за качество и структуру.
› Аналитический слой — за бизнес-логику.
› BI — за представление.

ОБЪЯСНИМОСТЬ // METRIC_PROVENANCE_VALIDATION

Отчётность становится надёжной, когда цифру можно объяснить

Зрелая аналитическая система должна отвечать не только на вопрос:

«Сколько?»

Но и на несколько следующих:

КРИТЕРИИ_ПРОЗРАЧНОСТИ // DATA_AUDIT_QUESTIONS

› «Откуда это взялось?»
› «По какому правилу рассчитано?»
› «Какие источники использованы?»
› «Когда данные обновлялись?»
› «Почему показатель изменился?»
› «Можно ли доверять этой цифре?»

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

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

РЕЗЮМЕ_АНАЛИТИКИ // END_TO_END_PROVENANCE

От дашборда обратно к источнику

Именно поэтому серьёзная аналитика начинается задолго до BI.

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

В итоге путь выглядит так:

И это важнейшая мысль всей архитектуры:

дашборд не создаёт достоверность данных. Он только показывает то, что произошло с ними до него.

Если на входе хаос, BI сделает из него красивый хаос.

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

И именно тогда аналитика начинает приносить бизнесу реальную ценность.

НАВИГАЦИЯ // SUGGESTED_READING

[ Модуль // ИНТЕГРАЦИИ ]

API, Webhook или очередь сообщений?

читать материал ──►

[ Модуль // ИНТЕГРАЦИИ ]

Когда API есть, а интеграция всё равно не работает

читать материал ──►

[ Модуль // АВТОМАТИЗАЦИЯ ]

Как соединить производство и корпоративные системы

читать материал ──►

[ EXPERTISE JOURNAL ]

Все инженерные материалы и экспертные статьи

перейти к каталогу ──►

[ CORE GLOSSARY ]

Полный алфавитный справочник ИТ-терминов

открыть справочник ──►

[ DIRECT EMAIL LINE ]
info@log-ai.ru

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).

Политика конфиденциальности Пользовательское соглашение