Владелец Данных VS Владелец процесса
Разграничения владельца данных и владельца бизнес-процесса является фундаментальным для построения эффективной и безопасной архитектуры управления в любом более менее крупном бизнесе .
Это разграничение проистекает не из абстрактных теоретических Регламентов и прочих ВНД, а из объективной необходимости разделения ответственности в условиях сложной корпоративной структуры.
Сущность владельца бизнес-процесса заключается в управлении деятельностью. Этот субъект сфокусирован на эффективности, производительности, оптимизации операций и достижении конкретных бизнес-результатов. Его ключевые метрики — это время цикла, стоимость операции, уровень сервиса. Его взгляд на данные является утилитарным: данные представляют собой сырье или продукт его процесса, инструмент для достижения операционных целей.
Владелец данных, в свою очередь, несет ответственность за сами информационные активы. Его сфера компетенции — это качество, целостность, безопасность, доступность и соответствие данных установленным стандартам и регуляторным требованиям. Его ключевые метрики — это точность, полнота, непротиворечивость и актуальность данных. Он более стратег: данные являются корпоративным активом, обладающим самостоятельной ценностью.
В малом бизнесе эти роли могут быть совмещены в силу простоты процессов и ограниченного объема данных. Однако в большой компании такое совмещение неминуемо ведет к конфликтам интересов и операционным рискам. Владелец процесса, стремясь к max операционной эффективности, может сознательно или бессознательно пойти на компромисс в вопросах качества или безопасности данных. Например, для ускорения обработки заказов может быть упрощена процедура валидации клиентской информации, что приведет к наполнению систем ошибочными данными. Или же в погоне за снижением издержек могут быть сняты необходимые ограничения доступа, подвергая конфиденциальную информацию неоправданному риску.
Обратная ситуация, когда владелец данных, стремясь к идеальному состоянию информации, может устанавливать чрезмерно строгие правила сбора и обработки, которые тормозят бизнес-процессы, делая их негибкими и неконкурентноспособными.
Финализирую: разделение этих ролей создает систему сдержек и противовесов. Владелец процесса определяет, какие данные необходимы для эффективной работы и какие требования к ним предъявляются с операционной точки зрения. Владелец данных обеспечивает удовлетворение этих требований, но в рамках корпоративных стандартов, правил информационной безопасности и законов. Их взаимодействие, часто через механизмы рабочих групп и комитетов, позволяет находить баланс между операционкой и необходимостью управления рисками, связанными с данными. Это не дублирование функций. Это установление четких зон ответственности, что является краеугольным камнем зрелой системы корпоративного управления.
Заметки Data Steward | Евгений Толпышев | Подписаться
Разграничения владельца данных и владельца бизнес-процесса является фундаментальным для построения эффективной и безопасной архитектуры управления в любом более менее крупном бизнесе .
Это разграничение проистекает не из абстрактных теоретических Регламентов и прочих ВНД, а из объективной необходимости разделения ответственности в условиях сложной корпоративной структуры.
Сущность владельца бизнес-процесса заключается в управлении деятельностью. Этот субъект сфокусирован на эффективности, производительности, оптимизации операций и достижении конкретных бизнес-результатов. Его ключевые метрики — это время цикла, стоимость операции, уровень сервиса. Его взгляд на данные является утилитарным: данные представляют собой сырье или продукт его процесса, инструмент для достижения операционных целей.
Владелец данных, в свою очередь, несет ответственность за сами информационные активы. Его сфера компетенции — это качество, целостность, безопасность, доступность и соответствие данных установленным стандартам и регуляторным требованиям. Его ключевые метрики — это точность, полнота, непротиворечивость и актуальность данных. Он более стратег: данные являются корпоративным активом, обладающим самостоятельной ценностью.
В малом бизнесе эти роли могут быть совмещены в силу простоты процессов и ограниченного объема данных. Однако в большой компании такое совмещение неминуемо ведет к конфликтам интересов и операционным рискам. Владелец процесса, стремясь к max операционной эффективности, может сознательно или бессознательно пойти на компромисс в вопросах качества или безопасности данных. Например, для ускорения обработки заказов может быть упрощена процедура валидации клиентской информации, что приведет к наполнению систем ошибочными данными. Или же в погоне за снижением издержек могут быть сняты необходимые ограничения доступа, подвергая конфиденциальную информацию неоправданному риску.
Обратная ситуация, когда владелец данных, стремясь к идеальному состоянию информации, может устанавливать чрезмерно строгие правила сбора и обработки, которые тормозят бизнес-процессы, делая их негибкими и неконкурентноспособными.
Финализирую: разделение этих ролей создает систему сдержек и противовесов. Владелец процесса определяет, какие данные необходимы для эффективной работы и какие требования к ним предъявляются с операционной точки зрения. Владелец данных обеспечивает удовлетворение этих требований, но в рамках корпоративных стандартов, правил информационной безопасности и законов. Их взаимодействие, часто через механизмы рабочих групп и комитетов, позволяет находить баланс между операционкой и необходимостью управления рисками, связанными с данными. Это не дублирование функций. Это установление четких зон ответственности, что является краеугольным камнем зрелой системы корпоративного управления.
Заметки Data Steward | Евгений Толпышев | Подписаться
👍6❤1👏1
…Я его слепила из того что было.. 🎶. (с)
Или рассуждение на тему - что делать если задача построить Управление данными есть, а ресурсов - нет.
Ответ - и не такое можно слепить, имея навыки писать процедуры и excel.
Вот гипотетический сценарий, когда в качестве инструментов доступны: Excel, Confluence и самописные скрипты в рамках существующего хранилища.
Все можно реализовать, комбинируя функциональность каждого компонента.
Excel может служить первичным интерфейсом для сбора метаданных, описания бизнес-правил и даже для фиксации результатов проверок качества данных. Confluence (и схожий с ним класс систем) выступает в роли централизованного каталога, где документализируются стандарты, политики управления данными и результаты аудитов. Самописные процедуры в хранилище берут на себя вычислительную нагрузку, реализуя проверки качества данных на основе правил в Excel.
Итого, вместо развертывания специализированной платформы, фреймворк строится на соглашениях и рутинных операциях.
Пример: процент заполненности поля или соответствие шаблону, вычисляются скриптами и могут быть выгружены обратно в Excel для визуализации. Confluence обеспечивает необходимый контекст, объясняя, почему то или иное правило является важным с бизнес-точки зрения.
В чем риски такого подхода?
Первый риск - операционная хрупкость. Процесс, зависящий от ручных манипуляций с Excel-файлами и запуска скриптов, крайне уязвим к человеческим ошибкам. Версионность конфигураций правил отслеживается плохо, что может привести к несогласованности проверок.
Второй риск - проблема масштабируемости. Такой фреймворк может работать с десятками таблиц, но станет неэффективным при увеличении объема данных и количества объектов до сотен или тысяч. Отсутствие автоматизированного мониторинга и централизованного представления о состоянии данных в компании превратит поддержку системы в постоянную рутинную работу.
Третий, и наиболее серьезный риск - отсутствие системного управления метаданными. Confluence как вики-система не предназначена для строгого структурирования метаданных. Это приводит к тому, что поиск и установление связей между элементами данных становятся трудоемкими. Фреймворк рискует превратиться в разрозненный архив документов, а не в систему управления.
Четвертый риск касается безопасности и контроля доступа. Управление разрешениями на уровне Excel-файлов и страниц Confluence не обеспечивает того же уровня гранулярности и аудита, что и специализированные решения для управления данными. Есть опасность несанкционированного изменения критичных бизнес-правил.
Таким образом, создать некий фреймворк с нулевыми прямыми затратами возможно, но его эксплуатационные расходы и скрытые издержки будут высоки. Такой подход можно рассматривать как прототип или временное решение, которое демонстрирует ценность управления данными.
Но для построения устойчивой, масштабируемой и надежной практики требуется инвестирование в соответствующие инструменты.
Решение из подручных средств является тактическим, но не стратегическим.
#инструменты_управления_данными
#сделай_сам
👍8
Показалась весьма занятным исследование на тему : а где сейчас деньги в IT?
Forwarded from Alice
b1-software-and-it-services-in-russia-research-2025.pdf
2.9 MB
Анализ рынка ПО и ИТ-услуг в мире и в России. Занимательные выводы про то, что будет расти и на сколько
#исследования
#исследования
👍3
Решил сделать подборку презентации топовых компаний на предмет Data Governance.
Выжимка презентаций из нашего основного чата:
https://t.me/DataAdventurers
Подписывайтесь !;)
⤵️⤵️⤵️
Выжимка презентаций из нашего основного чата:
Подписывайтесь !;)
⤵️⤵️⤵️
👍3🔥1
🔥3🤝1
Пришлось столкнуться с тем, что в наследство достался реестр бизнес-доменов, в котором были назначены владельцы данных. Реестр был трехлетней давности - это тот самый момент, когда устаревание данных произошло не в самой базе данных, а прямо в инструменте управления.
Штош… Пора актуализировать.
Какие шаги можно предпринять?
Прежде всего признать, что ответственность владельца данных не может быть определён исключительно на основе перечня доменов или таблиц. Это совокупность бизнес- процессов, охватывающих происхождение, качество, использование и соответствие данных регуляторным требованиям. Поэтому первым шагом должна стать инвентаризация всех сквозных бизнес - процессов и объектов данных, находящихся в зоне домена: это и таблицы в хранилище данных (DWH), и сущности в АБС.
Иногда приходится провести согласование границ домена с владельцами смежных областей. Ведь часто одна и та же сущность —«клиент» или «договор» — фигурирует в нескольких доменах. И тут важно не просто зафиксировать, кто «владеет» таблицей, а определить, кто несёт ответственность за её семантическую корректность.
Особое внимание не забудьте уделить метаданным. Владелец данных должен быть в состоянии объяснить, откуда берутся значения в его таблицах, как часто обновляются и с какой точностью отражают реальность. Часто это требуется чтобы привязаться к бизнес-контексту: например, если в DWH хранится агрегированный показатель «просрочка по портфелю», владелец должен понимать, какие источники участвуют в его расчёте, какие бизнес-правила заложены в логику расчета показателя.
Также необходимо погрузить владельца в тему качества данных. Это можно сделать через SLA на поставку данных, например СМЭФ.
Важно, чтобы такие обязательства были измеримы и подотчётны — иначе роль владельца данных рискует превратиться в декларативную функцию без реального влияния.
Change- активности: стоит внедрить регулярный пересмотр периметра ответственности. Бизнес меняется, системы трансформируются, домены сливаются или дробятся — и реестр владельцев данных должен быть таким же живым. Для этого целесообразно привязать актуализацию к циклам управления изменениями в ИТ-ландшафте или к ежегодному планированию архитектуры.
Таким образом, обозначение периметра ответственности — это не единовременная задача, а непрерывный процесс согласования, документирования и верификации, в котором техническая точность должна быть уравновешена бизнес-смыслом. Только при таком подходе владелец данных становится не номинальной фигурой, а реальным гарантом доверия к информации в организации.
#владелец_данных
Заметки Data Steward | Евгений Толпышев | Подписаться
Штош… Пора актуализировать.
Какие шаги можно предпринять?
Прежде всего признать, что ответственность владельца данных не может быть определён исключительно на основе перечня доменов или таблиц. Это совокупность бизнес- процессов, охватывающих происхождение, качество, использование и соответствие данных регуляторным требованиям. Поэтому первым шагом должна стать инвентаризация всех сквозных бизнес - процессов и объектов данных, находящихся в зоне домена: это и таблицы в хранилище данных (DWH), и сущности в АБС.
Иногда приходится провести согласование границ домена с владельцами смежных областей. Ведь часто одна и та же сущность —«клиент» или «договор» — фигурирует в нескольких доменах. И тут важно не просто зафиксировать, кто «владеет» таблицей, а определить, кто несёт ответственность за её семантическую корректность.
Особое внимание не забудьте уделить метаданным. Владелец данных должен быть в состоянии объяснить, откуда берутся значения в его таблицах, как часто обновляются и с какой точностью отражают реальность. Часто это требуется чтобы привязаться к бизнес-контексту: например, если в DWH хранится агрегированный показатель «просрочка по портфелю», владелец должен понимать, какие источники участвуют в его расчёте, какие бизнес-правила заложены в логику расчета показателя.
Также необходимо погрузить владельца в тему качества данных. Это можно сделать через SLA на поставку данных, например СМЭФ.
Важно, чтобы такие обязательства были измеримы и подотчётны — иначе роль владельца данных рискует превратиться в декларативную функцию без реального влияния.
Change- активности: стоит внедрить регулярный пересмотр периметра ответственности. Бизнес меняется, системы трансформируются, домены сливаются или дробятся — и реестр владельцев данных должен быть таким же живым. Для этого целесообразно привязать актуализацию к циклам управления изменениями в ИТ-ландшафте или к ежегодному планированию архитектуры.
Таким образом, обозначение периметра ответственности — это не единовременная задача, а непрерывный процесс согласования, документирования и верификации, в котором техническая точность должна быть уравновешена бизнес-смыслом. Только при таком подходе владелец данных становится не номинальной фигурой, а реальным гарантом доверия к информации в организации.
#владелец_данных
Заметки Data Steward | Евгений Толпышев | Подписаться
👍4💯3
Когда надо сообщить Владельцу процесса , что он теперь и Владелец данных.
p.s. @Alisojd спасибо за выбор мема)
p.s. @Alisojd спасибо за выбор мема)
😁6👍1
Как организация понимает что ей нужно внедрять Каталог данных?
Необходимость напрямую связана с двумя системными рисками: цикличностью цифровой трансформации и стратегической зависимостью от аутстаффинга в ИТ.
Эти два фактора образуют порочный круг, разорвать который без формализации ИТ активов практически невозможно.
Цифровая трансформация редко является разовым событием. Увы. Чаще она представляет собой череду стримов, каждый из которых пытается устранить технический долг и неэффективность, созданные предыдущим циклом. Основная причина цикличности — отсутствие устойчивой и самодостаточной архитектуры данных. Когда компания предпринимает очередную трансформацию, будь то миграция на новую АБС или внедрение новой платформы данных, инженеры сталкиваются с проблемой: отсутствием понятной и единой карты данных. Процесс переноса или модернизации сводится к длительному и дорогостоящему реверс-инжинирингу легаси систем, бизнес-логика которых нигде не зафиксирована. И каталог данных выступает здесь в роли путеводной звезды. Он сохраняет семантику, lineage и бизнес-контекст данных независимо от смены технологического стека. Новая трансформация в этом случае начинается не с нуля, а с полного понимания существующего ИТ- ландшафта, что радикально снижает сроки, стоимость и риски перехода. А стоимость трансформации немаленькая.
Зависимость от ИТ-аутстаффинга усугубляет эту проблему до уровня стратегической уязвимости. Когда разработка и поддержка систем отданы на аутсорсинг, ключевые знания о данных — их происхождении, зависимостях, коммерческой тайны— концентрируются у внешних исполнителей.
Смена подрядчика или вывод их команды приводит к потере критического контекста. И получается что компания де-факто потеряет контроль над своими же активами, попадая в ситуацию информационного заложников.
Каталог (или дата фреймворк) в этой парадигме будет являться механизмом защиты суверенитета организации над данными. Он формализует и удерживает знания внутри компании, превращая их из неявного опыта временных сотрудников в явный, институциональный актив. Это позволяет безопасно менять подрядчиков, масштабировать команды и сохранять непрерывность процессов, поскольку новые специалисты получают не разрозненные устные инструкции, а централизованный и авторитетный источник информации о данных.
Централизованное управление данными создает устойчивый каркас данных, который переживет смену технологий и персонала, превращая цифровую трансформацию из циклического процесса в непрерывную и управляемую эволюцию, а аутстаффинг — из стратегического риска в тактический инструмент гибкости.
#управление_данными
#Каталог_данных
Заметки Data Steward | Евгений Толпышев | Подписаться
Необходимость напрямую связана с двумя системными рисками: цикличностью цифровой трансформации и стратегической зависимостью от аутстаффинга в ИТ.
Эти два фактора образуют порочный круг, разорвать который без формализации ИТ активов практически невозможно.
Цифровая трансформация редко является разовым событием. Увы. Чаще она представляет собой череду стримов, каждый из которых пытается устранить технический долг и неэффективность, созданные предыдущим циклом. Основная причина цикличности — отсутствие устойчивой и самодостаточной архитектуры данных. Когда компания предпринимает очередную трансформацию, будь то миграция на новую АБС или внедрение новой платформы данных, инженеры сталкиваются с проблемой: отсутствием понятной и единой карты данных. Процесс переноса или модернизации сводится к длительному и дорогостоящему реверс-инжинирингу легаси систем, бизнес-логика которых нигде не зафиксирована. И каталог данных выступает здесь в роли путеводной звезды. Он сохраняет семантику, lineage и бизнес-контекст данных независимо от смены технологического стека. Новая трансформация в этом случае начинается не с нуля, а с полного понимания существующего ИТ- ландшафта, что радикально снижает сроки, стоимость и риски перехода. А стоимость трансформации немаленькая.
Зависимость от ИТ-аутстаффинга усугубляет эту проблему до уровня стратегической уязвимости. Когда разработка и поддержка систем отданы на аутсорсинг, ключевые знания о данных — их происхождении, зависимостях, коммерческой тайны— концентрируются у внешних исполнителей.
Смена подрядчика или вывод их команды приводит к потере критического контекста. И получается что компания де-факто потеряет контроль над своими же активами, попадая в ситуацию информационного заложников.
Каталог (или дата фреймворк) в этой парадигме будет являться механизмом защиты суверенитета организации над данными. Он формализует и удерживает знания внутри компании, превращая их из неявного опыта временных сотрудников в явный, институциональный актив. Это позволяет безопасно менять подрядчиков, масштабировать команды и сохранять непрерывность процессов, поскольку новые специалисты получают не разрозненные устные инструкции, а централизованный и авторитетный источник информации о данных.
Централизованное управление данными создает устойчивый каркас данных, который переживет смену технологий и персонала, превращая цифровую трансформацию из циклического процесса в непрерывную и управляемую эволюцию, а аутстаффинг — из стратегического риска в тактический инструмент гибкости.
#управление_данными
#Каталог_данных
Заметки Data Steward | Евгений Толпышев | Подписаться
👍1
«Проверки - проверочки, пошил - и на примерочку»
Понимаю, что, возможно, это и забитая тема, но есть в ней пара важных пунктов, отделяющих создание проверок «для галочки»и необходимых бизнесу.
Поэтому как о проблеме не говори, актуальности о на не потеряет.
По фактам. Покажу на примере переезда БД с одной системы на другую.
Комплексный подход здесь - в глубоком процессе верификации данных, цель которого — обеспечить не только целостность, но и бизнес-консистентность данных после переезда.
Только первый уровень проверок — валидация полноты и объема данных. Где убедиться, что все целевые сущности и атрибуты перенесены без потерь?
Можно проводить такую проверку на уровне агрегированных метрик: общие суммы по ключевым показателям, количеству уникальных клиентов, уникальных транзакций и т.д.. Расхождение на одну запись может явно указывать на ошибку работы ETL/ELT.
Второй критический аспект — проверка целостности и точности. Необходимо проверить согласованность ссылочной целостности, убедившись, что все перенесенные внешние ключи имеют родительские записи. Верификация точности ключевых метрик и атрибутов: сравнение сумм, дат, текстовых описаний и статусов между исходной и целевой системами для репрезентативной выборки данных, а лучше — для полного объема и т.д. Особое внимание следует уделить правильности преобразований данных, например, конвертации валют, агрегации или очистки.
Третий уровень — оценка согласованности и непротиворечивости данных с точки зрения бизнес-логики. Данные могут быть технически целыми и точными, но нарушать бизнес-правила. Например, необходимо проверить, что не появилось заказов с датой выполнения раньше даты создания, или что возраст клиента находится в реалистичных пределах. Следует запустить проверку на наличие дубликатов ключевых бизнес-сущностей, таких как клиенты или договоры, которые могли возникнуть в процессе миграции из разных Информационных систем. Также важно валидировать корректность исторических данных, убедившись, что срезы истории и временные метки были перенесены и интерпретированы правильно.
Наконец, четвертый, упускаемый элемент — это проверка эксплуатационных характеристик данных в новой среде. После подтверждения содержательной корректности необходимо оценить производительность выполнения типовых запросов и отчетов, которые будут использоваться бизнес-пользователями. Медленная работа системы из-за неоптимальной структуры данных или индексов после миграции может быть воспринята как проблема с качеством самих данных, подрывая доверие к проекту.
По итогу, комплексная проверка данных при миграции — многоуровневый процесс, который охватывает статическую корректность информации, её динамическое поведение и соответствие бизнес-контексту.
#Качество_данных
#проверки
Заметки Data Steward | Евгений Толпышев | Подписаться
Понимаю, что, возможно, это и забитая тема, но есть в ней пара важных пунктов, отделяющих создание проверок «для галочки»и необходимых бизнесу.
Поэтому как о проблеме не говори, актуальности о на не потеряет.
По фактам. Покажу на примере переезда БД с одной системы на другую.
Ключевая идея заключается в том, что проверка данных при миграции не должна сводиться к подсчёту строк между старой и новой системой.
Комплексный подход здесь - в глубоком процессе верификации данных, цель которого — обеспечить не только целостность, но и бизнес-консистентность данных после переезда.
Только первый уровень проверок — валидация полноты и объема данных. Где убедиться, что все целевые сущности и атрибуты перенесены без потерь?
Можно проводить такую проверку на уровне агрегированных метрик: общие суммы по ключевым показателям, количеству уникальных клиентов, уникальных транзакций и т.д.. Расхождение на одну запись может явно указывать на ошибку работы ETL/ELT.
Второй критический аспект — проверка целостности и точности. Необходимо проверить согласованность ссылочной целостности, убедившись, что все перенесенные внешние ключи имеют родительские записи. Верификация точности ключевых метрик и атрибутов: сравнение сумм, дат, текстовых описаний и статусов между исходной и целевой системами для репрезентативной выборки данных, а лучше — для полного объема и т.д. Особое внимание следует уделить правильности преобразований данных, например, конвертации валют, агрегации или очистки.
Третий уровень — оценка согласованности и непротиворечивости данных с точки зрения бизнес-логики. Данные могут быть технически целыми и точными, но нарушать бизнес-правила. Например, необходимо проверить, что не появилось заказов с датой выполнения раньше даты создания, или что возраст клиента находится в реалистичных пределах. Следует запустить проверку на наличие дубликатов ключевых бизнес-сущностей, таких как клиенты или договоры, которые могли возникнуть в процессе миграции из разных Информационных систем. Также важно валидировать корректность исторических данных, убедившись, что срезы истории и временные метки были перенесены и интерпретированы правильно.
Наконец, четвертый, упускаемый элемент — это проверка эксплуатационных характеристик данных в новой среде. После подтверждения содержательной корректности необходимо оценить производительность выполнения типовых запросов и отчетов, которые будут использоваться бизнес-пользователями. Медленная работа системы из-за неоптимальной структуры данных или индексов после миграции может быть воспринята как проблема с качеством самих данных, подрывая доверие к проекту.
По итогу, комплексная проверка данных при миграции — многоуровневый процесс, который охватывает статическую корректность информации, её динамическое поведение и соответствие бизнес-контексту.
#Качество_данных
#проверки
Заметки Data Steward | Евгений Толпышев | Подписаться
❤3👍3