Салют! Меня зовут Ваня Леонтьев, я директор по аналитике в СберМаркете. Эта статья о том, как мы оцифровали такую сложную концепцию как data-культура в компании. Поделюсь предпосылками, нашим подходом к расчету и планами по её развитию. Думаю, наш опыт будет интересен аналитикам, лидам аналитических команд, руководителям продукта и компаний в целом — всем тем, кто кто стремится продвигать культуру данных в своей компании. А также тем, кто хочет иметь инструмент для приоритизации и управления в команде аналитики.

Финансовый сектор уже давно одна большая "дата", когда банк принимает решение о том, выдать ли человеку или компании кредит, он анализирует сотни метрик. Я руковожу стримом Data Quality в Газпромбанке и расскажу о том, как мы решаем проблемы при интеграции с внешними источниками информации, какие оценочные метрики используем и как экспериментируем с моделями, прогоняя неверные данные.

Откуда берутся ошибки и чем внешние источники данных отличаются от внутренних

Чем больше данных, тем больше проблем, связанных с их качеством, причем к ошибкам может привести огромное количество причин.  Некоторые — банальные. Например, оператор при вводе персональных данных неправильно перепечатал ФИО из паспорта. Есть ошибки в проектировании систем. Скажем, разработчики проигнорировали требование к длине поля ввода данных. Например, поле «Паспорт выдан» ограничили 35 символами. Понятно, что нужно больше, но в системе сохраняются только первые 35 введенных символов: «ФМС Тверского района по городу Моск». Бывает, не учли, что какие-то данные вообще надо сохранять, а они потом потребовались. Например, пол клиента. Могут возникнуть сложности, связанные с потерей части данных при передаче информации из системы в систему в ходе ETL/ELT-процессов. При этом стоит разделять проблемы с качеством внутренних данных, которые находятся во внутрикорпоративных системах, и внешних, поступающих из сторонних источников. У нас в банке отлажены процессы по улучшению качества данных (КД), поэтому оно постоянно растет и стабильно выше, чем КД из внешних источников.

Полезная, актуальная и при этом полная документация - миф или реальность? В первой части статьи обсудим зачем вообще нужна документация (а когда она и не нужна вовсе), поговорим о распространённых проблемах и ошибках, а во второй - посмотрим на примеры специфичной документации, связанной с ML-моделями и данными.

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

“Письменный текст или иллюстрация, которая сопровождает программное обеспечение или интегрирована прямо в исходный код. Документация объясняет, как работает ПО или как его использовать. Может иметь разное значение для людей с разными ролями в команде”

Определение действительно неплохое, в нём содержится несколько важных свойств документации.

Всем привет!

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

Ещё отмечу, что это не какие-то мои наработки, а лучшие практики рынка, которые я решила собрать в одном месте. Поэтому ссылок будет много)

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

Начнём с того, что я поздравляю вас(потому что начинается всё самое интересное), если наступил тот счастливый момент, когда ваша компания настолько подросла, что для дальнейшего развития, ей просто необходимо познакомиться с целями внедрения системы аналитики:

Техрадар обычно бывает двух видов: или труп, или сделан неправильно. Я Олег Федоткин, Head of PaaS СберМаркета. Хочу рассказать, почему это так и как заставить техрадар работать.

Это текстовая версия моего выступления на Podlodka TechLead Crew. Если вам больше нравится смотреть видео, то оно здесь.

Привет! На связи Николай Шикунов и Леонид Сидоров из ML-команды СберМаркета. Модель, над которой мы работаем, прогнозирует наличие товаров на полках во всех точках, представленных в нашем приложении, и называется out-of-stock model. В этой статье хотим рассказать, какую проблему бизнеса мы решаем, как эволюционировал наш подход к управлению остатками с 2019 года и к чему мы пришли сейчас. 

