Модные заголовки про оптимизацию кожаных мешков натолкнули меня на мысль порассуждать на футуристическую тему : а может ли 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
Текущая заметка про связь данных и 152-ФЗ.
Одним из недостатков базовых платформ по умалению данными,является неспособность к интерпретации перс. данных. Без вкрученных ML-модулей базовый алгоритм обнаружит только шаблон, без определения совокупности перс данных, подпадающих под 152-ФЗ
Тот же алгоритм квалифицирует категорию данных как биометрию или чувствительную, инсайдерку и т.д.
Ключевой фигурой, кто нужен - ответственный за обработку перс. данных, в быту - DPO.
DPO переводит законы в правила и классификации. Его экспертиза позволяет внести не только технические, но и юридически значимые метки, определяющие политику безопасности, получение доступа по ролевой модели. Без этого платформа превращается сперва в свалку, а затем в рискованный актив.
Данные из пассивного ресурса уходят в управляемый, обеспечивается легитимность данных.
С DPO данные становятся полноценным ИТ- активом и в последующем могут быть монетизированы.
Обрабатываете данные по закону, и прибудет с Вами сила !💪🏻
Одним из недостатков базовых платформ по умалению данными,является неспособность к интерпретации перс. данных. Без вкрученных ML-модулей базовый алгоритм обнаружит только шаблон, без определения совокупности перс данных, подпадающих под 152-ФЗ
Тот же алгоритм квалифицирует категорию данных как биометрию или чувствительную, инсайдерку и т.д.
Ключевой фигурой, кто нужен - ответственный за обработку перс. данных, в быту - DPO.
DPO переводит законы в правила и классификации. Его экспертиза позволяет внести не только технические, но и юридически значимые метки, определяющие политику безопасности, получение доступа по ролевой модели. Без этого платформа превращается сперва в свалку, а затем в рискованный актив.
Данные из пассивного ресурса уходят в управляемый, обеспечивается легитимность данных.
С DPO данные становятся полноценным ИТ- активом и в последующем могут быть монетизированы.
Обрабатываете данные по закону, и прибудет с Вами сила !💪🏻
👍2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
А теперь немного управленческих кейсов в мире big data.
Кейс: «Deadline или Качество?»
Контекст:
Крупный ритейлер запускает рекламную кампанию к «black Friday». Маркетинг опирается на сегментацию клиентов, которую рассчитывает ваша команда Data Science. За день до старта (вечер пятницы) выясняется, что в витрине DWH обнаружен критический баг: 15% клиентов попали не в свои сегменты (например, «потеряшки» получили премиальные скидки, а VIP — спам).
Бизнес-юнит говорит: «Мы не можем останавливать кампанию, потери составят миллион рублей за час простоя. Исправляйте на лету». Техлид говорит: «Чтобы пересчитать данные честно, нужно 12 часов, а старые данные удалить нельзя, так как они уже ушли в CRM».
Вопрос:
Как CDO/ COO каков будет ваш план действий в ближайшие 30 минут и в ближайшие 24 часа?
Кейс: «Deadline или Качество?»
Контекст:
Крупный ритейлер запускает рекламную кампанию к «black Friday». Маркетинг опирается на сегментацию клиентов, которую рассчитывает ваша команда Data Science. За день до старта (вечер пятницы) выясняется, что в витрине DWH обнаружен критический баг: 15% клиентов попали не в свои сегменты (например, «потеряшки» получили премиальные скидки, а VIP — спам).
Бизнес-юнит говорит: «Мы не можем останавливать кампанию, потери составят миллион рублей за час простоя. Исправляйте на лету». Техлид говорит: «Чтобы пересчитать данные честно, нужно 12 часов, а старые данные удалить нельзя, так как они уже ушли в CRM».
Вопрос:
Как CDO/ COO каков будет ваш план действий в ближайшие 30 минут и в ближайшие 24 часа?
Вариант ответа (можете изложить свою версию в комментариях):
1. ⛑️ Первая помощь (первые 30 минут)
Немедленная коммуникация с маркетингом. Если нельзя остановить рассылку, можно ли остановить списание средств? Блокировка отправки пушей/смс самым критичным сегментам (VIP), пока не разберемся.
2. 🧰Квадрат решений: Классификация инцидента по матрице «Срочность/Важность» и «Влияние на бизнес/Репутацию».
3. 🛠️Технический компромисс: Предложение тех.команде не пересчитывать 100% данных, а разработать скрипт «обратного потока данных» или обогащения данными на стороне CRM (досылка правильных атрибутов).
4. 🛎️ Прозрачность: Разбора полетов и план коммуникации с пострадавшими клиентами (извинения + двойной кешбэк), если баг дошел до пользователей.
1. ⛑️ Первая помощь (первые 30 минут)
Немедленная коммуникация с маркетингом. Если нельзя остановить рассылку, можно ли остановить списание средств? Блокировка отправки пушей/смс самым критичным сегментам (VIP), пока не разберемся.
2. 🧰Квадрат решений: Классификация инцидента по матрице «Срочность/Важность» и «Влияние на бизнес/Репутацию».
3. 🛠️Технический компромисс: Предложение тех.команде не пересчитывать 100% данных, а разработать скрипт «обратного потока данных» или обогащения данными на стороне CRM (досылка правильных атрибутов).
4. 🛎️ Прозрачность: Разбора полетов и план коммуникации с пострадавшими клиентами (извинения + двойной кешбэк), если баг дошел до пользователей.
👍1
Кейс №2: «Молчаливая поломка»
Контекст:
Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды. Вы открываете дашборд — данные действительно красные. Вы звоните инженерам: «Все сервисы зеленые, ETL (процесс загрузки данных) завершился успешно в 03:00 ночи».
Через час выясняется, что смежная команда обновила API системы-источника (CRM), но забыла предупредить. Данные загружались, но грузились NULL или дубли в ключевом поле revenue…
Вопрос:
Каков план ваших действий?
Что сделаете в первую очередь?
Как выстроите коммуникацию с руководством и командами?
Контекст:
Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды. Вы открываете дашборд — данные действительно красные. Вы звоните инженерам: «Все сервисы зеленые, ETL (процесс загрузки данных) завершился успешно в 03:00 ночи».
Через час выясняется, что смежная команда обновила API системы-источника (CRM), но забыла предупредить. Данные загружались, но грузились NULL или дубли в ключевом поле revenue…
Вопрос:
Каков план ваших действий?
Что сделаете в первую очередь?
Как выстроите коммуникацию с руководством и командами?
Непутевые Заметки Data Steward ‘а
Кейс №2: «Молчаливая поломка» Контекст: Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды.…
Вариант ответа:
1. Перевести разговор из эмоциональной плоскости в техническую: «Давайте разберемся, данные требуют верификации».
2. Маршрут данных (Data Lineage): Показать, как строится пайалайн. Использовать концепцию родословной данных, чтобы найти точку сбоя (source -> staging -> mart).
3. Иногда нужно иметь План Б: Быстрый запуск пересчета данных за выходные из сырого бакета (raw data) в обход сломанного API, если есть снапшоты. Оценка времени на исправление.
4. Управление ожиданиями: Предложить гендиру метрику "SLA по качеству данных" и создать протокол оповещения топ-менеджмента о "ненадежных данных" на дашбордах (например, раскрашивать плитки желтым, пока идет верификация).
1. Перевести разговор из эмоциональной плоскости в техническую: «Давайте разберемся, данные требуют верификации».
2. Маршрут данных (Data Lineage): Показать, как строится пайалайн. Использовать концепцию родословной данных, чтобы найти точку сбоя (source -> staging -> mart).
3. Иногда нужно иметь План Б: Быстрый запуск пересчета данных за выходные из сырого бакета (raw data) в обход сломанного API, если есть снапшоты. Оценка времени на исправление.
4. Управление ожиданиями: Предложить гендиру метрику "SLA по качеству данных" и создать протокол оповещения топ-менеджмента о "ненадежных данных" на дашбордах (например, раскрашивать плитки желтым, пока идет верификация).