Как новые сущности Arenadata Catalog превращают данные в управляемый актив

Статья объясняет назначение и бизнес-ценность новых сущностей, показывает их связь с общепринятыми практиками управления данными и даёт два пошаговых сценария внедрения: с нуля (раздел 4) и поверх уже наполненного информацией каталога (раздел 5). Для наглядного разъяснения процессов мы описали сквозной пример управления данными HR-блока на базе условной компании «Промтех» (раздел 6): данные о сотрудниках есть в любой организации, поэтому описанные в статье шаги одинаково применимы в банке, производственной компании, IT и госсекторе, а пример легко воспроизвести в собственном каталоге с помощью чек-листа внедрения (Приложение).

1. Разъяснение сущностей: домены и дата-продукты

1.1. Что такое домен данных

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

В интерфейсе Arenadata Catalog домены живут в отдельном разделе «Домены» в боковой панели. У каждого домена есть техническое наименование, бизнес-наименование, описание, владелец — команда или пользователь, теги, иерархия «родитель — поддомен» и связи с другими сущностями каталога.

Карточка домена устроена интуитивно просто. Шесть вкладок отражают всё, что нужно знать о бизнес-области:

• «Основная информация» — описание, разметка классификаторами, владелец; здесь же отображаются пользовательские атрибуты.
• «Поддомены» — дочерние объекты; отсюда же создаются новые поддомены.
• «Дата-продукты» — продукты данных, выпускаемые этим доменом.
• «Объекты» — таблицы, дашборды, топики и другие ассеты, принадлежащие домену.
• «Участники» — пользователи и команды, работающие с доменом.
• «Связанные объекты» — связи с глоссарием и другими сущностями каталога.

Главная ценность домена для бизнеса — он делает зону ответственности видимой. Раньше «кто отвечает за HR-данные» было вопросом к памяти отдельных людей; теперь это поле карточки, обновляемое одним кликом.

1.2. Что такое дата-продукт

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

Идея продуктового подхода к данным проста: данные нужно проектировать как самостоятельный продукт, а не как побочный результат работы информационных систем. У хорошего дата-продукта есть набор обязательных качеств: он обнаруживаемый (его можно найти поиском), понятно описанный (дата-продукту можно задать описание, расширить карточку пользовательскими атрибутами), заслуживающий доверия (можно назначить владельца) и защищённый (доступ до объекта регулируется политиками доступа). Карточка дата-продукта в Arenadata Catalog закрывает каждый из этих пунктов штатными средствами.

В карточке продукта есть шапка с основной информацией по объекту, а также вкладки:

• «Основная информация» — описание, разметка классификаторами, расширенные атрибуты.
• «Объекты» — состав продукта: таблицы, дашборды, модели данных дашбордов, топики, конвейеры, ML-модели, объекты глоссария, контейнеры, хранимые процедуры.
• «Связанные объекты» — связи с глоссарием и другими объектами каталога через настраиваемые типы связей.

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

1.3. Дата-контракт: следующий шаг модели

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

Полноценные дата-контракты — в планах развития функциональных возможностей Arenadata Catalog (см. раздел 7.2). Важно учесть одно: всё, что вы делаете с доменами и дата-продуктами сейчас, готовит почву для контрактной модели, поскольку переделывать ничего не придётся.

1.4. Иерархия и наследование

Иерархия домена двухуровневая: домен и поддомен. У карточки поддомена нет вкладки «Поддомены» — глубина дерева ограничена намеренно, чтобы декомпозиция не превращалась в многоэтажную бюрократию. Дата-продукты живут внутри домена или поддомена, но третьим уровнем иерархии не считаются — это отдельная сущность. Типовая корпоративная архитектура насчитывает 15–25 доменов: «Бюджетирование», «Клиенты», «Коммерция», «Логистика и складирование», «Маркетинг», «Менеджмент кадров», «Финансы» и другие. В этой статье мы подробно разберём один из них — «Менеджмент кадров».

