Когда Excel уже не справляется, а BI еще рано: легкий дашборд по выгрузке из 1С

Меня зовут Андрей Шантарин, я ИТ-директор на машиностроительном предприятии.

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

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

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

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

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

Далее я покажу пример создания такого дашборда. Статья будет полезна двум аудиториям:

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

• Для начинающих аналитиков — пример работы с выгрузкой, KPI, синтетическими данными, контрольными значениями и ИИ-агентом, где агент помогает писать код, но не заменяет постановку задачи и ответственность за смысл показателя.

Кейс

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

На предприятии АО «Ромашка» применяются сменно-суточные задания — ССЗ. Это рабочий план производства на смену или сутки: какие операции, по каким заказам и в каком объеме должны выполняться на участках.

ССЗ оформляются мастерами в доработанной конфигурации 1С:ERP. Часть операций оформляется по технологии — на основе маршрутов, норм времени и состава работ. Другая часть добавляется вручную, без жесткой связи с технологической информацией.

ИТ-служба наладила передачу технологических данных из PDM-системы в 1С:ERP. Теперь руководство хочет увеличить долю операций, оформленных по технологии, и снизить объем произвольного оформления.

Это значит, что начальнику производства нужно получить ответы на вопросы:

• какая доля нормо-часов оформлена по технологии;

• какие операции чаще оформляются не по технологии;

• кто из мастеров чаще оформляет задания не по технологии;

• как меняется ситуация по периодам.

Ежемесячно в ССЗ создаётся порядка 10 тысяч операций. Слишком много для того, чтобы аналитик искал отклонения вручную. Разумнее подготовить дашборд и с его помощью провести начальника производства по маршруту: исходные данные → KPI → отклонение → причина → действие.

Данные

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

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

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

• Обезличенный файл — это реальный файл, в котором часть значений удалили или заменили. Он всё равно может сохранять фактические события и связи.

• Синтетический файл — это файл, созданный заново. Он повторяет форму реальной выгрузки, но не содержит реальных заказов, ФИО, маршрутов и коммерческой информации.

В синтетике важно сохранить проверяемое поведение будущего дашборда:

• те же колонки, что в реальной выгрузке;

• похожие типы данных;

• нормальные и проблемные строки;

• разные периоды, цеха, заказы, операции и ответственных;

• пустые или спорные значения, если они бывают в реальности;

• контрольные отклонения, которые дашборд должен найти;

• ожидаемые KPI для проверки расчета.

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

Бриф

Одного синтетического файла для ИИ-агента будет недостаточно. Нужно подготовить короткий рабочий бриф: описание задачи, структура загрузочного файла, правила расчета и ограничения.

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

Минимальный бриф должен отвечать на несколько вопросов.

Контекст для такого брифа собирается из двух источников:

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

2. Внешний исследовательский контур. Если внутри команды не хватает компетенции по проектированию дашбордов, структуре KPI и т.д., можно использовать обычный ИИ-чат как консультанта: попросить его предложить типовую структуру экрана, риски в данных, варианты проверки KPI или критерии приемки. Но в такой чат нельзя передавать реальные выгрузки, ФИО, номера заказов, внутренние документы и коммерческую информацию. Только обобщенное описание задачи и синтетические примеры .

Разработка

После подготовки синтетического файла и постановки можно переходить к работе с ИИ-агентом кодинга.

Краткий глоссарий:

• ИИ-агент кодинга — инструмент на базе ИИ, который работает с программным проектом: читает файлы, предлагает изменения, пишет код, запускает проверки и объясняет результат.

• Codex — ИИ-агент OpenAI для работы с программными проектами.

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

• Skill / скил — заранее описанный сценарий работы агента для типовой задачи. По сути, это способ не давать агенту работать хаотично.

• Superpowers — методология работы с ИИ-агентами кодинга через набор скилов.

Для создания дашбордов я использую Codex App и скилы Superpowers. Но конкретные инструменты здесь не главное.

Главное — не отдавать агенту один большой запрос вроде «сделай весь дашборд». Лучше вести его по шагам: уточнение задачи → план реализации → контрольные проверки → итерационная реализация → ревью → приёмка → документирование.

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

