BI-отчётность в закрытом контуре: моя работа с DataLens

От страхового учёта до аналитики

В проекте «ЭкстраПолис» я работаю с аналитикой договоров и полисов. Источник страховых данных — 1С; для BI они передаются во внутреннюю аналитическую среду, где используются ClickHouse и развёрнутый внутри компании DataLens. Инфраструктуру развернула другая команда. Моя зона ответственности — понять структуру и смысл данных, подготовить необходимые выгрузки и датасеты, реализовать расчёты и проверить результат.

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

Кейс: признак продления полиса

Одна из задач касалась аналитики продления договоров. В исходной отчётности договор считался продлением, а в BI у части записей отображался противоположный признак. Простое исправление значения в DataLens скрыло бы причину и могло бы создать новые ошибки. Нужно было выяснить, как признак появляется в учётной системе и что именно передаётся в аналитический слой.

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

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

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

Второй тип расхождений: соединение выгрузок

При объединении данных из разных отчётов встречалась и другая проблема. Визуально одинаковые идентификаторы не всегда совпадали как строки: мешали пробелы и особенности формата. Я проверяла реальные значения, нормализовала ключи и адаптировала SQL к диалекту ClickHouse и возможностям внутреннего DataLens. После этого соединение нужно было вновь сверить на конкретных договорах, а не ограничиваться тем, что запрос перестал возвращать пустые значения.

Мой результат и границы кейса

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

Для ревью перед публикацией

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