Словарь KPI для BI: как сделать единый справочник показателей

Почему подразделения спорят о цифрах в BI

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

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

Обычно конфликт вызывает сочетание четырех причин: разные формулы и округления (включать ли НДС, учитывать ли возвраты), разные фильтры и сегменты (только B2B или все каналы), разные периоды и правила среза (календарный месяц или 4 недели), разные источники (CRM против ERP, витрина против разовой выгрузки).

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

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

Что такое словарь KPI и зачем он нужен

Словарь KPI для BI - это единый источник правды о показателях: как они называются, что именно измеряют и как считаются. Он нужен не для красоты, а чтобы один и тот же KPI в разных отчетах давал одинаковое число и одинаковый смысл.

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

Обычно в словаре закрепляют: определение показателя простыми словами, формулу, правила округления, периодичность расчета, фильтры по умолчанию и границы применимости (где KPI уместен, а где нет). Полезно указывать связанные показатели, чтобы не путать похожие метрики, например «выручка» и «поступления».

Словарь связывает бизнес-цель, отчет и исходные данные. Простой пример: цель - снизить просрочку по платежам. В BI появляется отчет для финансов и продаж, а в словаре прописано, что «доля просроченной дебиторки» считается по конкретным статусам счетов, на дату среза и из конкретных таблиц ERP/CRM. Тогда отделы не начинают считать одно и то же разными способами.

Формат может быть разным: таблица, страница в корпоративной wiki или каталог метаданных в BI-платформе. Важно не где это хранится, а чтобы справочник был доступен, имел владельцев и обновлялся по правилам, а не «по звонку».

Структура карточки показателя: что фиксировать

Карточка показателя - это короткий паспорт KPI. Если карточки заполнены одинаково для всех метрик, словарь KPI для BI перестает быть набором «названий на дашборде» и становится источником общих правил.

Минимальный набор полей стоит сделать единым. Обычно хватает следующего:

• Название и короткое описание простыми словами.
• Формула расчета (включая точные поля и операции).
• Периодичность и момент обновления.
• Единицы измерения и округление.
• Где показывается KPI (конкретный отчет/дашборд и виджет).

Дальше нужно снять двусмысленности. В карточке фиксируют правила включения и исключения: что считается «продажей», входят ли возвраты, как учитывать отмены, внутренние перемещения, тестовые записи. Точно так же описывают фильтры по умолчанию: какие статусы документа берутся, какие даты считаются (дата заказа или дата отгрузки), в какой валюте идет расчет.

Если KPI смотрят в разрезах, не ограничивайтесь словами «по филиалам» или «по каналам». Запишите определения сегментов: что такое «филиал» (юрлицо или склад), как определяется «канал» (источник лида или тип договора), какие справочники считаются эталонными.

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

Роли и ответственность: владельцы и согласование

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

Обычно хватает трех ролей:

• Владелец KPI (бизнес) - утверждает смысл: что измеряем, зачем, какой период, какие целевые значения используются в отчетности.
• Владелец данных - отвечает за источник, качество, доступность, правила обновления и ограничения.
• Владелец расчета (BI/аналитика) - переводит определение в точную формулу, внедряет ее в модель данных и следит, чтобы расчет был воспроизводимым.

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

Пример: в производственной компании спорят о «выполнении плана». Производство считает по отгрузке со склада, продажи - по счетам, финансы - по оплате. Владелец KPI фиксирует смысл (например, «по оплаченным счетам»), владелец данных подтверждает источник (ERP/бухучет), BI-владелец реализует формулу и тест.

Если согласия нет, задайте правило эскалации: сначала встреча владельцев, затем решение у руководителя процесса (например, CFO для финансовых метрик) и финальная запись в карточку KPI с датой и ответственным. Это прекращает бесконечные «а у нас в отчете было иначе».

Источники данных и правила доверия к цифрам

Споры о KPI часто начинаются не с формулы, а с вопроса: «Из какой системы вы это взяли?» Поэтому в карточке показателя важно закрепить источник и уровень данных. Тогда словарь KPI для BI становится договоренностью о том, какие цифры считаются официальными.

Зафиксируйте перечень систем-источников и их роль. Например: ERP как главный источник по отгрузкам и остаткам, CRM по воронке и сделкам, Service Desk по обращениям и SLA, бухгалтерия по факту доходов и расходов, хранилище данных (DWH) как место, где данные сводятся и очищаются. Если показатель считается из нескольких систем, укажите, какая из них «побеждает» при расхождениях.

