Война цифр между отделами — не техническая проблема, а организационная. Новый BI её не решит, пока не зафиксированы определения метрик и не назначены owners. Этот playbook даёт 5 шагов, реализуемых за 1–2 недели в Excel или Google Sheets: инвентаризация отчётов → диагностика типа дубля → выбор мастер-источника → metric dictionary → протокол эскалации. Почему цифры расходятся: типология дублей Прежде чем что-то чинить, нужно понять, почему второй отчёт вообще появился. Это не саботаж и не некомпетентность — у каждого дубля есть рациональная причина. Без её диагностики вы устраните симптом, но не корень. Тип дубля | Корневая причина | Способ устранения Разные определения термина | «Выручка» в продажах — дата договора, в финансах — дата оплаты | Зафиксировать единое определение в metric dictionary, выбрать одно событие-триггер Разные периоды среза | Один отчёт — календарный месяц, другой — операционный (с 25-го по 25-е) | Договориться о стандартном периоде для управленческих совещаний Разные системы-источники | CRM считает сделки, 1С — отгрузки, Excel — вручную сведённое | Назначить мастер-источник для каждой метрики, остальные — справочные Ручная трансформация при выгрузке | Аналитик «подчищает» данные по своей логике, не задокументированной нигде | Задокументировать трансформацию или перенести её в источник Устаревший отчёт в обращении | Старый Excel продолжают использовать по привычке, хотя появился новый | Явно вывести из обращения: поставить статус «устарел», дать ссылку на актуальный Политический дубль | Отдел ведёт свой отчёт, потому что официальный показывает их результаты хуже | Нейтральный арбитр, прозрачная методология, фиксация договорённостей письменно Технический дубль | Два разных запроса к одной базе дают разный результат из-за фильтров | Зафиксировать канонический SQL/запрос, сделать его общедоступным Определите тип дубля до того, как переходить к шагам. Это займёт 30 минут и сэкономит недели споров. Шаг 1. Инвентаризация за один день Возьмите одну конфликтную метрику — ту, которая вызвала последний публичный спор на совещании. Не пытайтесь охватить всё сразу: это главный антипаттерн, убивающий подобные инициативы. Чеклист аудита отчётов по одной метрике: • Кто в компании сейчас формирует отчёт с этой метрикой? (перечислите всех, включая смежные отделы) • Из какой системы берутся данные для каждого отчёта? (1С, CRM, Excel, выгрузка из банка, вручную) • Какое определение метрики использует каждый отдел? (попросите каждого написать одним предложением) • За какой период строится каждый отчёт? (календарный месяц, операционный, скользящие 30 дней) • Какие фильтры или исключения применяются? (например, «без НДС», «только закрытые сделки», «без возвратов») • Как часто обновляется каждый отчёт? (в реальном времени, раз в день, раз в неделю, вручную перед совещанием) • Кто является потребителем каждого отчёта? (кто реально читает и принимает решения на его основе) • Есть ли отчёты, которые формировались раньше, но формально не отменены? Результат инвентаризации — таблица в Google Sheets или Excel: строки — отчёты, столбцы — ответы на вопросы выше. Уже на этом шаге обычно становится видно, что 2–3 отчёта описывают разные вещи под одним названием. Шаг 2. Выбор мастер-источника После инвентаризации нужно выбрать один источник, который будет считаться главным. Это организационное решение, не техническое. Алгоритм выбора для типичного РФ-стека: Начните с вопроса: для чего используется метрика? Если метрика используется для финансовой отчётности и управленческих решений → мастер-источник — 1С (или ERP). Причина: 1С содержит проводки, которые имеют юридическую силу и прошли через бухгалтерский контроль. Это де-факто стандарт для финансовых метрик в РФ. Если метрика используется для оперативного управления продажами (воронка, конверсия, активность менеджеров) → мастер-источник — CRM (Bitrix24, amoCRM). Причина: CRM фиксирует события в реальном времени, 1С отражает их с задержкой после закрытия сделки. Если метрика живёт только в Excel — это сигнал, что ни одна система не закрывает потребность отдела. Прежде чем назначать мастер-источник, нужно понять, почему Excel появился: либо настроить выгрузку из существующей системы, либо признать, что метрика нужна, но нигде не автоматизирована. Правило конфликта 1С vs CRM: если цифры расходятся, обе могут быть правы — они считают разные события. Задача не выбрать «победителя», а зафиксировать, что каждая метрика означает, и использовать нужную в нужном контексте. Для совещания с CFO — 1С. Для планёрки отдела продаж — CRM. Шаг 3. Metric dictionary — минимальный артефакт Словарь метрик — это не BI-инструмент и не база данных. Это Google-таблица или Confluence-страница с одной строкой на каждую метрику. Минимальный шаблон: Поле | Пример заполнения Название метрики | Выручка (управленческая) Определение | Сумма оплаченных счетов за период, без НДС, без возвратов Мастер-источник | 1С: Бухгалтерия, отчёт «Реализация товаров» Owner (роль + имя) | CFO / Иванова А.В. Формула / фильтры | Сумма по Дт 62 за период, исключая статус «Возврат» Период обновления | Ежемесячно, до 5-го числа следующего месяца Статус | Актуален Справочные источники | CRM (оперативно), Excel маркетинга (не использовать для управленческих решений) Заполните словарь сначала для одной метрики. Покажите его всем отделам, которые участвовали в конфликте. Дайте неделю на замечания. Зафиксируйте финальную версию письменно — это и есть договорённость. Кто должен быть owner: бизнес-руководитель, который использует метрику для решений, — не IT. IT отвечает за техническую корректность выгрузки (роль custodian), но не за бизнес-логику определения. Шаг 4. Протокол разрешения конфликта Даже после фиксации metric dictionary конфликты будут возникать — особенно при изменении бизнес-процессов. Нужен заранее согласованный протокол. 3-шаговый процесс: Шаг 4.1. Диагностика за 24 часа. Owner метрики собирает данные: в чём именно расхождение, какие отчёты участвуют, какой период. Если расхождение объясняется разными определениями или периодами — это не конфликт, это разные метрики. Фиксируется в metric dictionary как отдельная строка. Шаг 4.2. Согласование между owners за 48 часов. Если расхождение не объясняется определением — owners двух отделов встречаются (30 минут), сверяют исходные данные, находят точку расхождения. Результат фиксируется письменно: либо обновляется определение в словаре, либо выявляется техническая ошибка в выгрузке. Шаг 4.3. Эскалация к нейтральному арбитру. Если owners не договорились — решение принимает CFO или COO. Это не слабость процесса, а его нормальная часть: политический аспект реален, и отдел, чьи цифры «проигрывают», нуждается в авторитетном решении сверху. Арбитр фиксирует решение письменно, оба отдела подтверждают получение. Важно: отдел, чей отчёт признан не мастер-источником, не должен просто «проиграть». Объясните логику выбора. Дайте переходный период 2–4 недели, в течение которого оба отчёта ведутся параллельно. Удаляйте дублирующий отчёт только после того, как отдел убедился в совпадении цифр. Шаг 5. Метрики здоровья процесса Как понять, что проблема решена? Не по ощущениям — по измеримым показателям. KPI | Как измерять | Цель Количество активных версий отчёта по ключевой метрике | Подсчёт файлов/отчётов в обращении | ≤ 1 на метрику Доля метрик с назначенным owner и зафиксированным определением | (Метрики в словаре со статусом «актуален») / (топ-10 управленческих метрик) | 100% для топ-10 Время сверки данных перед еженедельным совещанием | Опрос участников: сколько минут уходит на «а у меня другая цифра» | Сокращение на 50% за первый месяц Количество эскалаций «чья цифра правильная» за квартал | Лог обращений к арбитру | 0 по зафиксированным метрикам Доля отчётов со статусом «устарел», выведенных из обращения | (Устаревшие, удалённые или заархивированные) / (все устаревшие в словаре) | 100% в течение 30 дней после фиксации Время от запроса метрики до согласованного ответа | Замер по реальным запросам | < 1 рабочего дня Снимайте эти показатели раз в месяц в первые три месяца. Если время сверки не сокращается — значит, metric dictionary не используется на практике: нужно разобраться, почему. Антипаттерны, которые убивают инициативу Несколько ошибок, которые повторяются независимо от размера компании: • Начинать с выбора инструмента. BI, ETL, MDM не решат проблему, если определения метрик не зафиксированы. Инструмент автоматизирует хаос. • Объявлять один отчёт правильным без объяснения логики. Отдел, чей отчёт «проиграл», продолжит вести свой параллельно — молча. • Делать data owner IT-отдел для бизнес-метрик. IT не знает, почему «выручка без агентского вознаграждения» важна именно для этого отдела. • Удалять дублирующий отчёт без переходного периода. Пользователи вернутся к Excel через две недели. • Считать проблему технической. Чаще всего корень — в разных определениях одного термина, а не в разных базах данных. Что дальше После того как процесс отработан на одной метрике, распространяйте его на следующую — по приоритету болезненности. Через 2–3 итерации у вас будет живой metric dictionary на 10–15 ключевых метрик и работающий протокол разрешения конфликтов. Если на этом этапе возникает вопрос «а стоит ли теперь внедрять BI» — это отдельное решение с другими критериями. Его разбор — в статье «Когда BI ещё не нужен: как понять, что пора». Metric dictionary — это не временная мера. Это минимальная инфраструктура данных, которая работает независимо от того, есть у вас BI или нет. Даже если вы внедрите платформу позже, словарь метрик станет её техническим заданием — и сэкономит месяцы на согласование требований. *brezatech — интегратор ИИ в данные и процессы: разработка аналитических решений, автоматизация и BI для B2B-компаний в РФ.* Ключевые факты • По данным Infostart (2026), в типичной B2B-компании РФ одна финансовая метрика живёт одновременно в 3–5 версиях: 1С, Excel финансов, CRM продаж, выгрузка маркетинга. • BI Curated (2025) фиксирует: бизнес-юниты строят теневые таблицы в обход корпоративных систем не из вредности, а потому что официальный отчёт не отвечает на их вопрос вовремя. • Krause Analytics (2026): корень конфликта метрик — не разные базы данных, а разные определения одного термина между отделами. Инструмент автоматизирует хаос, если определения не зафиксированы до внедрения. • Цель процесса — не одна база данных, а одно определение метрики и один назначенный owner. Это достижимо без MDM и без нового BI. • Метрика здоровья: время сверки данных перед совещанием. Цель — сократить на 50% за первый месяц после фиксации metric dictionary.