К ключевой технической особенности относится наследование принадлежности к домену вниз по иерархии объектов. Назначили домен на сервис базы данных — его наследуют базы, схемы и таблицы. Назначили на схему — наследуют таблицы внутри. Дашборды, топики, конвейеры, ML-модели и контейнеры наследуют домен от своего сервиса, термины глоссария — от глоссария и предметной области, пользователи — от команды. Это делает разметку быстрой и масштабируемой: один клик на «контейнере» избавляет от ручной разметки тысяч страниц описания объектов.

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

1.5. Чем домен и дата-продукт не являются

Несколько границ, которые помогают избежать терминологической путаницы:

• Домен не классификация и не тег. Классификации (Tier1…Tier5, категории персональных данных) остаются и работают ортогонально: они отвечают на вопрос «насколько критичен объект», домен — на вопрос «к какой бизнес-области объект относится».
• Домен не глоссарий. Глоссарий хранит бизнес-термины и их определения, домен оперирует зоной ответственности. Это разные сущности; между собой они связываются отдельным механизмом типов связей.
• Домен не копия оргструктуры. Оргструктура меняется чаще, чем бизнес-функции. Декомпозицию стоит вести от функциональной карты компании: например, домен «Менеджмент кадров» может пережить три реорганизации HR-департамента.
• Дата-продукт не таблица и не отчёт. Это сущность поверх них: в продукт обычно объединяется несколько ассетов, и наоборот, одна таблица может входить в разные продукты разных доменов.
• Дата-продукт не пайплайн. Пайплайн — типовой ассет внутри продукта. Продукт — это обещание потребителю; пайплайн — то, как это обещание исполняется.

2. Концепция: какую задачу решают новые сущности

2.1. Что меняется в каталоге

До появления доменов и дата-продуктов каталог был плоским. Таблицы, дашборды, топики, конвейеры находились на одном уровне и были связаны через lineage и теги. На сотне объектов это работает. На тысячах превращается в шум: пользователь не понимает, что важно, кому жаловаться, какая таблица актуальна, а какая — призрак прошлого квартала.

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

Методологически это два ключевых принципа современного управления данными — доменное владение данными и отношение к данным как к продукту, — реализованные на уровне каталога. При этом перестраивать архитектуру под децентрализованную модель не обязательно: доменная разметка и продуктовая упаковка наводят порядок как в централизованной архитектуре с корпоративным DWH, так и в Lakehouse. Новые сущности делают управление данными и стюардство операционными: зоны ответственности перестают быть таблицей в Confluence и презентацией раз в полгода. Это актуальное состояние, которое видит любой пользователь каталога.

2.2. Где это даёт эффект

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

2.3. Какие задачи становятся проще

Из рутины DG-офиса уходит большая часть переписок «на пальцах»:

• Поиск владельца объекта. Если раньше велась длинная переписка по чатам, то теперь достаточно открыть карточку домена с полем «Владелец».
• Понимание зоны ответственности. У владельца появляется видимое «своё»: все объекты и продукты домена, политики над ними.
• Разграничение доступа. Политики доступа могут опираться на принадлежность к домену, при этом пользователь работает только со своей зоной.
• Декомпозиция работы DG-офиса. Каждый домен является отдельным планом работ по качеству, документированию и согласованиям.
• Onboarding потребителя данных. Хождения по таблицам заменил список дата-продуктов с описанием гарантий: что внутри, как часто обновляется, кому жаловаться.
• Сверка приоритетов с бизнесом. Домены соотносятся с бизнес-направлениями, метрики продуктов — с бизнес-KPI.

3. Интеграция с глоссарием, метаданными и качеством

Новые сущности не отменяют того, что уже есть в каталоге. Они встраиваются поверх и связывают существующие механизмы в единую систему. Четыре точки интеграции позволяют выполнить эту задачу эффективно, сохранив присущую каталогу ADC гибкость и удобство.