Важно записать и уровень данных: транзакции (первичные события), агрегаты (суммы и средние), витрины (готовые таблицы для отчетов) или ручные файлы. Ручные файлы лучше оставлять только как временное решение и сразу фиксировать срок, когда источник должен быть заменен на системный.

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

Перед публикацией KPI задайте минимальные проверки качества данных: проверьте полноту (нет ли провалов по датам и филиалам), дубликаты, актуальность справочников и статусов, корректность ключей для склейки систем (ID, ИИН/БИН, договор), а также свежесть загрузки. Когда эти правила описаны и выполняются, вопросы «почему у вас не так, как у нас» возникают заметно реже.

Формулы KPI: как описывать без двусмысленностей

Формула KPI должна быть понятна одинаково и руководителю, и аналитику. Удобно держать два слоя описания: бизнес-формулу (простыми словами) и техническую реализацию (как именно считать в данных). Тогда спор быстро сводится к одному вопросу: какая версия определения принята.

Начинайте с границ расчета. Явно перечислите, что входит в числитель и что входит в знаменатель. Если показатель долевой, сразу задайте правила для нулей и пропусков: что делать, если знаменатель равен нулю (возвращать 0, пусто или исключать из агрегации) и как трактовать отсутствующее значение (нет события или нет данных).

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

Чтобы формулу можно было повторить, используйте единый словарь терминов внутри нее. Например, определите, что такое «заявка», что значит «закрыта», какие даты используются (создания, закрытия, оплаты) и в какой временной зоне. Эти определения должны совпадать с тем, что есть в исходных системах.

Пример оформления

Бизнес-формула: «Доля закрытых заявок за день = количество заявок, закрытых в этот день, деленное на количество заявок, созданных в этот день. Отмененные и тестовые не учитываем».

Техническая реализация: отдельным блоком перечислите таблицы и поля (сущность, поле статуса, список статусов «закрыта», признак тестовой записи, правило по отмене), затем правило деления (что делаем при нуле в знаменателе) и уровень агрегации (по дням, отделам, филиалам).

Как спланировать и собрать справочник KPI: шаги

Начните не с «всех метрик компании», а с тех, из-за которых уже есть споры в отчетах. Это быстрее даст эффект и покажет, как будет работать процесс.

Практичный план на 2-4 недели

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

Дальше проведите короткие интервью с владельцами бизнеса и аналитиками: как показатель используют, какое решение он поддерживает и где он «ломается». В карточке KPI сразу фиксируйте определение простыми словами, периодичность, нужные разрезы (филиалы, продукты) и критерии успеха.

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

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

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

Процесс изменения формулы с версионированием

Формулы KPI нельзя менять «по-тихому». Любая правка меняет смысл показателя и влияет на планы, премии, отчеты для руководства и сравнение периодов. Изменения должны проходить через понятный процесс и фиксироваться в словаре KPI для BI.

Запрос на изменение обычно появляется в трех случаях: меняется бизнес-политика (например, иначе считаем возвраты), меняется источник или система (обновили поля в ERP/CRM), или обнаружилась ошибка в формуле и фильтрах. Если причина не ясна, лучше сначала уточнить, какую бизнес-логику KPI должен отражать.

Как оформить запрос на изменение

Хорошая заявка короткая, но полная. Достаточно зафиксировать:

• Причину изменения и ожидаемый эффект.
• Какие отчеты/дашборды и подразделения затронуты.
• Дату вступления (с какого периода считаем по-новому).
• Как работаем с историей (пересчитываем или оставляем как есть).

Версия, история и релиз

Каждая правка получает новую версию: номер, дата, автор (инициатор и исполнитель), описание «что изменилось» и «почему». В карточке KPI храните текущую формулу и журнал изменений. Так проще объяснить, почему цифры в январе и феврале разъехались.

Главный вопрос совместимости - что делать со старыми периодами. Обычно выбирают один из вариантов: пересчитать историю (если KPI нужен для трендов) или «заморозить» прошлое и применять новую формулу только с даты вступления. Решение нужно записать явно, иначе сравнения будут некорректны.

Перед релизом формулу тестируют на контрольной выборке: сверяют с источником, проверяют крайние случаи (пустые значения, отмененные сделки, дубликаты), затем проводят приемку у владельца показателя. После утверждения уведомляют владельцев данных, команду BI, финансовый контроль и пользователей ключевых отчетов, чтобы новые цифры не выглядели как «BI сломался».

Типичные ошибки при ведении KPI-словаря

Самая частая проблема: один и тот же KPI живет под разными названиями. В одном отчете это «Выручка», в другом «Продажи», в третьем «Revenue». Если в словаре нет единого определения и списка синонимов, люди обсуждают разные вещи и думают, что спорят об одном.

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

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

