Data Governance Audit проверяет не качество самих данных (для этого есть Data Quality Audit) и не единство мастер-данных (Master Data Audit), а то, есть ли в компании вообще формальная структура управления данными: назначены ли владельцы, задокументированы ли политики, определены ли права доступа. Компания может иметь идеально чистые данные и при этом не иметь никакого governance — просто потому, что повезло, а не потому, что построена система, которая это гарантирует в будущем.
Происхождение и исследовательская база
Дисциплина Data Governance систематизирована как отдельная область знаний в DAMA-DMBOK (Data Management Body of Knowledge), своде знаний по управлению данными от DAMA International — governance определяется там как совокупность политик, ролей, стандартов и процессов, обеспечивающих эффективное использование данных для достижения целей организации.
Ключевое разделение ролей, которое вводит дисциплина, — между владельцем данных (Data Owner), который несёт бизнес-ответственность и принимает стратегические решения по домену данных, и стюардом данных (Data Steward), который операционно отвечает за качество и правильное использование данных день в день. Разделение этих ролей — не бюрократическая формальность, а признание того, что стратегические решения и операционная работа требуют разных компетенций и полномочий.
Ключевые идеи и принципы
Принцип: governance — это структура принятия решений, а не сами данные
Аудит governance не спрашивает "хорошие ли у нас данные" — он спрашивает "кто решает, что делать с данными, если возникает вопрос или конфликт". Без явной структуры принятия решений даже качественные данные остаются уязвимыми к деградации, потому что никто формально не отвечает за их поддержание.
Принцип: владение и операционная ответственность — разные роли
Владелец данных решает "что можно делать с этими данными" на стратегическом уровне (например, разрешить ли доступ новому отделу). Стюард данных обеспечивает "чтобы данные оставались корректными" на операционном уровне. Смешение этих ролей в одном человеке или, хуже, отсутствие обеих ролей — источник систематических проблем.
Принцип: приоритизация governance-усилий — по разрыву между критичностью и зрелостью
Не все домены данных одинаково важны для бизнеса — governance-усилия логично направлять туда, где разрыв между тем, насколько данные критичны, и тем, насколько зрело ими управляют, максимален, а не распределять внимание равномерно по всем доменам.
Принцип: каталог данных — предпосылка, без которой governance невозможен
Нельзя управлять тем, о существовании чего не знаешь — актуальный каталог данных (что за данные есть, где хранятся, кто владелец) — базовая инфраструктура, без которой все остальные элементы governance повисают в воздухе.
Governance — это не про то, насколько чисты данные сегодня. Это про то, кто отвечает за то, чтобы они оставались чистыми завтра.
Ограничения, слепые зоны и критика
Формальная структура governance (роли, политики, комитеты) без реального авторитета и вовлечённости назначенных людей превращается в бумажную формальность — назначение "владельца данных" не решает проблему, если у этого человека нет ни времени, ни полномочий реально исполнять роль.
Избыточно бюрократизированный governance (сложные процедуры согласования для любого изменения) может замедлить операционную работу компании больше, чем оправдывает реальный риск — баланс между контролем и скоростью требует сознательного выбора, а не автоматического максимума формальности.
Полноценная governance-структура для всех доменов данных сразу — избыточная инвестиция для маленькой компании; практический подход обычно начинается с наиболее критичных доменов и постепенно расширяется.
Типовые ошибки
Ошибка 1: роли владельца и стюарда не разделены или вообще не назначены.
Ни для одного домена данных формально не назначен ни владелец, ни стюард — ответственность размыта между всеми и никем одновременно.
Как избежать: явно назначить и владельца, и стюарда для каждого ключевого домена данных, с чётким разделением стратегической и операционной ответственности.
Ошибка 2: политики использования данных существуют только в устной традиции.
Правила хранения, использования, удаления данных известны неформально, но нигде не задокументированы — при смене сотрудников знание теряется.
Как избежать: формально документировать все ключевые политики использования данных, а не полагаться на устную передачу знаний.
Ошибка 3: governance-усилия распределяются равномерно, без учёта критичности домена.
Одинаковое внимание уделяется малозначимым и критически важным доменам данных, вместо приоритизации по реальной значимости для бизнеса.
Как избежать: явно сравнивать критичность и текущую зрелость управления по каждому домену, направляя усилия на домены с наибольшим разрывом.
Ошибка 4: каталог данных отсутствует или устарел.
Компания не имеет актуального представления, какие данные вообще существуют, где хранятся и кто ими владеет.
Как избежать: вести и регулярно обновлять каталог данных как базовую инфраструктуру, предшествующую остальным элементам governance.
Ошибка 5: соответствие регуляторным требованиям не отслеживается систематически.
Проверка на соответствие требованиям (например, защита персональных данных) происходит разово или реактивно, а не как постоянный процесс мониторинга.
Как избежать: внедрить регулярный, а не разовый процесс мониторинга соответствия регуляторным требованиям к данным.
Главное, что нужно знать
Governance проверяет структуру принятия решений по данным, а не качество самих данных.
Владелец данных (стратегическая ответственность) и стюард данных (операционная ответственность) — разные, не взаимозаменяемые роли по DAMA-DMBOK.
Приоритизация governance-усилий строится на разрыве между критичностью домена данных и текущей зрелостью управления им.
Актуальный каталог данных — базовая предпосылка, без которой остальные элементы governance невозможны.
Формальная структура без реального авторитета и вовлечённости назначенных людей превращается в бумажную формальность.
План внедрения
Недели 1-2 — инвентаризация текущего состояния. Проверить, какие из шести элементов governance реально функционируют, составить или актуализировать каталог данных.
Недели 3-4 — назначение ролей и приоритизация доменов. Назначить владельцев и стюардов для ключевых доменов данных, оценить их зрелость и критичность.
Недели 5-6 — документирование политик и внедрение мониторинга. Формально задокументировать политики использования данных, внедрить регулярный мониторинг соответствия требованиям.
Далее: поддержание и обновление. Регулярно пересматривать зрелость governance по доменам, актуализировать каталог данных и политики при изменениях в компании.
Как реализовать этот план с помощью фрейма «Data Governance Audit» в OrgDevTools
Фрейм «Data Governance Audit» в OrgDevTools напрямую поддерживает план внедрения. На этапе инвентаризации (недели 1-2) заполните чек-лист «6 обязательных элементов governance» — счётчик покрытия сразу показывает, каких элементов структуры управления данными не хватает.
На этапе приоритизации (недели 3-4) заполняйте таблицу «Домены данных — зрелость vs критичность» — для каждого домена оцените текущую зрелость управления и реальную критичность для бизнеса; фрейм автоматически рассчитывает и подсвечивает разрыв, давая объективный приоритет, куда направить governance-усилия в первую очередь — устраняя Ошибку 3 (равномерное распределение усилий) из списка выше.