3.1. Связь с глоссарием

Глоссарий каталога ведёт описания бизнес-терминов с определениями, кастомизируемым атрибутным составом, синонимами и ответственными. Корпоративный глоссарий обычно насчитывает сотни и тысячи терминов. В нашем примере их около сорока из финансов и HR (НДС, Бухгалтерская проводка, Точечный рекрутинг, Текучесть кадров и др.).

Связь домена или дата-продукта с термином устанавливается через отдельный механизм типов связей, а не через теги. Для пары «домен ↔ объект глоссария» (и аналогично для связи «дата-продукт ↔ объект глоссария») создаётся свой тип связи с настройкой направленности. Результат отображается на вкладке «Связанные объекты» в табличном виде: тип связи, наименование объекта, тип объекта. То же видно и со стороны термина: на его карточке появляется блок связанных доменов и продуктов. Кроме того, сами термины и предметные области могут принадлежать домену, поскольку они наследуют его от глоссария.

Что важно на практике: на уровне дата-продукта стоит связывать 4–7 ключевых терминов — тех, без которых нельзя понять, что внутри. Десяток связей превращает карточку в свалку; четыре-пять читаются как оглавление.

3.2. Связь с метаданными и lineage

К главной технической особенности домена относится наследование вниз по иерархии (подробно — в разделе 1.4). Иконка «Наследован» в карточке отличает наследуемую принадлежность от назначенной вручную; прямых назначений у объекта может быть до пяти доменов.

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

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

Lineage между объектами сохраняется без изменений: связи между таблицами остаются на уровне таблиц, а продукт становится логическим слоем поверх, по которому удобно смотреть агрегированную картину зависимостей.

Функционал внутренних справочников внутри Arenadata Catalog (RDM) не является элементом доменной модели. Таким образом, справочники не потребуют дополнительных корректировок при обновлении на новую версию ADC.

3.3. Связь с качеством данных

Тесты качества пишутся на конкретную таблицу или колонку. С появлением доменов и продуктов никаких новых интерфейсов для качества не появилось, и это правильно. Меняется то, как качество видно потребителю.

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

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

Командам, у которых тесты уже настроены, делать дополнительно ничего не нужно: инженеры по качеству данных работают как и раньше.

3.4. Глобальная фильтрация по домену

Помимо ассоциаций «домен ↔ объект», домен можно использовать как режим работы. В шапке приложения есть выбор домена: после выбора необходимого домена раздел «Обзор» показывает только объекты этого домена и его поддоменов. Значение «Все домены» возвращает полный каталог, включая объекты без назначенного домена.

Отдельные домены можно скрыть из списка для части пользователей, это настраивается политиками доступа. Команды получают возможность «жить» в своём домене, не отвлекаясь на чужие объекты; DG-офис переключается между доменами, как между папками.

4. Как внедрить с нуля

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

4.1. Шаг 1. Подготовительные договорённости

Самый продолжительный по времени этап не относится к функционалу ADC. Он про договорённости в организации:

• Согласовать декомпозицию предприятия на домены. Это совместная работа DG-офиса, архитектуры и руководителей бизнес-функций. Ведите её от функциональной карты организации или цепочек создания ценности; оргструктура — запасной вариант, она меняется чаще, чем бизнес-функции.
• Утвердить владельцев. Для каждого корневого домена — одна команда-владелец и один человек, отвечающий за бизнес-смысл домена («бизнес-стюард»).
• Определить базовые классификации. Tier1…Tier5 для критичности, категории персональных данных, контуры доступа. Эти теги работают параллельно с доменами и применяются к любым объектам каталога.
• Договориться о составе расширенных атрибутов. Минимум для домена: уровень зрелости, бизнес-стюард, бизнес-цели, ключевые метрики, регуляторика. Для дата-продукта: SLA, частота обновления, этап жизненного цикла, потребители, источники, уровень доступа.