Исследование команды анализа данных Яндекс Практикума, которое помогает понять, как изменяется запрос работодателей от грейда к грейду и что нужно аналитику, чтобы перейти с текущего уровня на вышестоящий. Мы выяснили, какие стратегии роста работают для аналитиков данных, и что сыграет против кандидата на собеседовании — делимся результатами. 

Команда исследователей Практикума направления анализа данных осенью 2022 года изучила актуальный скилсет аналитиков данных всех грейдов (система оценки уровня знаний и навыков, к которому в IT нередко привязывают уровень дохода). Результаты исследования объясняют, какие именно навыки позволяют джуну стать мидлом, мидлу — сеньором, сеньору — лидом. Полученные данные помогают понять, какими эффективными способами сами профессионалы наращивают свои компетенции.

Всем привет! В предыдущей статье мы рассказали об использовании коробочного продукта Master Data Management и обещали рассказать о дальнейшем развитии подходов управления справочниками в компании. Сегодня мы сдержим свое обещание.

Система MDM - специализированное программное решение, которое помогает унифицировать нормативно-справочную информацию (НСИ) во всех информационных системах предприятия и организовать управление НСИ

Коробочный продукт мы использовали в течение пяти лет. И спустя эти пять лет наша история создания и развития MDM получила логическое продолжение – мы создали свой программный продукт Master Data Management, о котором сегодня и расскажем вам.

Наступило новое время импортозамещения, поменялись платформы в компании, мы активно включились в процесс и разработали концепцию импортозамещенного MDM.

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

Всем привет! На связи Александр Киваев, руководитель направления департамента управления справочной информацией в команде управления данными «Ростелекома». Если у вас в компании внедрена и эффективно работает MDM система, то считайте, что вы сорвали джэк-пот, потому что это значительно облегчит вам процесс внедрения новых информационных систем в IT инфраструктуру компании, упростит и удешевит интеграцию имеющихся систем, и позволит вам создавать качественную аналитическую и управленческую отчетность, сократив при этом время на обработку, актуализацию и верификацию данных.

Именно эти преимущества мотивируют крупные компании внедрять MDM-решения. В этой статье мы хотим рассказать об опыте внедрения системы управления мастер-данными Ростелекома, о том с какими сложностями мы столкнулись и какими способами нам удалось их решить.

Привет! Меня зовут Михаил Благов, я руководитель департамента «Чаптер инженеров данных и разработчиков» в beeline tech. В этом посте я хочу поделиться способом, с помощью которого можно выбрать подходящую архитектуру для конвейера данных в зависимости от требований к нему. В частности, обсудим паттерн CDC (change data capture, aka «захват изменений»), основная идея которого — быстрая репликация какого-то источника в аналитическое хранилище. 

Под катом мы:

- познакомимся с вариантами архитектуры конвейеров данных: из каких компонентов и как его можно собирать,

- рассмотрим и сравним четыре разные архитектуры конвейеров.

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

Начнем с матчасти

Уже более десяти лет тот факт, что люди с трудом извлекают из своих данных полезную информацию, сбрасывают на чересчур большой размер этих данных. «Объем собираемой информации слишком велик для ваших хилых систем», — такой нам ставили диагноз. А лекарство, соответственно, заключалось в том, чтобы купить какую‑нибудь новую причудливую технологию, которая сможет работать в больших масштабах. Конечно, после того, как целевая группа по Big Data покупала новые инструменты и мигрировала с устаревших систем, компании снова обнаруживали, что у них по‑прежнему возникают проблемы с пониманием своих данных.

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

Мир в 2023 году выглядит иначе, чем когда зазвенели первые тревожные звоночки по поводу Big Data. Катаклизм обработки информации, который все предсказывали, не состоялся. Объемы данных, возможно, немного возросли, но возможности аппаратного обеспечения росли еще быстрее. Поставщики услуг все еще продвигают свои возможности масштабирования, но люди, которые сталкиваются с ними на практике, начинают задаваться вопросом, как они вообще связаны с их реальными проблемами.