Отдельная боль - отсутствие владельца и следов изменений. Формула тихо меняется «чтобы было правильнее», а через месяц никто не может объяснить скачок на графике. Для словаря KPI для BI обязательно нужна ответственность и журнал: кто изменил, когда, почему и с какого отчета применяем.

Еще один риск - зависимость от ручных файлов без расписания обновлений и контроля качества. Когда KPI считается из Excel, но никто не знает, кто его обновляет и что делать при пропуске, BI начинает показывать вчерашний мир.

Понять, что словарь ведут неправильно, помогают простые признаки: один KPI в разных дашбордах отличается на 1-5% без объяснения; новые сотрудники не могут повторить расчет по описанию; «временные» исключения становятся постоянными; формулы живут в чатах, а не в карточке показателя; KPI публикуют без проверки на нескольких реальных кейсах.

Быстрый чеклист перед публикацией и обновлениями

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

Убедитесь, что у показателя назначены ответственные: владелец смысла (бизнес) и владелец источника (данные). Если это один и тот же человек, так и зафиксируйте.

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

Короткая проверка перед релизом:

• Единицы измерения, округление и период расчета (день/неделя/месяц; по дате события или по дате проведения в системе).
• Тест на крайние случаи: деление на ноль, пустые значения, неполный период.
• Актуальность источника: время последней загрузки и проверка полноты.
• Все места использования KPI: дашборды, витрины, выгрузки, управленческие отчеты.
• Версия, дата вступления в силу и краткое описание изменения.

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

Пример сценария: согласуем KPI между отделами

Колл-центр, бэк-офис и финансы смотрят один дашборд, но спорят о KPI «срок обработки заявки». Колл-центр считает, что заявка обработана, когда оператор поставил статус «Готово». Бэк-офис - когда выполнена проверка и сформирован документ. Финансы - когда поступила оплата. Цифры расходятся, хотя все уверены, что правы.

Первый шаг - описать объект измерения простыми словами: что именно считается «заявкой». Например: «уникальная запись в CRM с типом “Новая заявка” и идентификатором lead_id». Тут же фиксируем момент старта: «дата и время первого присвоения статуса “Принята”» или «время создания записи», но не оба одновременно.

Дальше договариваемся о моменте окончания. Чтобы не смешивать работу и деньги, часто вводят две метрики: «операционный срок» (до “Закрыта оператором”) и «финансовый срок» (до “Оплачена”). Если нужна ровно одна, выбираем одно событие и называем KPI так, чтобы смысл был честным, например «срок до оплаты».

Чтобы спор не возвращался, заранее прописываем граничные случаи:

• Переоткрытие: считать только первое закрытие или последнее.
• Паузы: включать ожидание клиента или исключать.
• Отмена: исключать из расчета или считать отдельной категорией.
• Дубликаты: правило дедупликации (по телефону, ИИН, email).
• Частичная оплата: что считается завершением.

Отдельно фиксируем витрину и период: показатель считается по дате создания заявки или по дате закрытия. Это влияет на план-факт по неделям и на «хвосты» в конце месяца.

Оформляем версию KPI 1.0: формула, источники (например, таблица CRM и статусы), точные поля времени, правила фильтрации. И сразу план изменения при переходе на новую CRM: версия 2.0, дата вступления, соответствие статусов (старый «Закрыта» = новый «Resolved») и период параллельного расчета (например, 1 месяц), чтобы сравнить расхождения и обновить дашборды без сюрпризов.

Следующие шаги: как поддерживать словарь и масштабировать BI

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

Начните с ответственности. У каждого показателя должен быть бизнес-владелец (что означает KPI и зачем он нужен) и технический владелец (откуда данные и как считается). Добавьте короткий регламент: как часто пересматриваем показатели, кто утверждает изменения и что считается критичным изменением (например, смена источника или логики расчета).

Практика, которая часто работает: небольшой комитет по метрикам (2-4 человека из финансов, бизнеса и данных). Раз в месяц он закрывает накопившиеся запросы и следит, чтобы новые дашборды не появлялись без карточек показателей.

Для минимального набора достаточно трех вещей: шаблон карточки KPI, журнал изменений и правила приемки (как проверяем цифры перед публикацией). Главное - чтобы эти материалы были одинаковыми для всех подразделений.

Если BI, хранилище данных и число источников растут быстрее, чем успевают договоренности, стоит подключать системного интегратора. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане помогает проектировать инфраструктуру для BI и хранилищ данных, выстраивать процессы управления метриками и данными (роли, регламенты, контроль качества) и поддерживать решения в режиме 24/7 через сервисную сеть по стране.