Хорошая декомпозиция узнаётся по трём признакам: у каждого домена есть единый владелец в виде команды; содержимое домена остаётся обозримым, обычно это 3–10 ключевых объектов или 1–5 продуктов; название домена отражает бизнес-функцию, а не систему («Менеджмент кадров», а не «1С: ЗУП»).

4.2. Шаг 2. Завести структуру в каталоге данных

Все операции выполняются через раздел «Домены» в боковой панели. Кнопка создания открывает выбор типа сущности. Создаём в следующем порядке:

1. Корневые домены создаются последовательно, с заполнением имени, обязательного описания и указанием владельца.
2. Поддомены создаются из карточки родительского домена, с вкладки «Поддомены», с автоматическим заполнением родительского домена. При таком процессе создания родитель проставляется автоматически. Дата-продукты — из карточки соответствующего домена, с вкладки «Дата-продукты» с автоматическим заполнением связи с доменом, или же из левого меню в разделе «Домены» с ручным выбором нужного домена. Имя сущности ограничено 128 символами. Отображаемое наименование используется в карточке и навигации; его рекомендуется заполнять на естественном, понятном всем пользователям языке, избегая сложных или путанных сокращений. Имена и описания индексируются, по ним работает поиск из раздела «Обзор».

4.3. Шаг 3. Подвязать объекты

Объекты добавляются в два слоя — в домен и в продукт. Это разные действия:

• Подвязка к домену делается из карточки конкретного объекта (виджет «Домен»). Часто разметка «верхних контейнеров» — сервисов и схем — сразу даёт принадлежность сотням таблиц через наследование. Это самый быстрый способ покрыть каталог доменной структурой.
• Подвязка к дата-продукту делается из карточки конкретного объекта (виджет «Дата-продукт»). Один объект может входить в несколько продуктов.

Не пытайтесь подвязать к продукту сто таблиц, «чтобы было». Больше не означает лучше. Карточка работает, когда в ней 4–6 ключевых ассетов из тех, к которым обращаются потребители. Тогда вкладка «Объекты» читается как состав продукта, а не как папка файлов.

4.4. Шаг 4. Расширить атрибутный состав

Расширенные атрибуты превращают карточку домена и продукта из «карточки сущности» в полноценный профиль зоны ответственности. Процесс состоит из двух частей:

1. Администратор регистрирует атрибуты для типов «Домен» и «Дата-продукт» в разделе «Конфигурация карточек», на вкладке «Объекты метаданных», через общий реестр атрибутов. Это разовая настройка: после её выполнения поля автоматически появляются во всех карточках соответствующего типа.
2. Пользователи заполняют атрибуты в карточках конкретных сущностей на вкладке «Основная информация». Значения попадают в версионируемую историю объекта.

Рекомендованный минимальный объём атрибутов приведён в разделе 6.8. Главное правило: один и тот же набор атрибутов на всех карточках типа. Единообразие превращает каталог в инструмент, а не в коллекцию разнородных карточек.

4.5. Шаг 5. Назначить владельцев и теги

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

Связи с глоссарием устанавливаются на вкладке «Связанные объекты» через типы связей, а не через теги. На той же вкладке отображаются связи и с другими сущностями каталога.

4.6. Шаг 6. Подключить операционные функции

Когда карточки заполнены, стоит сразу активировать функции, которые часто остаются без внимания:

• Подписка на сущность. Пользователь подписывается на домен или продукт и получает уведомления об изменениях.
• История версий. Любое изменение наименования, описания, владельца, тегов и расширенных атрибутов фиксируется как новая версия с автором и временем.
• Глобальная фильтрация по домену. Команды переключают вид каталога на свой домен из шапки приложения.
• Политики доступа с учётом доменов. Через политики («Доступ к методам API», «Доступ к объектам и их полям», «Доступ к атрибутам объекта») можно скрыть домены из списка фильтрации, ограничить доступ к дата-продуктам и операции с атрибутами «Домен» и «Дата-продукт» в карточках объектов.

