🔥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
Модные заголовки про оптимизацию кожаных мешков натолкнули меня на мысль порассуждать на футуристическую тему : а может ли 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