Меня зовут Андрей Шантарин, я ИТ-директор на машиностроительном предприятии.
В этой статье разберу ситуацию, знакомую многим производственным компаниям: руководителям нужны управленческие срезы по данным из учётной системы, но в текущей конфигурации 1С нет нужного аналитического функционала.
На практике это часто решается через Excel. Данные выгружаются из 1С, а дальше экономист, аналитик или специалист подразделения вручную собирает сводные таблицы, фильтрует строки, выбирает главное и объясняет руководителю, что происходит.
Пока данных немного, такая схема работает. Но когда в выгрузке появляются тысячи строк, сложная структура заказов, операций и ответственных, Excel становится узким местом. Часть сигнала теряется в ручной обработке, а руководитель получает не данные, а их пересказ.
Системно проблему можно решить через BI-проект или доработку 1С. Но в реальной практике всё упирается в ограничения: бюджет сжат, ресурсы разработки ограничены, а очередь задач в 1С занята более критичными изменениями.
В таких случаях я использую промежуточный подход: лёгкий дашборд поверх выгрузки из учётной системы, собранный под один конкретный управленческий сценарий. Пользователь открывает страницу в браузере, загружает XLSX- или CSV-файл, а приложение локально проверяет структуру, рассчитывает KPI, показывает зоны внимания и даёт перейти к детализации. Отдельной серверной части хранения и расчета данных нет, роли доступа не используются.
Далее я покажу пример создания такого дашборда. Статья будет полезна двум аудиториям:
Для руководителей ИТ-функции это пример того, как проверить аналитический сценарий до запуска тяжелого проекта и при этом не разрушить корпоративную архитектуру.
Для начинающих аналитиков — пример работы с выгрузкой, KPI, синтетическими данными, контрольными значениями и ИИ-агентом, где агент помогает писать код, но не заменяет постановку задачи и ответственность за смысл показателя.
Кейс
Возьмем производственный пример. Он синтетический: все названия, показатели и строки используются только для демонстрации подхода.
На предприятии АО «Ромашка» применяются сменно-суточные задания — ССЗ. Это рабочий план производства на смену или сутки: какие операции, по каким заказам и в каком объеме должны выполняться на участках.
ССЗ оформляются мастерами в доработанной конфигурации 1С:ERP. Часть операций оформляется по технологии — на основе маршрутов, норм времени и состава работ. Другая часть добавляется вручную, без жесткой связи с технологической информацией.
ИТ-служба наладила передачу технологических данных из PDM-системы в 1С:ERP. Теперь руководство хочет увеличить долю операций, оформленных по технологии, и снизить объем произвольного оформления.
Это значит, что начальнику производства нужно получить ответы на вопросы:
какая доля нормо-часов оформлена по технологии;
какие операции чаще оформляются не по технологии;
кто из мастеров чаще оформляет задания не по технологии;
как меняется ситуация по периодам.
Ежемесячно в ССЗ создаётся порядка 10 тысяч операций. Слишком много для того, чтобы аналитик искал отклонения вручную. Разумнее подготовить дашборд и с его помощью провести начальника производства по маршруту: исходные данные → KPI → отклонение → причина → действие.
Данные
Разработку дашборда можно ускорить с помощью ИИ-агента кодинга. Но есть важное ограничение: реальные производственные выгрузки нельзя передавать во внешний ИИ-контур.
В Excel-файле могут быть ФИО сотрудников, номера заказов, подразделения, маршруты, нормы времени, номера документов, коммерческая информация и внутренние комментарии. Даже если удалить фамилии и явные идентификаторы, в файле останутся чувствительные связи: реальные объёмы, редкие операции, структура заказов, последовательность событий и внутренние коды.
Поэтому для разработки нужен не «обезличенный реальный файл», а синтетическая выгрузка.
Обезличенный файл — это реальный файл, в котором часть значений удалили или заменили. Он всё равно может сохранять фактические события и связи.
Синтетический файл — это файл, созданный заново. Он повторяет форму реальной выгрузки, но не содержит реальных заказов, ФИО, маршрутов и коммерческой информации.
В синтетике важно сохранить проверяемое поведение будущего дашборда:
те же колонки, что в реальной выгрузке;
похожие типы данных;
нормальные и проблемные строки;
разные периоды, цеха, заказы, операции и ответственных;
пустые или спорные значения, если они бывают в реальности;
контрольные отклонения, которые дашборд должен найти;
ожидаемые KPI для проверки расчета.
Если дашборд должен находить заказы с низкой долей операций по технологии, такие заказы должны быть в синтетическом файле. Если в реальной выгрузке бывают текстовые числа, лишние пробелы, пустые ответственные или отсутствующие значения, эти случаи тоже нужно заложить в синтетику. Иначе первая версия будет работать только на «идеальном» файле, которого в реальной жизни нет.
Бриф
Одного синтетического файла для ИИ-агента будет недостаточно. Нужно подготовить короткий рабочий бриф: описание задачи, структура загрузочного файла, правила расчета и ограничения.
Иначе агент начнет заполнять пробелы сам: может неверно понять показатель, предложить лишние графики, смешать расчет с интерфейсом или построить экран поверх неправильной модели данных.
Минимальный бриф должен отвечать на несколько вопросов.
Блок вопросов | Что зафиксировать | |
Предметная область | Что такое ССЗ, зачем нужен дашборд, кто пользователь, какое решение должен поддерживать экран | |
Данные | Формат файла, листы, обязательные колонки, типы данных, возможные ошибки | |
Метрики (KPI) | Формула, целевое значение, контрольные значения на синтетическом файле | |
Исключения | Что делать с пустыми значениями, текстовыми числами, неизвестными статусами | |
Экран | Главный KPI, отклонение от цели, зоны внимания, фильтры, детализация | |
Границы | Что входит и что не входит в разрабатываемую версию дашборда | |
Контекст для такого брифа собирается из двух источников:
Сама организация: существующие выгрузки, ручные отчеты, регламенты, опыт экономистов, производственников, диспетчеров и руководителей. Именно здесь находятся реальные правила работы, исключения, привычные формулировки и управленческие вопросы.
Внешний исследовательский контур. Если внутри команды не хватает компетенции по проектированию дашбордов, структуре KPI и т.д., можно использовать обычный ИИ-чат как консультанта: попросить его предложить типовую структуру экрана, риски в данных, варианты проверки KPI или критерии приемки. Но в такой чат нельзя передавать реальные выгрузки, ФИО, номера заказов, внутренние документы и коммерческую информацию. Только обобщенное описание задачи и синтетические примеры .
Разработка
После подготовки синтетического файла и постановки можно переходить к работе с ИИ-агентом кодинга.
Краткий глоссарий:
ИИ-агент кодинга — инструмент на базе ИИ, который работает с программным проектом: читает файлы, предлагает изменения, пишет код, запускает проверки и объясняет результат.
Codex — ИИ-агент OpenAI для работы с программными проектами.
Codex App — рабочая среда для работы с Codex в программном проекте. Для аналитика этот инструмент удобен тем, что разработкой можно управлять через привычные сущности: пользовательский сценарий, требования, ограничения, макет, критерии приемки и обратную связь.
Skill / скил — заранее описанный сценарий работы агента для типовой задачи. По сути, это способ не давать агенту работать хаотично.
Superpowers — методология работы с ИИ-агентами кодинга через набор скилов.
Для создания дашбордов я использую Codex App и скилы Superpowers. Но конкретные инструменты здесь не главное.
Главное — не отдавать агенту один большой запрос вроде «сделай весь дашборд». Лучше вести его по шагам: уточнение задачи → план реализации → контрольные проверки → итерационная реализация → ревью → приёмка → документирование.
Агент кодинга должен использоваться как инструмент сборки и проверки, а не как источник бизнес-логики. Это снизит риск того, что агент начнёт выходить за рамки задачи: добавлять лишние функции, усложнять архитектуру или менять логику без согласования.
Этап | Что делает агент | Что проверяет человек |
Уточнение задачи | Описывает понимание задачи, риски, вопросы и черновую структуру экрана | Цель, пользователя, KPI, управленческий сценарий и границы первой версии |
План реализации | Делит работу на небольшие этапы, указывает ожидаемый результат каждого этапа и возможные изменения в проекте | Нет ли лишней архитектуры, новых KPI и функций за пределами задачи |
Контрольные проверки | Предлагает тесты и контрольные случаи | Верны ли формулы, исключения и контрольные значения |
Реализация по итерациям | Делает один ограниченный шаг | Не изменена ли бизнес-логика и не расширены ли границы задачи |
Ревью | Показывает, что реализовано, что проверено и где возможны расхождения | Соответствует ли результат постановке, ограничениям и ожидаемому поведению |
Приемка | Запускает сборку, расчёты и основные сценарии | Можно ли показывать результат бизнес-пользователю |
Документирование | Фиксирует правила расчёта, структуру файла и ограничения | Корректно ли документация описывает фактическую работу дашборда |
Подготовить промпты для каждого из этапов поможет обычный ИИ-чат. Для примера приведу промпт для этапа "Уточнение задачи", составленный с помощью ИИ-чата:
Используй скилы @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.
Делаем | Не делаем |
Проверяем гипотезу | Не строим новую учетную систему |
Загружаем XLSX/CSV вручную | Не подключаемся напрямую к учетной системе |
Показываем зоны внимания | Не делаем универсальную BI-модель |
Работаем локально в браузере | Не создаем базу данных |
Вывод
Не каждый запрос бизнеса нужно сразу превращать в BI-проект, доработку 1С или новую информационную систему. Иногда правильный первый шаг — лёгкий дашборд, который проверяет один управленческий сценарий и не выходит за безопасные архитектурные границы.
Для CIO такой подход снижает риск автоматизировать неподтверждённую логику. Сначала мы проверяем KPI, данные, сценарий пользователя и ценность экрана для руководителя. Затем принимаем осознанное решение: оставить инструмент лёгким, встроить логику в BI, перенести её в 1С или включить в развитие корпоративного хранилища.
Для аналитика урок ещё практичнее: не начинайте с диаграмм. Начинайте с того, какое решение должен принять пользователь, какой показатель это решение поддерживает, как он считается, какие ошибки есть в данных и на каких контрольных значениях проверяется результат. Хороший дашборд — это не набор визуализаций, а проверяемая управленческая логика.