5. Как внедрить тем, у кого каталог уже работает

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

5.1. Шаг 1. Снять «фотографию» текущего состояния

До любых изменений нужна инвентаризация. Зафиксируйте:

• Используемые теги и классификации, включая актуальные и устаревшие.
• Структуру глоссария с группировкой терминов.
• Владельцев по объектам и фактическую нагрузку по ним.
• Тесты качества и их актуальный статус.
• Действующие политики доступа и распределение прав.

Цель шага — увидеть, какая фактическая декомпозиция уже сложилась через теги и владельцев. На практике она часто близка к доменной модели, и её остаётся только формализовать.

5.2. Шаг 2. Картировать «как есть → как будет»

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

Здесь же определитесь с приоритетами: с какого домена начать, какие следуют дальше. Не пытайтесь делать всё сразу.

5.3. Шаг 3. Завести домены поверх существующих структур

Создавайте домены и поддомены так же, как описано в разделе 4. Существующие теги и глоссарий не трогайте, поскольку они продолжают работать ортогонально. Не нужно «переводить» теги в домены: это разные сущности с разной семантикой.

Лайфхак, экономящий дни работы: сначала размечайте «верхние контейнеры» — сервисы, базы, схемы. Большая часть таблиц получит домен автоматически через наследование. Далее останется точечно доразметить объекты, которым нужна другая принадлежность. При этом прямое назначение имеет приоритет над унаследованным.

5.4. Шаг 4. Перевести ассеты в дата-продукты

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

1. Выберите приоритетный домен. Хороший кандидат — «Менеджмент кадров»: он есть в любой компании, и эффект миграции виден буквально всем сотрудникам.
2. Определите 2–4 дата-продукта внутри домена. Для HR это типично «Сотрудник 360», «Воронка найма», «Контроль ПДн сотрудников», «HR-метрики».
3. Подвяжите к каждому продукту 4–6 ключевых объектов, к которым потребители уже фактически обращаются. Вместе с таблицами в гарантии продукта попадут и их тесты качества.
4. Заполните описание, владельца, теги, расширенные атрибуты.
5. Опубликуйте продукт во внутренних каналах компании. Зафиксируйте: теперь это «продукт», у него есть владелец и заявленные гарантии.
6. Через две недели соберите обратную связь. Сразу становится очевидно, помогло потребителям или нет.

5.5. Шаг 5. Не сломать существующее

Несколько правил, проверенных на миграциях больших каталогов:

• Не отключайте старые теги, пока не убедились, что весь содержательный контент перенесён.
• Не переименовывайте таблицы и не меняйте FQN, поскольку это сломает lineage и привязанные тесты.
• Не назначайте «временных» владельцев без согласования. Лучше оставить поле пустым, чем создать ложную ответственность.
• Документируйте процесс миграции в карточке домена через расширенные атрибуты. Через год это будет неоценимо.
• Помните правила удаления: домен удаляется, только когда он пуст. Поэтому сначала придётся исключить поддомены, продукты и объекты; это защита от случайной потери структуры. Дата-продукт удаляется мягко, с возможностью восстановления — это безопасно (и его тоже нельзя удалить, пока в нём есть объекты).

5.6. Шаг 6. Развивать модель волнами

Расширенные атрибуты вводите волнами, а не пытайтесь придумать всё сразу:

• Первая волна — минимум гарантий: SLA, частота обновления, этап жизненного цикла, потребители. Этого достаточно, чтобы потребитель понимал, чего ждать.
• Вторая волна — коммуникация с потребителем: источники данных, уровень SLA (Gold/Silver/Bronze), уровень доступа, тип данных.
• Третья волна — формализация: ссылка на документ дата-контракта, состояние lineage, регуляторные ссылки. Это уровень зрелости «Управляемый» по моделям зрелости управления данными.

