Контроль качества данных в корпоративных отчётах

Проблема, которая скрывается за красивыми дашбордами

Компания открывает квартальный отчёт — и обнаруживает, что выручка по одному подразделению не сходится с данными CRM, а два разных отчёта по одному и тому же клиенту показывают разные суммы задолженности. Разбирательство обычно упирается не в ошибку бухгалтера и не в баг в Excel-формуле, а в то, что данные для отчёта собирались из нескольких систем, которые по-разному называют одного и того же контрагента, по-разному округляют суммы или обновляются с разной периодичностью.

Аналитики называют это «мусор на входе — мусор на выходе»: сколько бы аналитики и BI-инструментов ни стояло на выходе, если в исходных данных есть дубли, пропуски и рассинхронизация, отчёт унаследует все эти проблемы. По оценке Gartner, низкое качество данных обходится организациям в среднем в 12,9 млн долларов ежегодных потерь — за счёт неверных решений, повторной работы и упущенных возможностейGartner estimates that every year, poor data quality costs organizations an average of $12.9 million.

Материал будет полезен финансовым директорам, руководителям отделов аналитики и данных, ИТ-директорам и владельцам бизнеса, которые хотят понимать, за счёт чего отчётность становится надёжной — и что для этого нужно выстроить в компании.

Какие свойства данных нужно проверять

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

• Полнота: обязательные поля и периоды присутствуют.
• Точность: значения соответствуют первичному источнику и бизнес-правилам.
• Уникальность: одна сущность не размножается из-за разных ключей и написаний.
• Свежесть: данные обновились в допустимый срок.
• Согласованность: связанные системы одинаково трактуют клиента, товар, документ и статус.

Такие измерения используются и в промышленных инструментах управления данными: среди типовых характеристик Microsoft перечисляет accuracy, completeness, conformity, consistency, timeliness и uniqueness [4].

Где ставить проверки качества

Контроль полезен на нескольких уровнях. На вводе он не пропускает заведомо неверный формат. В интеграции проверяет обязательные поля, справочники и связность. В витрине сверяет полноту периодов и дубли. Перед публикацией отчёта сопоставляет контрольные итоги с источником.

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

Практический результат — три связанных артефакта: реестр проверок, реестр обнаруженных проблем и отчёт о качестве. Такой состав прямо встречается в рекомендациях Банка России по организации процесса качества данных [3].

Внутренний контроль и достоверность отчётности

Для бухгалтерской отчётности вопрос качества данных связан с обязанностью организовать внутренний контроль. Статья 19 закона № 402-ФЗ закрепляет внутренний контроль совершаемых фактов хозяйственной жизни, а для организаций, чья отчётность подлежит обязательному аудиту, — также внутренний контроль ведения учёта и составления отчётности [1][2].

Это не означает, что каждой компании нужна отдельная Data Quality-платформа. Но правила сверки, ответственные и доказуемый порядок исправления расхождений полезно закрепить там, где данные из нескольких систем формируют финансовые или управленческие показатели.

Варианты организации контроля качества данных

На практике компании выбирают один из нескольких путей — часто их комбинируя.

Ручные регламенты и чек-листы. Подходит для небольших компаний с несколькими системами учёта: закреплённые процедуры сверки, чек-листы перед закрытием периода, назначенные ответственные за конкретные справочники. Плюс — низкий порог входа, минус — низкая устойчивость к росту объёма данных и человеческий фактор.

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

Отдельная система/платформа управления качеством данных и MDM. Для компаний с несколькими учётными системами, филиальной структурой или большим объёмом справочной информации имеет смысл выделенное решение для управления НСИ: единый эталонный справочник, автоматическая дедупликация, правила сведения записей из разных источников в однуСбор и подготовка — доставка исходных, несогласованных, противоречивых и дублирующихся мастер-данных из различных источников данных и приложений; Анализ и исследование — исследование содержания, взаимного соответствия и структуры данных на наличие проблем качества, дублей и несоответствий; Обработка — устранение ошибок и несоответствий, стандартизация данных; Агрегация — объединение множество версий в одну «эталонную» запись для всего предприятия. Такой подход даёт наибольшую устойчивость, но требует более серьёзных вложений на старте и, как правило, отдельного проекта интеграции с существующими системами.

Интеграционный слой с контролем на границах систем. Если ошибки возникают в первую очередь при обмене данными между CRM, ERP, 1С и внешними сервисами, точку контроля логично выносить именно в интеграционный слой — API, шину данных или брокер сообщений, — где данные можно проверять и приводить к единому формату до того, как они попадут в отчётную систему. Здесь важно заранее продумать: какие системы участвуют в обмене, какие данные передаются, как происходит авторизация запросов, как обрабатываются ошибки и отклонённые записи, какие доступы нужны каждой стороне и как это тестируется перед запуском в промышленную эксплуатацию.

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

