Сдвиг в предметной области: переход от анализа продуктов к инвестициям в инфраструктуру в сфере управления данными.

Как смещение акцента в операционной деятельности от разрозненных продуктов обработки данных к системной доменной архитектуре устраняет технические узкие места и оптимизирует инвестиции в платформу.

Делиться

В предыдущей статье о мандате на использование данных к 2026 году я объяснил, как Закон ЕС об искусственном интеллекте, Закон о киберустойчивости и Закон о данных подталкивают организации к структурным мандатам, направленным на переход от реактивного соблюдения требований к системному управлению на этапе проектирования. Однако воплощение этого архитектурного замысла в повседневную бизнес-деятельность создает практическое узкое место: как организация может измерить эффективность механизмов управления, если они уже заложены в проект?

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

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

Большинство предприятий уже используют формальные программы управления. Однако наличие структуры не гарантирует операционной эффективности. Исследование Gartner предупреждает, что до 80% инициатив по управлению данными и аналитикой, по прогнозам, потерпят неудачу , часто из-за того, что они рассматривают управление реактивно, а не связывают его с масштабируемыми бизнес-результатами.

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

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

Эта деятельность на микроуровне удовлетворяет требованиям контрольного списка. Она не масштабируется для реализации программы управления. Совокупные затраты значительны: примерно 45% специалистов по работе с данными сообщают о выгорании, при этом энергия расходуется на отдельные проблемы, а не на структурные улучшения. При 60 продуктах это управляемо. При 200 это становится работой на полный рабочий день. При 500 это полностью перестает работать. Это сортировка без стратегии.

Изоляция на уровне продукта против шаблонов на уровне предметной области.

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

Рассмотрим одну и ту же проблему, но с двух разных точек зрения:

Анализ продукта: Пять продуктов обработки данных из трех бизнес-областей демонстрируют отсутствие настроек RBAC (управление доступом на основе ролей). Анализ на уровне продукта выявляет пять независимых, изолированных сбоев, связанных с пятью различными ответственными лицами.

Анализ предметной области: агрегирование этих данных показывает, что развертывание RBAC повсеместно дает сбои в нескольких средах. Это не проблема управления ресурсами, а сбой инфраструктуры.

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

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

При принятии решений о распределении ресурсов правильной единицей анализа является предметная область, а не отдельный продукт.

Выявление закономерностей с помощью тепловой карты зрелости предметной области

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

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

При визуализации производственной инфраструктуры с помощью этой сетки обычно выявляются две структурные реальности.

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

Столбчатая кластеризация: В развивающихся областях сбои редко происходят случайным образом. Несоответствия группируются в рамках определенных направлений в совершенно разных областях. В приведенном выше примере, поля «Происхождение» и «RBAC» одновременно выделены красным цветом для отдела кадров и отдела закупок. Это не проблемы отдела кадров или отдела закупок. Это общеорганизационные пробелы в инфраструктуре, проявляющиеся одновременно в двух местах.

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

Переосмысление вопроса распределения ресурсов в сфере управления

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

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

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

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

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

Вопрос, который стоит задавать перед каждым заседанием Совета управляющих.

Прежде чем анализировать статус какого-либо отдельного продукта или списка задач проекта, стоит задать себе один вопрос:

«Какие основы управления терпят неудачу в различных областях?»

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

Что не показывает тепловая карта

Представление данных в предметной области выявляет сбои в системе, но не объясняет их причины. Низкий уровень соответствия требованиям в отношении происхождения данных в предметной области может быть вызван несколькими различными причинами:

• Автоматизированные инструменты приема данных отключены от конвейеров обработки данных в рамках домена.
• Базовая архитектура данных нестандартна, что препятствует автоматическому сбору метаданных.
• В рамках данного бизнес-подразделения роли владельцев данных официально не определены.

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

Это заменяет собой субъективную повестку дня. Заседания совета, где никто не может прийти к согласию относительно того, какой области следует уделить приоритетное внимание или какие элементы управления наиболее важны в этом квартале. При таком подходе все присутствующие в зале работают, исходя из одной и той же объективной картины корпоративной информационной инфраструктуры еще до обсуждения первого продукта.

Управление как инфраструктура

Управление на уровне продукта необходимо, но недостаточно. Программы, которые быстрее всего развиваются и масштабируются под давлением современного регулирования, — это не те, которые рассматривают наибольшее количество отдельных заявок. Это те, которые делают шаг назад, анализируют закономерности на уровне предметной области, в первую очередь устраняют системные архитектурные пробелы и наблюдают, как показатели на уровне продукта улучшаются как естественное следствие.

Прежде чем уйти…

Подписывайтесь, чтобы не пропустить мои будущие публикации; больше моих статей вы найдете на моей странице профиля. Вы также можете связаться со мной в LinkedIn или X!

Алле Шравани Посмотреть все в Алле Шравани

Источник: towardsdatascience.com