Подготовить промпты для каждого из этапов поможет обычный ИИ-чат. Для примера приведу промпт для этапа «Уточнение задачи», составленный с помощью ИИ-чата:

Используй скилы @brainstorming и @frontend-design.Код пока не пиши.Контекст:- нужен локальный дашборд поверх XLSX-выгрузки;- тема: качество оформления сменно-суточных заданий (ССЗ) по технологии;- пользователь: руководитель производства или аналитик;- цель: увидеть, где ССЗ оформляются не по технологии.Главный KPI: доля нормо-часов по технологии = нормо-часы по операциям, оформленным по технологии / все нормо-часы.Функциональные ограничения:- только локальная обработка файла;- бэкенд, база данных, авторизация и внешние API не добавляются;- интеграцию с 1С или другими системами не проектировать;- новые KPI не придумывать;Технические ограничения:- решение должно оставаться клиентским дашбордом, работающим в браузере;- XLSX-файл должен обрабатываться на стороне клиента, без отправки данных во внешний контур;- если проект уже создан, нужно использовать существующий стек и структуру проекта;- не предлагать смену стека, UI-фреймворка или библиотеки визуализации без отдельного обоснования;- не добавлять новые зависимости без объяснения, зачем они нужны;- бизнес-логика расчёта KPI должна быть отделена от интерфейса;- дашборд должен оставаться пригодным для локального запуска или статической публикации.UX/UI-ограничения:- экран должен вести пользователя от общего KPI к причинам отклонения;- главный KPI, отклонение от цели и зоны внимания должны быть видны без лишних переходов;- цветовая индикация не должна быть единственным способом понять статус;- интерфейс должен быть понятен руководителю производства без пояснений разработчика;- детализация должна помогать проверить причину отклонения, а не перегружать экран графиками.Проверь, как ты понял задачу.Покажи:- цель дашборда;- пользователя;- какие управленческие решения должен поддерживать экран;- риски и неоднозначности;- вопросы для уточнения;- предварительную структуру экрана;- какие технические ограничения нужно учесть при проектировании;- что точно не нужно делать в первой версии.

Результат

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

В моём случае этот подход лег в основу линейки дашбордов «Рапорт». Ниже — фрагменты главного экрана дашборда по контролю качества оформления ССЗ.

В верхней части сразу виден главный управленческий сигнал: за выбранный период доля нормо-часов, оформленных по технологии, составляет 48,9% при цели 50%, то есть отклонение — 1,1 п.п. Дальше дашборд не просто показывает процент, а объясняет, где именно теряется технология: проблемный заказ, цех и операция вынесены в блок «Главный вывод».

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

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

Вы можете пройти путь пользователя самостоятельно c помощью публичной демо-версии «Рапорта»: https://shantarinav.github.io/raport-product-line/ Синтетический файл для проверки сценария ССЗ доступен в репозитории: https://github.com/shantarinav/raport-product-line/tree/main/demo-data/ssz

Внедрение

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

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

Чтобы упаковать дашборд в продукт потребуется:

• понятное название;

• короткое описание пользы;

• инструкция максимум на одну страницу;

• несколько примеров управленческих вопросов, на которые дашборд отвечает.

Начните с нейминга. Хорошее внутреннее название должно быть коротким, нейтральным и прикладным. Оно должно отвечать на два вопроса: что это за инструмент и какую область он закрывает. Поэтому вместо абстрактных названий вроде «Аналитика 2.0» или «Модуль контроля» лучше использовать формулу: продукт + предметная область Например: «Рапорт по ССЗ».

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

Архитектурная граница

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

Я сформулировал такое правило: легкий дашборд проверяет бизнес-логику, но не берет на себя функции 1С, BI, DWH.

Вывод

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

Для CIO такой подход снижает риск автоматизировать неподтверждённую логику. Сначала мы проверяем KPI, данные, сценарий пользователя и ценность экрана для руководителя. Затем принимаем осознанное решение: оставить инструмент лёгким, встроить логику в BI, перенести её в 1С или включить в развитие корпоративного хранилища.

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