Пример внедрения доменов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короткая шпаргалка — для печати или копирования в трекер задач.

1.Согласовать декомпозицию на домены с бизнесом (от функциональной карты, не от систем).

2.Утвердить владельцев и бизнес-стюардов корневых доменов.

3.Определить классификации (Tier, ПДн) и единый набор расширенных атрибутов.

4.Создать корневые домены и поддомены; заполнить описания и владельцев.

5.Разметить доменами «верхние контейнеры» (сервисы, схемы) — таблицы получат домен по наследованию.

6.Создать 2−4 дата-продукта в пилотном домене; подвязать по 4−6 ключевых ассетов.

7.Зарегистрировать расширенные атрибуты в реестре; заполнить карточки.

8.Связать продукты с 4−7 терминами глоссария через типы связей.

9.Включить подписки, проверить историю версий, настроить политики доступа.

10.Опубликовать продукты для потребителей; через две недели собрать обратную связь и запланировать следующий домен.