Пришлось столкнуться с тем, что в наследство достался реестр бизнес-доменов, в котором были назначены владельцы данных. Реестр был трехлетней давности - это тот самый момент, когда устаревание данных произошло не в самой базе данных, а прямо в инструменте управления.
Штош… Пора актуализировать.
Какие шаги можно предпринять?
Прежде всего признать, что ответственность владельца данных не может быть определён исключительно на основе перечня доменов или таблиц. Это совокупность бизнес- процессов, охватывающих происхождение, качество, использование и соответствие данных регуляторным требованиям. Поэтому первым шагом должна стать инвентаризация всех сквозных бизнес - процессов и объектов данных, находящихся в зоне домена: это и таблицы в хранилище данных (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
Модные заголовки про оптимизацию кожаных мешков натолкнули меня на мысль порассуждать на футуристическую тему : а может ли AI 🤖 заменить специалиста по данным (data steward, data manager) и автоматизировать его функционал?
Пока пузырь AI еще в стадии турбонадува, приведу мои причины «почему нет»:
1️⃣ Работа с данными — это не только про цифры и правила. Чтобы по-настоящему разобраться в информации, нужно понимать неочевидные вещи: как на самом деле люди в компании общаются между собой, какие негласные договоренности существуют и о чем они молчат в официальных отчетах. AI умеет находить шаблоны в том, чему его научили, но он не может понять скрытый смысл разговоров у кулера или почувствовать напряженность на совещании. Он видит данные, но не видит всей картины, которая складывается из человеческих отношений. Тут нужны глаза и уши на уровне Game Of Thrones.
2️⃣ Вопрос ответственности и спорных решений. Менеджер Данных/ Data steward часто выступает третьей стороной, когда разные отделы не могут договориться как должен использовать информацию. Эти споры часто связаны с властью, деньгами и амбициями, а не с техническими деталями. Если решение примет алгоритм, кто будет за него отвечать? Например, если из-за этого решения будут ущемлены права людей или компания понесет убытки. В конечном счете, ответственность ляжет на человека, не на алгоритм. Даже если алгоритм сам написал алгоритм - всегда найдется его заказчик.
Чаще всего людям нужен другой человек, чтобы спорить, жаловаться и доверять.
AI скорее станет отличным помощником: выполнять скучную и однообразную работу, находить ошибки и составлять отчеты, мониторинги.
Понимать, договариваться и нести ответственность — останется за человеком.
В будущем нас скорее ждет не замена, а партнерство, где AI будет инструментом в руках эксперта.
#AI
#stewardship
Пока пузырь AI еще в стадии турбонадува, приведу мои причины «почему нет»:
1️⃣ Работа с данными — это не только про цифры и правила. Чтобы по-настоящему разобраться в информации, нужно понимать неочевидные вещи: как на самом деле люди в компании общаются между собой, какие негласные договоренности существуют и о чем они молчат в официальных отчетах. AI умеет находить шаблоны в том, чему его научили, но он не может понять скрытый смысл разговоров у кулера или почувствовать напряженность на совещании. Он видит данные, но не видит всей картины, которая складывается из человеческих отношений. Тут нужны глаза и уши на уровне Game Of Thrones.
2️⃣ Вопрос ответственности и спорных решений. Менеджер Данных/ Data steward часто выступает третьей стороной, когда разные отделы не могут договориться как должен использовать информацию. Эти споры часто связаны с властью, деньгами и амбициями, а не с техническими деталями. Если решение примет алгоритм, кто будет за него отвечать? Например, если из-за этого решения будут ущемлены права людей или компания понесет убытки. В конечном счете, ответственность ляжет на человека, не на алгоритм. Даже если алгоритм сам написал алгоритм - всегда найдется его заказчик.
AI скорее станет отличным помощником: выполнять скучную и однообразную работу, находить ошибки и составлять отчеты, мониторинги.
Понимать, договариваться и нести ответственность — останется за человеком.
В будущем нас скорее ждет не замена, а партнерство, где AI будет инструментом в руках эксперта.
#AI
#stewardship
👍5❤3
Конец года, стресс, отчеты, закрытие периодов.. хорошее решение справится со всем этим придумали наши банковские коллеги.
Всем опоры , поддержки и тепла!
Всем опоры , поддержки и тепла!
👍2😁1
Forwarded from Банкста
This media is not supported in your browser
VIEW IN TELEGRAM
Метафорические карты для баланса и гармонии в любой ситуации
Итоги года – это всегда отчеты, сверенные счета и много стресса. Как не потерять внутреннюю опору в этот период и остаться в гармонии с собой? Финлид от Точка Банк позаботился об этом и создал чат-бот с метафорическими картами для бухгалтеров.
«Метафорические карты для счастливых бухгалтеров» – не для предсказания будущего, а для понимания своих внутренних ощущений. Каждый расклад, как диалог с собой: он отражает ваши чувства и мысли. Это инструмент самоподдержки, который всегда рядом.
Получите ответы на все ваши вопросы и входите в новый год с ощущением полного баланса и в работе, и в жизни.
Задать вопрос картам
Итоги года – это всегда отчеты, сверенные счета и много стресса. Как не потерять внутреннюю опору в этот период и остаться в гармонии с собой? Финлид от Точка Банк позаботился об этом и создал чат-бот с метафорическими картами для бухгалтеров.
«Метафорические карты для счастливых бухгалтеров» – не для предсказания будущего, а для понимания своих внутренних ощущений. Каждый расклад, как диалог с собой: он отражает ваши чувства и мысли. Это инструмент самоподдержки, который всегда рядом.
Получите ответы на все ваши вопросы и входите в новый год с ощущением полного баланса и в работе, и в жизни.
Задать вопрос картам
Неплохая иллюстрация вовлеченности топ - менеджмента в технологии.
Forwarded from r/ретранслятор
Специалист по кибербезопасности рассказал о том, как на практике происходит внедрение ИИ в компаниях. Если кратко — это выглядит смешно и нелепо.
Мы решили не пересказывать, а перевести текст целиком, чтобы сохранить весь этот абсурд в первозданном виде:
r/#Entrepreneur
Мы решили не пересказывать, а перевести текст целиком, чтобы сохранить весь этот абсурд в первозданном виде:
> В прошлом квартале я внедрил Microsoft Copilot для 4 000 сотрудников.
> Это 30 долларов за пользователя в месяц.
> 1,4 миллиона долларов в год.
> Я назвал это «цифровой трансформацией».
> Совету директоров эта фраза понравилась.
> Они утвердили всё за одиннадцать минут.
> Никто не спросил, что это вообще будет делать.
> Включая меня.
> Я сказал всем, что это «увеличит продуктивность в 10 раз».
> Это не настоящее число.
> Но звучит как настоящее.
> HR спросили, как мы будем измерять эти 10x.
> Я сказал, что мы «будем использовать аналитические дашборды».
> Они перестали задавать вопросы.
> Через три месяца я посмотрел отчёты по использованию.
> 47 человек открывали Copilot.
> 12 использовали его больше одного раза.
> Один из них — я.
> Я использовал его, чтобы он кратко пересказал мне письмо, которое я мог прочитать за 30 секунд.
> Это заняло 45 секунд.
> Плюс время на исправление галлюцинаций.
> Но я назвал это «успешным пилотным запуском».
> Успех — это когда не было заметного провала.
> Финансовый директор спросил о рентабельности инвестиций.
> Я показал ему график.
> График шёл вверх и вправо.
> Этот график измерял «ИИ-вовлечённость».
> Я сам придумал этот показатель.
> Директор одобрительно кивнул.
> Теперь наша компания «с внедрённым ИИ».
> Я не знаю, что это значит.
> Но это есть в презентации для инвесторов.
> Старший разработчик спросил, почему мы не используем Claude или ChatGPT.
> Я сказал, что нам нужна «корпоративная безопасность».
> Он спросил, что это значит.
> Я сказал: «Соответствие требованиям».
> Он спросил — каким именно.
> Я сказал: «всем».
> Он выглядел скептически.
> Я назначил ему «беседу о развитии карьеры».
> Он перестал задавать вопросы.
> Microsoft прислали команду для анализа кейса.
> Они хотели представить нас как историю успеха.
> Я сказал им, что мы «сэкономили 40 000 часов».
> Я рассчитал эти часы, умножив количество сотрудников на число, которое сам придумал.
> Они ничего не проверили.
> Они никогда ничего не проверяют.
> Теперь мы на сайте Microsoft.
> «Глобальная компания добилась повышения производительности на 40 000 часов с помощью Copilot».
> Генеральный директор поделился этим в LinkedIn.
> Ему поставили 3 000 лайков.
> Он ни разу не использовал Copilot.
> Никто из руководства не использовал.
> У нас есть исключение.
> «Стратегическая направленность требует минимального цифрового отвлечения».
> Я написал эту политику.
> Лицензии продлеваются в следующем месяце.
> Я запрашиваю расширение.
> Ещё 5 000 лицензий.
> Мы не использовали первые 4 000.
> Но в этот раз мы «будем стимулировать внедрение».
> Внедрение — это обязательное обучение.
> Обучение — это 45-минутный вебинар, который никто не смотрит.
> Но прохождение будет отслеживаться.
> Прохождение — это метрика.
> Метрики отображаются на панелях мониторинга.
> Эти показатели идут в презентации для совета директоров.
> Презентации для совета директоров помогут мне получить повышение.
> Я стану старшим вице-президентом к третьему кварталу.
> Я всё ещё не знаю, что делает Copilot.
> Но я знаю, зачем он нужен.
> Он нужен, чтобы показать, что мы «инвестируем в ИИ».
> Инвестиции означают расходы.
> Расходы означают приверженность.
> Приверженность означает, что мы серьёзно относимся к будущему.
> Будущее — это то, что я потом им скажу.
> Главное, чтобы график шёл вверх и вправо.
r/#Entrepreneur
😁3
Для чего нужна эмпатия и психология в работе.
Покажу пару кейсах при назначении владельцев данных.
Цифровая трансформация редко имеет дело с чисто техническими вызовами.
Ее основной посыл лежит к области человеческих факторов, в виде готовности людей к изменениям.
1️⃣ кейс. В одном банке было инициировано внедрение некой платформы по управлению данными. Ключевым требованием было назначение владельцев данных из числа руководителей фин департамента, казначейства, бэк-офиса. Формально приказ подписан, но на практике ответственность игнорировалась. Руководители восприняли это как доп. нагрузку, не видя пользы. На их взгляд казалось что данные это удел IT. То самое сопротивление, когда нововведение не согласуется с убеждениям и «традициями».
Успех был достигнут после следующего: вместо приказов- индивидуальные рабочие встречи, где на примерах показано, как качественные данные напрямую влияют на качество обязательной отчетности.
2️⃣ Кейс про глубокую форму сопротивления — эмоциональную, основанную на страхе. Владельцем данных по домену «Клиенты» назначили нового руководителя из соседнего Департамента. Несмотря на внешнее согласие, процесс стал саботироваться. Суть саботажа заключался в невысказанном страхе, что выявятся потенциальные недостатки в процессе реконсиляции данных , может подорваться авторитет и руководителя и коллектива.
Выходом из ситуации стала интеграция экспертного знания коллег в новый процесс. Было назначение одного из коллег в качестве методолога от управления данными.
На основании всего этого можно сформулировать принцип: работа с изменениями это не задача кнута, а потенциального пряника.
Необходимо уйти от эмоций и выявить лежащие в их основе суть вещей — непонимание нововведений, эмоциональный страх или инерция.
#психология
#управление_изменениями
Покажу пару кейсах при назначении владельцев данных.
Цифровая трансформация редко имеет дело с чисто техническими вызовами.
Ее основной посыл лежит к области человеческих факторов, в виде готовности людей к изменениям.
1️⃣ кейс. В одном банке было инициировано внедрение некой платформы по управлению данными. Ключевым требованием было назначение владельцев данных из числа руководителей фин департамента, казначейства, бэк-офиса. Формально приказ подписан, но на практике ответственность игнорировалась. Руководители восприняли это как доп. нагрузку, не видя пользы. На их взгляд казалось что данные это удел IT. То самое сопротивление, когда нововведение не согласуется с убеждениям и «традициями».
Успех был достигнут после следующего: вместо приказов- индивидуальные рабочие встречи, где на примерах показано, как качественные данные напрямую влияют на качество обязательной отчетности.
2️⃣ Кейс про глубокую форму сопротивления — эмоциональную, основанную на страхе. Владельцем данных по домену «Клиенты» назначили нового руководителя из соседнего Департамента. Несмотря на внешнее согласие, процесс стал саботироваться. Суть саботажа заключался в невысказанном страхе, что выявятся потенциальные недостатки в процессе реконсиляции данных , может подорваться авторитет и руководителя и коллектива.
Выходом из ситуации стала интеграция экспертного знания коллег в новый процесс. Было назначение одного из коллег в качестве методолога от управления данными.
На основании всего этого можно сформулировать принцип: работа с изменениями это не задача кнута, а потенциального пряника.
Необходимо уйти от эмоций и выявить лежащие в их основе суть вещей — непонимание нововведений, эмоциональный страх или инерция.
Эффективный менеджер должен быть и системным аналитиком и психологом с развитой эмпатией.
Технологии - это инструменты, внедряют их люди.
#психология
#управление_изменениями
👍2
Дорогие подписчики, Data- Авантюристы! С наступающим Новым годом! 🎉
2025-й был огонь: много классных мероприятий, конференции и практичных идей, благодаря вам! Вы — лучшие.
Но, не останавливаемся! Вместе сделаем data-driven подход мейнстримом. К новым победам над данными в 2026! 🚀
С праздником! И пусть ваш код работает без дебагов!
2025-й был огонь: много классных мероприятий, конференции и практичных идей, благодаря вам! Вы — лучшие.
Но, не останавливаемся! Вместе сделаем data-driven подход мейнстримом. К новым победам над данными в 2026! 🚀
С праздником! И пусть ваш код работает без дебагов!
❤4👍4🔥1
В связи с внедрением в законодательство термина ИТ-активы, хотелось бы разобраться, кто является Владельцем ИТ-актива?
Данный вопрос явно лежит на стыке права, корпоративного управления и технологий и требует четкого разграничения.
Сам термин «ИТ-актив» является агрегирующим и обозначает любой ресурс, имеющий ценность для организации в контексте ИТ. Однако с юридической и операционной точек зрения внутри этого понятия существуют принципиально разные категории, права на которые часто распределены между различными субъектами.
Владельцем данных, в классическом понимании, является субъект, который определяет цель, содержание и правила обработки информации. В корпоративной среде таким субъектом выступает владелец бизнес-процесса или функциональное подразделение, которое создает и использует данные для достижения целей. Например, данные о клиентах принадлежат департаменту продаж или операционному подразделению, а счета — бухгалтерии. Их право собственности носит не технический, а содержательный и управленческий характер. Они несут ответственность за качество, конфиденциальность и целостность данных в соответствии с регламентами 152 ФЗ. При этом физическое хранение и обработка этих данных осуществляются на инфраструктуре, которой они, как правило, не владеют.
Владельцем информационной системы, как технологического актива, является тот, кто несет ответственность за ее жизненный цикл, эксплуатационную готовность, безопасность и развитие. В рамках организации это часто подразделение ИТ-службы или центры ответственности, такие как владелец сервиса или владелец инфраструктуры. Их право собственности — техническое и операционное. Они обеспечивают вычислительные мощности, хранилища, сетевые компоненты, ПО и прикладные системы, которые служат средой для обработки данных. Их ключевая задача — предоставление надежного и эффективного сервиса владельцам данных.
Таким образом, в рамках парадигмы ИТ-активов возникает фундаментальное разделение: владелец данных контролирует контент и логику его использования, а владелец системы контролирует контейнер и механизмы для этого использования. Конфликт интересов и зон ответственности между ними является классическим. Владелец данных требует от системы максимальной гибкости, доступности и функциональности, часто не учитывая технологических ограничений и стоимости владения. Владелец системы, наоборот, стремится к стандартизации, управляемости и безопасности инфраструктуры, что может восприниматься как ограничение для бизнес-подразделений.
С правовой точки зрения, если данные представляют собой объект интеллектуальной собственности или содержат перс данные, владелец данных выступает в роли правообладателя или оператора персональных данных, что налагает на него дополнительные обязательства, выходящие за рамки внутрикорпоративных отношений. Владелец системы в этой схеме становится обработчиком или уполномоченным лицом, действующим на основании договора или корпоративного регламента.
Следовательно, ответ на вопрос о владельцах в контексте ИТ-активов заключается в признании дуализма собственности. Эффективное управление ИТ-активами невозможно без установления прозрачных и формализованных отношений между владельцем данных как субъекта бизнеса и владельцем системы как субъекта технологического обеспечения. Это разделение прав и ответственности формирует основу для архитектуры управления предприятием, где ИТ-активы перестают быть просто затратами, а становятся объектом страт управления, требующего баланса между бизнес-ценностью и технологической целесообразностью.
#ит-активы
#владелец_данных
#владелец_ИС
Данный вопрос явно лежит на стыке права, корпоративного управления и технологий и требует четкого разграничения.
Сам термин «ИТ-актив» является агрегирующим и обозначает любой ресурс, имеющий ценность для организации в контексте ИТ. Однако с юридической и операционной точек зрения внутри этого понятия существуют принципиально разные категории, права на которые часто распределены между различными субъектами.
Владельцем данных, в классическом понимании, является субъект, который определяет цель, содержание и правила обработки информации. В корпоративной среде таким субъектом выступает владелец бизнес-процесса или функциональное подразделение, которое создает и использует данные для достижения целей. Например, данные о клиентах принадлежат департаменту продаж или операционному подразделению, а счета — бухгалтерии. Их право собственности носит не технический, а содержательный и управленческий характер. Они несут ответственность за качество, конфиденциальность и целостность данных в соответствии с регламентами 152 ФЗ. При этом физическое хранение и обработка этих данных осуществляются на инфраструктуре, которой они, как правило, не владеют.
Владельцем информационной системы, как технологического актива, является тот, кто несет ответственность за ее жизненный цикл, эксплуатационную готовность, безопасность и развитие. В рамках организации это часто подразделение ИТ-службы или центры ответственности, такие как владелец сервиса или владелец инфраструктуры. Их право собственности — техническое и операционное. Они обеспечивают вычислительные мощности, хранилища, сетевые компоненты, ПО и прикладные системы, которые служат средой для обработки данных. Их ключевая задача — предоставление надежного и эффективного сервиса владельцам данных.
Таким образом, в рамках парадигмы ИТ-активов возникает фундаментальное разделение: владелец данных контролирует контент и логику его использования, а владелец системы контролирует контейнер и механизмы для этого использования. Конфликт интересов и зон ответственности между ними является классическим. Владелец данных требует от системы максимальной гибкости, доступности и функциональности, часто не учитывая технологических ограничений и стоимости владения. Владелец системы, наоборот, стремится к стандартизации, управляемости и безопасности инфраструктуры, что может восприниматься как ограничение для бизнес-подразделений.
С правовой точки зрения, если данные представляют собой объект интеллектуальной собственности или содержат перс данные, владелец данных выступает в роли правообладателя или оператора персональных данных, что налагает на него дополнительные обязательства, выходящие за рамки внутрикорпоративных отношений. Владелец системы в этой схеме становится обработчиком или уполномоченным лицом, действующим на основании договора или корпоративного регламента.
Следовательно, ответ на вопрос о владельцах в контексте ИТ-активов заключается в признании дуализма собственности. Эффективное управление ИТ-активами невозможно без установления прозрачных и формализованных отношений между владельцем данных как субъекта бизнеса и владельцем системы как субъекта технологического обеспечения. Это разделение прав и ответственности формирует основу для архитектуры управления предприятием, где ИТ-активы перестают быть просто затратами, а становятся объектом страт управления, требующего баланса между бизнес-ценностью и технологической целесообразностью.
#ит-активы
#владелец_данных
#владелец_ИС
👍4