6. Пример: HR-блок компании «Промтех»

Разберём внедрение на сквозном примере условной производственной компании «Промтех»: 12 000 сотрудников, шесть площадок и управляющая компания. Кадровые данные живут в четырёх системах: 1С:ЗУП (кадровый учёт и зарплата), ATS (подбор), LMS (обучение) и СКУД (учёт рабочего времени). Раз в сутки и микробатчами данные стекаются в корпоративное хранилище; витрины собраны в схеме hr_mart, дашборды построены в BI. Компания вымышленная, но сценарии типовые. Достаточно подставить названия своих систем, и пример станет вашим планом внедрения.

До внедрения доменов картина у «Промтеха» была знакомой многим. Квартальный отчёт по текучести HRBP собирал десять дней из пяти выгрузок. HR и финансы спорили о численности персонала, потому что считали её по-разному, как с внешними совместителями, так и без них. Служба безопасности при аудите 152-ФЗ две недели выясняла, в каких таблицах лежат копии согласий. А после ухода аналитика никто не мог сказать, какие из сорока HR-таблиц актуальны, а какие относятся к числу забытых экспериментов.

6.1. Карта HR-блока

Целевая структура, которую заводим в каталоге:

6.2. Домен «Менеджмент кадров»

Зачем нужен домен. Домен закрепляет единую зону ответственности за все кадровые данные компании. Владелец — команда HR Data из трёх человек: руководитель направления HR-аналитики (он же бизнес-стюард), дата-инженер и аналитик. Теперь на вопрос «чья это таблица?» по любому из сорока HR-объектов есть ответ за тридцать секунд, и у всех он одинаковый.

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

На карточке шесть вкладок: «Основная информация» (видна на скриншоте), «Поддомены», «Дата-продукты», «Объекты», «Участники», «Связанные объекты». Каждая из них функционирует как самостоятельный экран, поэтому карточка фактически становится полноценным «порталом» по бизнес-области.

На вкладке «Связанные объекты» связи с глоссарием представлены в табличном виде: тип связи, наименование, тип объекта. Эти связи устанавливаются через механизм типов связей, не через теги.

6.3. Дата-продукт «Сотрудник 360»

Зачем нужен продукт. Продукт даёт всесторонний ответ на вопрос «что мы знаем о сотруднике» из одной точки вместо пяти систем и выгрузок записей из разных таблиц «по знакомству». Состав конкретен: hr_mart.employees (профиль: подразделение, должность, дата приёма), hr_mart.positions (история переводов), hr_mart.grades (грейды и вилки), hr_mart.absences (отпуска и больничные, обновляются каждые 15 минут из СКУД), hr_mart.learning (курсы и сертификаты из LMS) и дашборд «Карточка сотрудника».

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

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

Любой потребитель, открыв такую карточку, получает ответы на главные вопросы: что внутри, когда обновляется, кому жаловаться, какие гарантии заявлены, кто ещё пользуется. Шаблон одинаково подходит крупному банку, производственной компании и IT-стартапу, поменяются только источники и слои.

6.4. Поддомен «HR-аналитика»

Зачем нужен поддомен. Аналитические витрины и прогнозы живут по другим правилам, чем учётные данные: другая команда-владелец (аналитики, а не кадровое делопроизводство), другие SLA, другие потребители. Выделение их в поддомен разделяет ответственность, не ломая общую рамку «Менеджмента кадров».

6.5. Дата-продукт «Воронка найма»

Зачем нужен продукт. Сквозная воронка «вакансия → отклик → скрининг → интервью → офер → выход». До продукта рекрутеры считали конверсии вручную в таблицах раз в месяц, и этим цифрам мало кто верил. Состав: hr_mart.vacancies, hr_mart.applications, hr_mart.interviews, hr_mart.offers (микробатч из ATS каждые 15 минут) и дашборд с воронкой и метриками.

