Как сделать дашборд по данным 1С

В 1С уже хранится большая часть данных, которая нужна, чтобы сделать управленческий дашборд: продажи, закупки, остатки, платежи, взаиморасчёты, себестоимость, сведения о клиентах и сотрудниках. Но наличие этих данных ещё не означает, что их можно сразу передать в BI-систему и получить готовую аналитическую панель.

Сначала нужно определить, какие показатели действительно нужны пользователю и в какой детализации. Затем — понять, где находятся исходные данные 1С, организовать их получение, подготовить к аналитике. Только после этого данные подключают к BI, создают показатели и визуализации, из которых собирается дашборд. Если панель используется регулярно, потребуется также автоматическое обновление и контроль актуальности.

В небольшом проекте можно обойтись без отдельного хранилища: выгрузить необходимые данные 1С в источник или формат, который поддерживает выбранная BI-система. При больших объёмах, нескольких информационных базах или сложных преобразованиях между 1С и BI появляется аналитическая база, DWH или отдельная витрина.

Общую цепочку можно представить так:

1С → получение данных → подготовка / хранилище → BI → дашборд

Разберём каждый этап, чтобы понять, как сделать дашборд по данным 1С - от управленческой задачи до работающей аналитической панели.

Что определить перед созданием дашборда по данным 1С

Начинать с подключения BI или выбора диаграмм не стоит. Сначала нужно понять, какой вопрос должен решать дашборд, кто будет им пользоваться, чтобы сделать дашборд по данным 1С под конкретную задачу.. Один и тот же набор информации можно визуализировать десятками способов, но полезными будут только те показатели, которые помогают принимать конкретные решения.

Руководителю отдела продаж, например, недостаточно видеть общую выручку. Ему полезнее понимать, выполняется ли план, как меняется маржа, какие менеджеры обеспечивают рост и за счёт каких товарных групп формируется результат. Финансовому директору на основе тех же учётных данных понадобятся уже другие показатели: движение денежных средств, прибыль, дебиторская задолженность или план-факт.

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

Определите KPI и аналитические разрезы

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

Допустим, руководителю нужно контролировать маржинальность продаж. Тогда одной выручки недостаточно: понадобятся себестоимость и прибыль. Чтобы сделать дашборд полезным для анализа причин изменения маржи, результат потребуется анализировать по времени, менеджерам, товарам или категориям.

Вместо абстрактного требования «нужен дашборд по продажам» получается конкретная задача:

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

Из такой формулировки уже понятно, какие данные понадобятся из 1С, чтобы сделать дашборд. Принцип простой: сначала бизнес-вопрос и KPI, затем состав исходных данных, а не наоборот.

Какие данные из 1С нужны для дашборда

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

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

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

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

Почему готового отчёта не всегда достаточно

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

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

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

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

Подробно выбор между документами, справочниками, регистрами и готовыми отчётами разобран в отдельном материале Denvic «Какие данные из 1С нужны для BI: документы, справочники, регистры или отчёты».

Когда состав данных определён, возникает следующий вопрос: каким способом передавать их из учётной системы в аналитический контур.

Как получить данные из 1С для дашборда

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

Чтобы сделать прототип дашборда, может быть достаточно Excel или CSV. Аналитик выгружает данные 1С, подключает их к BI и проверяет, насколько полезен будущий дашборд. Такой вариант позволяет быстро проверить гипотезу без построения отдельной инфраструктуры, но плохо подходит для регулярного обновления.

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

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

Подробное сравнение этих вариантов вынесено в отдельную статью Denvic «Выгрузка данных из 1С для аналитики: сравниваем 7 популярных подходов».

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

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

Нужно ли хранилище между 1С и BI

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

Для прототипа может быть достаточно схемы:

1С → выгрузка в поддерживаемый источник → BI

Ситуация меняется, когда аналитика становится регулярной. Представим компанию с несколькими базами 1С, длинной историей продаж и дополнительными сведениями из CRM. Пользователям нужны разные дашборды, но все они должны одинаково рассчитывать выручку, прибыль и другие KPI. В этом случае удобнее сначала собрать информацию в отдельном аналитическом контуре, привести её к единой модели и только затем подключить BI.

Получается схема:

1С и другие источники → аналитическая БД / DWH → витрины → BI

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

PostgreSQL или ClickHouse

Выбор СУБД зависит от характера проекта. PostgreSQL — универсальная реляционная система, подходящая для широкого набора задач и привычной SQL-модели. ClickHouse ориентирован на аналитические нагрузки и эффективную обработку больших объёмов при агрегирующих запросах.

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

Подробнее устройство корпоративного аналитического контура на данных 1С рассмотрено в материале Denvic «Как превратить 1С в надёжный источник данных для корпоративного DWH».

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

Как подготовить данные из 1С для аналитики

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

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

сырые данные → приведение структуры → объединение → расчёты → аналитическая модель → BI

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

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

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

Где выполнять такие расчёты — на этапе подготовки или внутри BI — зависит от архитектуры. Но если один показатель используется во множестве отчётов, его методику лучше централизовать, чтобы два аналитика не получили две разные версии одной и той же «маржи».

От сырых таблиц к аналитической модели

Для BI удобно разделять факты и измерения. Факт описывает событие и числовые значения: продажу, количество, выручку, себестоимость. Измерения дают контекст — дату, товар, клиента, менеджера или подразделение.