А дальше будет и того интереснее.

Хабр, привет! Сегодня, в предпраздничный день, публикую статью Кирилла Евдокимова, директора практики Data Governance GlowByte. В области данных и аналитики он работает уже около 20 лет, последние 7 лет основной фокус – это Data Governance. Как говорит Кирилл, история с управлением данными всё еще остаётся terra incognita. В статье под катом он разбирает наиболее частые ошибки, проблемы, с которыми приходится сталкиваться компаниям, вступающим на тернистый путь управления данными.

Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в Quadcode. Сегодня хочу рассказать о Data-специалистах и познакомить вас с нашей командой Data Platform.

Добрый день!

Меня зовут Никита, я работаю ведущим системным аналитиком в Департаменте управления данными компании Ростелеком.

В данной статье я опишу наш опыт использования Реестра отчетов и Бизнес-глоссария, подводные камни, с которыми мы столкнулись, а также планы по оптимизации рабочих процессов в инструментах Data Governance (далее – DG).

Три года назад ИТ-команда Ростелекома разработала Реестр отчетов и Бизнес-глоссарий на базе Open-Source технологий, и данные модули впоследствии получили широкое распространение в периметре компании. Также была создана Единая точка входа, позволяющая сотрудникам получать быстрый доступ ко всем отчетам и бизнес-терминам, существующим в компании. За два года количество постоянных пользователей Единой точки входа увеличилось с 200 до 2300 человек, при этом количество уникальных посетителей Единой точки входа составляет порядка 400 пользователей еженедельно, и данная цифра постоянно растет.

Инструментарий для работы с данными покрывает значительный объем запросов Ростелекома в разрезе таких сегментов как B2B, B2C, БТИ и т.д. Подробнее можно прочитать здесь и здесь.

Департамент по управлению данными заинтересован не только в оптимизации процессов работы с данными во всей компании, но и в улучшении показателей пользовательского опыта в разрезе DG продуктов. Для этого необходимо модернизировать функционал существующих систем путем поиска точек роста и выпуска обновлений по их устранению. Искать точки роста мы решили при помощи интервьюирования пользователей и сбора обратной связи от них. По результатам были отрисованы карты пользовательских путей (cjm – "customer journey map") в разрезе DG инструментов, а также сформирован бэклог, описывающий основные зоны роста в части систем по управлению данными. В связи с этим, в скором времени планируется ряд обновлений с целью внедрения доработок и увеличения эффективности продуктов.

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

Разберем понятие Data Governance, что это и для чего оно предприятию.

Data Governance – это совокупность процессов определения наиболее важных данных для использования сотрудниками, присвоение им прав доступа и управления для отлаженной работы бизнес-процесса, а также защита данных от внешних воздействий.

Стоит отметить, что многие путают понятия Data Governance и Data Management.

Data Management это процесс сбора, хранения и обновления данных.

Можно сказать, что Data Governance формирует стратегию управления данными, а Data Management напрямую осуществляет управление данными согласно определенной стратегии.

Введение

1. Введение
2. Что такое MDM
3. Типы корпоративных данных: что такое справочные и транзакционные данные
4. Зачем оно нужно?
   
   • Зоопарк ИТ-систем и консолидированная отчетность
   • Интеграция систем
   • Единая база контрагентов
   • Очистка и нормализация данных
   • Случаи из жизни
5. Методы решения
   
   • Административное решение
   • Внедрение MDM-системы
6. Типы MDM-систем
   
   • Централизованная система
   • Аналитическая система
   • Гармонизированная система
   • Примеры реализации MDM-систем
7. Индикаторы необходимости внедрения СУ НСИ
8. Выводы

Привет!

Меня зовут Коля, и я системный аналитик.

В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет:

Рискну предложить несколько дополнений и уточнений к этому процессу - как на основании собственного опыта, так и обобщения опыта коллег, с которыми обсуждал этот вопрос.