Как используется. Лид рекрутинга на еженедельной планёрке видит, на каком этапе «застревают» кандидаты по каждой вакансии. Нанимающие менеджеры проверяют статус своих позиций сами, не дёргая рекрутеров. Финансы планируют бюджет подбора, опираясь на фактический time-to-hire: у «Промтеха» это 38 дней по рабочим специальностям против 62 по инженерным, и это видно из одного дашборда.

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

Полезный контраст: «Сотрудник 360» описывает состояние, «Воронка найма» — процесс. На этой паре наглядно видна разница между двумя типами дата-продуктов — мастер-витриной и аналитическим процессом — и то, почему в каталоге нужны оба.

6.6. Чувствительный продукт: «Контроль ПДн сотрудников»

Зачем нужен продукт. Реестр того, где лежат персональные данные сотрудников: таблица согласий с датами и сроками действия (hr_mart.consents), журнал доступа к ПДн (hr_mart.pdn_access_log) и перечень систем-обработчиков. Для российских компаний, ведущих кадровый учёт, это требование 152-ФЗ.

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

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

6.7. До и после: пустой домен

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

При этом не пытайтесь нагрузить карточку сразу всем: на практике 80 процентов ценности дают описание, владелец и три-пять расширенных атрибутов. Остальное наращивается поверх, волнами (см. раздел 5.6).

6.8. Атрибуты, использованные в примере

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

Для домена

Для дата-продукта

7. Заключение

Домены и дата-продукты не являются просто «ещё одной сущностью в каталоге». Это переход к зрелой модели управления данными, где у каждого набора данных есть владелец, у каждой публикации есть заявленные гарантии, у каждой ответственности есть видимая зона. Каталог перестаёт быть энциклопедией объектов и становится картой ответственности и обязательств.

Для компании, которая разворачивает каталог с нуля, рецепт простой: 6–10 корневых доменов, в каждом 2–5 дата-продуктов, единый набор расширенных атрибутов, публикация для команды. Далее следуют итерации: развитие модели качества, постепенное подключение политик доступа, подготовка к контрактной модели.

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

7.1. Что уже есть в версии 1.0

Помимо самих сущностей «Домен» и «Дата-продукт», в версии 1.0 сразу доступен набор операционных функций:

• Двухуровневая иерархия «домен — поддомен» и продукты внутри доменов.
• Наследование принадлежности к домену вниз по иерархии, от сервиса и схемы к таблицам; до пяти прямых назначений домена на объект.
• Глобальная фильтрация по домену из шапки приложения, с учётом поддоменов.
• Политики доступа с учётом доменов и дата-продуктов: скрытие доменов, ограничение операций с атрибутами, ограничение доступа к продуктам.
• Версионирование сущностей с историей изменений и подписка на домен и дата-продукт с уведомлениями.
• Расширение атрибутивного состава карточек через общий реестр атрибутов.
• Связи с глоссарием и другими объектами через настраиваемые типы связей.
• Безопасное удаление: домен можно удалить только при отсутствии вложенных объектов, дата-продукт удаляется мягко с возможностью восстановления.

7.2. Что будет дальше: дата-контракты

Следующим шагом развития модели являются дата-контракты: формальные обязательства продукта перед потребителями. В планах развития Arenadata Catalog предусмотрено выделение контракта в самостоятельную сущность каталога с версионированием схемы данных, политикой обратной совместимости и проверкой соответствия фактических данных контракту; агрегированные SLA-метрики на уровне продукта и домена; оповещения потребителей о нарушениях. Состав и сроки появления этих возможностей могут уточняться, следите за примечаниями к релизам на нашем сайте.

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

Авторы статьи:
Артем Нестерчук, product owner Arenadata Catalog
Дарья Миленькая, аналитик, DataCatalog
Игорь Моисеев, директор по развитию бизнеса, DataCatalog