Сотрудники заказчика каждый месяц выгружали из платформы сырые данные и сводили статистику в Excel руками. Фактически это полставки оператора, причём каждый сводит по-своему. Мы перенесли эту работу внутрь платформы — пять ТЗ, 356 часов. Самым трудным в ней оказались не графики и не фильтры, а дисциплина справочников: пока десяток написаний одного техрегламента не сведён к одному классу, автоматическая группировка выдаёт мусор вместо отчёта.
Сводка
| Отрасль конечного клиента | Сертификация продукции, B2B-аналитика рынка |
| Конечный клиент | «Аналитика сертификатов» |
| Формат сотрудничества | Регулярное сопровождение — поток пронумерованных ТЗ по аналитической функциональности |
| Тип проекта | Перенос ручной сводки из Excel во встроенную аналитику B2B-платформы |
| Объём работ | Модуль запросника, группировщик статистики, гео-фильтры с разбором адресов, общий слой фильтров, годовой график с мастер-справочником |
| Дата проекта | IV квартал 2021 — основной блок закрыт к 2023, годовой график обслуживается по сей день |
| Трудозатраты | 356 часов по ТЗ (agreed/billed) |
| Команда | Антон Херсун (руководитель проекта) и разработчик аналитической панели — он ведёт это направление с первого дня и до сегодня |
| Технологический стек | Laravel · Sencha 6 grid · конструктор табличных данных из ядра · MariaDB-агрегации · дочерний сервер вычислений |
| Сдано | Запросник (65 ч), группировщик статистики (90 ч), гео-фильтры и разбор адресов (100 ч), фильтры общего отчёта + новости (16 ч), годовой график с мастер-справочником (85 ч) |
Постановка задачи
У сотрудников клиента была отлаженная Excel-практика: раз в период выгрузить из платформы сырые данные, перенести в файлы фиксированной структуры и собрать статистику — сколько документов выдал каждый орган сертификации, как они распределяются по техническим регламентам и классам продукции. Платформа этой аналитики не давала. В ТЗ на статистику так и написано: «На основании данных, которые мы выгружаем, мы вручную в Эксель формируем статистику за период».
Заказчик ставил ТЗ кусочками: сначала группировщик по простым метрикам, потом гео-фильтры с разбором адресов, потом фильтры общего отчёта с новостями, под конец — годовой график с мастер-справочником классификации продукции.
Что в этом сложного. Слабое место таких отчётов — справочники. Из реестров данные приходят в разнобой: один и тот же технический регламент пишется десятком способов («ТР ТС 021/2011», «о пищевой продукции», «ТР ТС 022/2011 в части маркировки»). Сотрудник в Excel схлопывает их в одну строку «Пищевая продукция», потому что считает руками и держит соответствие в голове. Для базы же это разные значения, и автоматическая группировка по ним рассыпается. С адресами та же беда: в реестрах они лежат как попало, один город записан в нескольких стилях, у части документов нет даже индекса. Поэтому в центре кейса не диаграммы и не фильтры, а две вещи поскучнее: мастер-справочник классификации и нормализация адресов. Без них отчёты так и остались бы ручными.
Как мы это сделали
1. Опирались на конструктор табличных данных из ядра, а не строили отдельный отчётный движок.
Конструктор встроен в изначальное ядро платформы (см. кейс «Original platform build»): оператор настраивает колонки и группировки прямо в интерфейсе. Все аналитические ТЗ выросли из него. Мы добавляли новые группы полей (технический регламент, тип объекта декларирования, географию), а не писали отдельный код под каждый отчёт. За счёт этого каждое следующее ТЗ обходилось дешевле предыдущего.
2. Группировщик статистики (90 ч): первый шаг от Excel внутрь платформы.
В платформе появился раздел «Аналитика» с меню «группировщик» и типами отчётов вроде «декларации ТР ТС — по заявителю». Первый рабочий отчёт показали через неделю после старта, ещё через 2 недели модуль открыли всем пользователям. По ходу работы логику группировки пришлось переработать — 30 часов сверх ТЗ, и они остались на нашей стороне. С этого момента ежемесячная сводка перестала жить в Excel-файлах.
3. Гео-фильтры и разбор адресов (100 ч): там, где сортировка по адресу не сводилась.
Заказчик хотел фильтровать отчёты по дате, региону и городу. Простой текстовый фильтр по адресу цеплял любые совпадения, как %like% в Excel, и выдавал мусор: адреса в исходной базе записаны как попало. Решили разбирать адрес на составляющие по почтовому индексу — через базу индексов Почты России и сервис DaData, доли копейки за запрос. Индекс даёт устойчивый ключ там, где текстовое написание плывёт. Документы без индекса ищутся по-старому, текстом. Типовая для нас история: внешний источник отдаёт грязные данные, и нормализация стоит дороже самого фильтра.
4. Фильтры общего отчёта и новости (16 ч): за 3 дня.
В отдельных отчётах фильтры настраивались, а в общем — нет: там один набор фильтров на все таблицы. Заказчик попросил добавить туда фильтры по федеральному округу, заявителю, ОГРН и ТР ТС, плюс блок новостей на главной. Сложность была не в интерфейсе, а в КГ-таблице: под некоторые фильтры пришлось дописывать отдельный код, потому что схема «одно поле — одна таблица в поиске» эти случаи не покрывала. Собрали, протестировали с разработчиком и сдали за 3 дня от согласования.
5. Годовой график документов и мастер-справочник (85 ч): отговорили заказчика от чужой системы.
Заказчик хотел графики по декларациям и сертификатам за год, и здесь была развилка. Можно было поднять Grafana: мы развернули её на отдельном сервере ради проверки и построили первые простые графики; вышло бы часов на 70–80. Можно было написать собственный модуль аналитики документов внутри платформы, около 100 часов. Grafana мы заказчику не предложили: своих компетенций в ней на тот момент не хватало, чтобы гарантировать результат и сроки. Честнее было собрать модуль в существующей аналитике, где мы отвечаем за всё. На нём и договорились.
Технически задача упиралась в нагрузку: годовые агрегации по всему массиву кладут основной сервер. Подняли дочерний сервер, настроили пересылку данных туда и предварительную обработку — скрипты готовят таблицы так, чтобы запросы выполнялись с приемлемой скоростью. Параллельно закрыли исходную проблему справочников, ради которой всё затевалось: мастер-справочник классификации. Администратор настраивает таблицу соответствия «исходное поле из базы → укрупнённый класс», и десяток формулировок про пищевую продукцию (029/2012, 021/2011, 022/2011 и прочие) сводится к одному классу «Пищевая продукция». Без этого справочника группировка по реальным данным разваливается. ТЗ закрыли с перерасходом по часам; перерасход остался на нашей стороне, не на счёте заказчика.
6. Модуль запросника (65 ч): сделали по ТЗ, концепция у заказчика не сложилась.
Запросник работает как конструктор запросов: подбор продукции по сводной ТР ТС / ТН ВЭД с множественным выбором кодов. Формы и базу на ~26 тысяч позиций сдали в срок. Дальше встал вопрос наполнения, и заказчик написал прямо: «как его наполнить, голову ломаем, идей почти нет». Применения концепции так и не нашлось. Мы предложили закрыть ТЗ, а не держать его в подвешенном состоянии; сам конструктор остался в системе и переиспользуется в других отчётах. Модуль сдан по ТЗ — продуктовая идея под него у заказчика не выкристаллизовалась.
Результаты
| Метрика | Значение |
|---|---|
| Часы по ТЗ | 356 часов (65 + 90 + 100 + 16 + 85) |
| ТЗ в аналитическом блоке | 5 пронумерованных заказов |
| Что заместили | Ручную ежемесячную Excel-сводку аналитики сотрудниками |
| Архитектурное переиспользование | Все ТЗ опираются на конструктор табличных данных из ядра |
| Ключевой момент | Мастер-справочник классификации + нормализация адресов — без них аналитика по реальным данным разваливалась |
Встроенная аналитика закрыла прежний ручной цикл. Ежемесячную сводку теперь собирает группировщик, а не сотрудник в Excel. Гео-фильтры работают на грязных адресах за счёт нормализации по индексу, общий слой фильтров накрывает все таблицы, годовой график считается на дочернем сервере и основной не трогает. Мастер-справочник превращает разнобой формулировок из реестров в осмысленные классы. График живёт и обслуживается тем же разработчиком по сей день: в начале 2026-го заказчик написал, что график «не хочет показывать 2026 год», и это поправили в рамках сопровождения.
Процесс и хронология
| Этап | Период | Результат |
|---|---|---|
| Модуль запросника | IV кв. 2021 — фев. 2022 | 65 ч — конструктор запросов; концепция наполнения у заказчика не сложилась |
| Группировщик статистики | дек. 2021 | 90 ч — первый отчёт за неделю, открыт всем через две, +30 ч переработки сверх ТЗ |
| Гео-фильтры и разбор адресов | янв. 2022 | 100 ч — фильтр дата/регион/город, нормализация адресов по индексу + DaData |
| Фильтры общего отчёта + новости | июль 2022 | 16 ч — фед. округ, заявитель, ОГРН, ТР ТС; реализовано за 3 дня |
| Годовой график с мастер-справочником | фев. — апр. 2023 | 85 ч — собственный модуль вместо Grafana, дочерний сервер, мастер-справочник; закрыт с перерасходом за наш счёт |
Что заказчик решил не делать, мы тоже зафиксировали: апгрейд годового отчёта (середина 2023) завис на этапе просчёта, формального ТЗ не появилось; мульти-выбор нескольких федеральных округов в общем отчёте (декабрь 2023) оценили в 10 часов, заказчик отложил.
Команда
- Антон Херсун, Xaver Pro, руководитель проекта: требования к мастер-справочнику, формализация фильтров, развилка «Grafana или собственный модуль», инфраструктура дочернего сервера вычислений
- Разработчик аналитической панели: серверная и клиентская части аналитических модулей. Конструктор табличных данных, группировщик, запросник и годовой график написаны в рамках одного направления, которое ведётся с 2021 года. Любой модуль, написанный годы назад, дорабатывает тот же человек: годовой график правится по сей день.
Скриншоты и материалы
Будут добавлены отдельным проходом.
Если ваши отчёты до сих пор собираются вручную в Excel из выгрузок CRM или платформы, пришлите три самых частых типа. Скажем, во что выйдет перенести их внутрь системы и где высвободится первая полставка. Разбор ничего не стоит.