Например, в центре модели продаж находится таблица операций, а вокруг неё — календарь, номенклатура, сотрудники и контрагенты. Такое представление часто строят по принципу схемы «звезда».

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

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

Когда аналитическая модель готова, работа перемещается непосредственно в BI-систему.

Как подключить подготовленные данные к BI-системе

Конкретный интерфейс зависит от выбранного продукта, но общий принцип схож для DataLens, Power BI, Visiology, PIX BI и других платформ: сначала BI получает доступ к подготовленному источнику, затем создаётся набор данных или модель, на основе которой строятся визуализации.

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

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

Не стоит сразу создавать десятки графиков. Сначала полезно проверить модель на небольшом наборе: правильно ли суммируется выручка, работают ли фильтры, корректно ли связываются таблицы и совпадают ли контрольные цифры.

Если основа работает правильно, можно переходить к центральной части — сборке дашборда.

Как сделать дашборд по данным 1С пошагово

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

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

Шаг 1. Подготовьте показатели

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

На их основе рассчитываются производные KPI:

Прибыль = Выручка − Себестоимость

Маржинальность = Прибыль / Выручка × 100%

Средний чек = Выручка / Количество продаж

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

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

Шаг 2. Выведите основные KPI

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

Карточка может показывать не только абсолютное значение, но и изменение относительно прошлого периода или плана. Тогда показатель «выручка 12,8 млн рублей» получает контекст: рост на 8% относительно предыдущего месяца выглядит совсем иначе, чем падение на те же 8%.

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

Шаг 3. Покажите динамику во времени

После текущего значения следующий вопрос обычно звучит так: как мы к нему пришли?

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

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

Именно на динамике пользователь часто впервые замечает аномалию: резкий провал, нетипичный пик или постепенное снижение.

Шаг 4. Добавьте разрезы, которые объясняют результат

Общий KPI показывает факт, но редко объясняет причину. Если выручка снизилась на 12%, руководителю важно понять, где произошло падение.

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

После этого пользователь может перейти глубже и посмотреть, какие категории сформировали падение внутри региона. Такая последовательность — от общего результата к причинам — превращает панель в инструмент анализа, а не просто экран с графиками.

Шаг 5. Добавьте детализацию

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

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

Удобная логика панели выглядит так:

KPI → динамика → аналитический разрез → детализация

Пользователь начинает с общего состояния и при необходимости постепенно углубляется в информацию.

Шаг 6. Настройте фильтры

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

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

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

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

Шаг 7. Добавьте интерактивность

Многие BI-системы позволяют использовать сами графики как инструмент навигации.

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

Другой распространённый сценарий — drill-down: переход от года к кварталу, затем к месяцу и дню либо от категории к подкатегории и конкретному товару.

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

Шаг 8. Соберите визуализации в единый экран

Когда отдельные элементы готовы, их объединяют в логичную композицию.

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

Хороший дашборд не должен заставлять пользователя долго разбираться в интерфейсе. Один экран желательно посвящать одной управленческой задаче, визуально выделять главное и не заполнять свободное пространство диаграммами только ради плотности.

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

Шаг 9. Сверьте результат с 1С

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

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

Например, под «выручкой» один отчёт может понимать сумму проведённых реализаций, а другой — поступившие оплаты. Оба расчёта могут быть технически корректными, но отвечают на разные бизнес-вопросы.

Если методика совпадает, проверяют всю цепочку:

1С → выгрузка → аналитическая база → преобразования → модель BI → визуализация

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

Этой задаче посвящён отдельный материал Denvic «Почему цифры в 1С и BI не совпадают и как выстроить сверку данных».

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

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

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

Рабочая цепочка должна выглядеть примерно так:

1С → автоматическая передача → подготовка → обновление BI

Частоту выбирают исходя из бизнес-задачи. Финансовой отчётности может быть достаточно одного обновления в сутки. Для анализа продаж сведения могут поступать несколько раз в день. Сокращать интервал до нескольких минут имеет смысл только тогда, когда такая оперативность действительно влияет на действия пользователя.

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

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

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

Такой механизм позволяет уменьшить объём повторной обработки и быстрее обновлять большие наборы. Подробно варианты организации процесса рассмотрены в статье Denvic «Инкрементальная выгрузка данных из 1С в BI: как настроить передачу изменений и не потерять данные».

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

Пользователь должен понимать, что перед ним не просто «сегодняшний отчёт», а, например, данные, обновлённые в 09:15.

Пример дашборда продаж по данным 1С

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

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

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

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

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

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

Для небольшого проекта архитектура может быть относительно простой:

1С → выгрузка в поддерживаемый источник → BI → дашборд

При больших объёмах и регулярном обновлении:

1С → автоматическая выгрузка → ClickHouse / PostgreSQL → BI → дашборд

Если информацию требуется объединять с CRM, файлами или другими источниками, появляется ETL-слой и аналитические витрины:

1С + другие источники → хранилище / ETL → витрина → BI → дашборд

Для пользователей Yandex DataLens на denvic.tech уже есть отдельная подробная инструкция «Выгрузка из 1С в DataLens», где показан переход от подготовленного источника к датасету, расчётным полям, чартам и готовой панели.