Практические этапы внедрения контроля качества данных

1. Инвентаризация источников. Зафиксировать, какие системы участвуют в формировании отчётности, какие данные и в каком виде из них берутся.
2. Профилирование и диагностика. Проверить реальное состояние данных: дубли, пропуски, рассинхронизацию между системами, нарушения целостности.
3. Формулирование требований к качеству. Определить вместе с бизнес-заказчиками отчётности, какие показатели критичны и какая погрешность или задержка недопустима.
4. Разработка правил контроля. Формально описать правила проверки — форматно-логические, сверочные, справочные — и определить, где именно в процессе они применяются.
5. Внедрение точек контроля. Встроить проверки в системы ввода, интеграции или в отдельный слой контроля качества данных, по возможности как можно ближе к источнику ошибки.
6. Мониторинг и отчётность по качеству данных. Настроить регулярное отслеживание метрик качества — отдельно от самой бизнес-отчётности, чтобы проблемы были видны до того, как они попадут в квартальный отчёт.
7. Закрепление ответственности. Назначить владельцев данных (data owners) по ключевым доменам — клиенты, контрагенты, номенклатура, финансовые показатели.
8. Тестирование и обучение. Проверить работу правил на реальных данных, обучить сотрудников, которые вносят данные вручную, — часто именно здесь возникает основная доля ошибок.

Ограничения, типичные ошибки и риски

• Контроль «на выходе», а не «на входе». Самая частая ошибка — проверять данные только на этапе формирования готового отчёта. К этому моменту исправление ошибки может требовать пересчёта уже закрытого периода.
• Отсутствие единого владельца данных. Если за качество справочников отвечают все понемногу, не отвечает по факту никто — а расхождения между отделами так и накапливаются.
• Игнорирование мастер-данных. Компании часто вкладываются в аналитику и BI, но не наводят порядок в справочниках — в результате красивый дашборд строится на данных с дублями и рассинхронизацией.
• Формальный подход к внутреннему контролю. Прописанный «для галочки» регламент внутреннего контроля по 402-ФЗ, который не подкреплён реальными процедурами проверки, не защищает от искажений отчётности и не снимает регуляторных и аудиторских рисков.
• Излишняя строгость правил. Слишком жёсткие правила контроля качества могут блокировать легитимный ввод данных и создавать дополнительную ручную работу — важно балансировать между строгостью и практичностью.
• Недооценка стоимости плохих данных. Проблема часто остаётся невидимой в моменте: расходы прячутся в повторной работе, ошибочных решениях и недоверии к отчётности, а не проявляются как отдельная строка бюджета — что и объясняет, почему компании годами откладывают инвестиции в контроль качества данных.

Как выбрать решение под свою задачу

Если ошибки в отчётности единичны и локализованы в одном-двух процессах, часто достаточно закрепить регламент, настроить проверки в существующей учётной системе и назначить ответственного за конкретный справочник — без отдельного проекта или новой платформы.

Если же расхождения системны, данные ведутся в нескольких независимых системах, а сверка перед каждой отчётностью занимает недели, — вероятно, необходим отдельный проект: аудит источников данных, выстраивание интеграций с контролем на границах систем и, возможно, внедрение решения для управления мастер-данными. В этом случае важно заранее понимать, какие интеграции потребуются, как будет организован обмен данными между системами и кто будет сопровождать это решение после запуска.

Вывод

Качество отчёта определяется не в момент его формирования, а на всех предыдущих шагах — от ввода данных до их обмена между системами. В России это не только вопрос управленческой зрелости, но и прямая обязанность по 402-ФЗ: организовать внутренний контроль фактов хозяйственной жизни и обеспечить достоверность отчётности. Компании, которые выстраивают контроль качества данных как постоянный процесс — с профилированием, правилами, мониторингом и закреплённой ответственностью, — реже сталкиваются с расхождениями в отчётах, замечаниями аудиторов и репутационными рисками при публикации отчётности в ГИРБО.

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

Источники

[1] Минфин России — Федеральный закон № 402-ФЗ «О бухгалтерском учёте» — https://minfin.gov.ru/ru/document?id_4=15014-federalnyi_zakon_ot_06.12.2011__402-fz_o_bukhgalterskom_uchete

[2] КонсультантПлюс — статья 19 закона № 402-ФЗ о внутреннем контроле — https://www.consultant.ru/document/cons_doc_LAW_122855/77f9b18f9bb66d5b1f255b2624622b229930993a/

[3] Банк России — рекомендации по процессу «Качество данных» — https://www.cbr.ru/Content/Document/File/170699/recommendations_27122024_3.PDF

[4] Microsoft Learn — правила и измерения качества данных — https://learn.microsoft.com/en-us/purview/data-governance-get-started