Качество данных

Стратегия по управлению данными была принята в «М.Видео-Эльдорадо» в 2021 году. Она распространяется не только на дата-офис, но и на весь цифровой блок, а также сотрудников операционных подразделений, ведь каждый бизнес — процесс, ИТ-система, цифровой продукт — является и потребителем, и генератором данных. О том, какая роль в управлении данными отводится их качеству, и об их влиянии на бизнес, рассказывает Данила Наумов, CDO «М.Видео-Эльдорадо» и номинант на премию Data Award.

— Почему обеспечение качества данных стало актуальным для «М.Видео-Эльдорадо», да и ретейла в целом?

К середине 2023 года мы подошли достаточно зрелыми с точки зрения управления данными. У нас внедрен организационный фреймворк Data Mesh, сформированы 10 доменов данных со своими инженерными командами. При этом данные воспринимаются не как статичная, а как динамическая сущность, то есть продукт со своими метриками и планами развития, назначены владельцы данных. Есть централизованная платформа данных, включающая в себя ETL, хранилища, BI, инструменты MLOps, а также самописный каталог данных M.Data.

Кроме того, в компании внедрен федеративный орган – Дата Комитет, состоящий из владельцев доменов данных и представителей корпоративных функций архитектуры и информационной безопасности. Он устанавливает корпоративные политики в области работы с данными и согласует планы по развитию платформы данных.

Качество данных стало для нас очевидной зоной роста. Во-первых, мы занимались «тушением пожаров» вместо того, чтобы действовать проактивно. Мы узнавали об инцидентах с данными от пользователей и только после их обращения в поддержку. Во-вторых, хотя у нас уже были сформированы проверки качества для наиболее чувствительных данных, они являлись уникальными разработками со своей спецификой. Например, продукт по управлению ассортиментом магазинов крайне отзывчив к качеству данных – как загружаемых, так и расчетных. Стоимость потерь для компании в случае несвоевременной загрузки данных в этом продукте оценивалась в 60 млн руб. в день. Внедрение каждой новой проверки качества данных становилось долгой и ресурсоемкой задачей, не поддающейся масштабированию и переиспользованию. По мере роста бизнеса появлялось все больше ключевых data-driven процессов. Так возникла необходимость реализовывать такие проверки быстро и дешево.

— Какие из проблем были наиболее чувствительными?

Согласно внутренним опросам, отсутствие контроля за качеством данных входило в тройку «больных вопросов» по управлению данными, а повышение качества данных (валидация, достоверность, консистентность) – в тройку ожиданий. Пользователи, даже найдя данные в M.Data, не могли понять, достаточного ли качества эти данные для их задач и были вынуждены обращаться за поддержкой. И, наконец, из-за отсутствия процессов и политик управления качеством данных у владельцев данных просто не было возможности ставить долгосрочные и среднесрочные цели по развитию их активов.

Независимые оценки по методологии CMMI Data Management Maturity подтвердили необходимость разработки политики управления качеством и достоверностью данных на основе критических элементов данных, а также рекомендовали расширить платформу данных инструментами мониторинга и контроля их качества.

— На чем вы фокусировались при повышении качества данных?

Чтобы сформировать стратегическое видение по развитию качества данных, нам было важно определиться не только с тем, что мы делаем, но еще и с тем, что мы точно не делаем. Изучив теорию, мы выделили четыре блока управления качеством данных (Data Quality, DQ).

Первый из них – мониторинг DQ в соответствии с заведенными правилами и проверками. Мониторинг не меняет сами данные, а считает показатели DQ для конкретного актива в системе-источнике или хранилище данных. Второй блок – профилирование. Это статистический контроль – например, количество значений, частотная характеристика значений. Профилирование может быть как инженерное (количество заполненных полей, пустые поля и др.), так и бизнесовое. Третий блок – управление инцидентами. По мере запросов от пользователей или возникновения в результате мониторингов инциденты необходимо фиксировать и обрабатывать. И, наконец, клинзинг – процесс исправления ошибок не только в отчете или хранилище, но еще и в системе-источнике.

Рассылка в Telegram по инциденту на свежесть данных

— Что из этого оказалось важнее всего?

Проанализировав боли и ожидания, мы решили, что важнее всего сфокусироваться именно на мониторинге. Например, у команды логистики 95% проблем касались несвоевременной или неполной загрузки данных в хранилище.

Проверку качества данных над транзакционными системами-источниками мы решили оставить вне рамок нашего проекта, так как DQ-проверки – весьма ресурсоемкая операция, зачастую требующая полного сканирования, что сильно снизило бы производительность транзакционных систем. DQ-проверки в транзакционных системах релевантны только при распределенных транзакциях, и даже в этом случае сканирование будет осуществляться силами команд этих транзакционных систем. При этом, если мы на стороне аналитических систем находим ошибки, мы должны передавать информацию о них в команды исходных систем.

— Если обобщить, то какие цели перед вами стояли?

Мы хотели выстроить процесс управления DQ и обучить ему как инженерные команды дата-офиса и представителей других цифровых команд, так и операционные функции. Кроме того, требовалось внедрить дешевый, быстрый и автоматизированный инструмент, а также упростить предоставление информации о результатах проверок всем категориям заинтересованных пользователей. И, наконец, выстроить процесс и механизм передачи информации об ошибке в данных на сторону систем-источников.

— Как изменился процесс по управлению качеством данных?

Раньше если пользователь обнаруживал проблему с данными, он в самом худшем случае самостоятельно исправлял данные в своем дата-активе – например, внутри выгрузки в Excel. Таким образом, в компании появлялась новая, более качественная версия данных, а остальные пользователи продолжали работать с некачественными данными.

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

В текущей версии количество субъектов и сущностей остается тем же, но связующим дополнительным звеном становится инструмент Data Quality. Пользователь заходит в дашборд DQ, дата-каталог или получает уведомление от системы мониторинга и видит текущий уровень качества данных.

Рассылка в почту на статистическое отклонение

— Есть ли у вас требования для инструмента Data Quality?

Конечно, мы сформулировали их на основе анализа потребностей. Главных требований три.

Система должна преимущественно запускать проверки над теми же хранилищами платформы данных, в которых и хранятся данные. Запуск внутри инструмента DQ должен осуществляться только для кастомных проверок, требующих использования данных одновременно из нескольких систем.

Для масштабирования инструмента результаты проверок DQ должны представляться в нашей внутренней BI-системе, привычной для всех. Иначе мы бы сосредоточились не на внедрении процесса, а на внедрении ИТ-системы.

Система должна бесшовно интегрироваться с нашим самописным каталогом данных M.Data для отображения метрики DQ и истории проверок непосредственно в карточке дата-актива.

— Можно ли назвать то, что вы сделали, инновационным?

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

Интеграция метрик Data Quality в карточку дата актива в каталоге данных

— Измеряли ли эффективность проекта? Как оценить пользу для бизнеса от решения?

Эффективность можно показать на примере конкретных кейсов и бизнес-процессов, в которые было встроено это решение.

Например, команда логистики при планировании перемещений и поставок товаров использовала весогабаритные характеристики товара (ВГХ) из ERP. В какой-то момент коллеги заметили несоответствие данных фактическим значениям. В частности, не совпадали габариты товаров. DQ-команда выявила, что большинство аномальных значений выглядят как 1х1х1. Вместе с коллегами из команды мастер-данных выяснили, что заведение данных происходит сразу в нескольких системах: ВГХ для клиентов заводится в одной системе, для внутренних пользователей – в другой. Поля были обязательными для заполнения, но не было никакого контроля над процессом, поэтому при заведении нередко указывали пустые значения. На момент внедрения проверки в системе значилось более 5 тыс. наименований с некорректными габаритами. Логисты брали средние значения ВГХ по товарной группе, и неправильные расчеты приводили к ошибкам маршрутизации, необходимости ручных корректировок при планировании рейсов, а это означает задержки и отмены клиентских заказов.

Другой кейс – дубли чеков. Только за четвертый квартал 2023 года вторая линия поддержки дата-офиса обработала более 300 таких инцидентов качества данных. Это значит, что более 300 инцидентов не дошло до пользователей. Мы считаем, что демонстрацией зрелости в области управления качеством данных является и то, что мы поставили метрики качества в персональные KPI владельцам данных. Мне пришлось выступить амбассадором нововведения: я взял на себя самые востребованные дата-активы: чеки, заказы, веб-трафик, розничный трафик и основные справочники. За первый квартал 2024 года мы замерили текущие показатели DQ по этим активам и поставили измеримые цели на второй квартал. Для владельцев других доменов данных во втором квартале 2024 года мы сформируем показатели DQ по критическим элементам данных, и поставим цели на следующие кварталы.

Еще один важный кейс для любого ретейлера – расчет премий для сотрудников розницы. Иногда не вся атрибутика чека бывает верно загружена: не везде определяется продавец, кассир и категория товара. Была осуществлена проверка, и теперь наши коллеги заранее «отлавливают» отклонения и обрабатывают 150-200 обращений в месяц в рабочем режиме. При закрытии периода премия рассчитывается правильно.

И последний пример. Как известно, мы передаем фискальные данные в ФНС, а они в свою очередь сравнивают их с ОФД. Если есть хоть какое-то отклонение, из ФНС поступает запрос в бухгалтерию на проверку и корректировку. Когда возникали случаи несовпадения данных по причине сбоев в передаче данных с локальных касс в ОФД, это фиксировалось бухгалтерией через личный кабинет ОФД и требовало правок на стороне директора магазина. Конечно же, инциденты возникали в последний момент перед закрытием отчетного периода, что вызывало проблемы. Сейчас эти отклонения выявляются заблаговременно.

— Каковы основные итоги проекта?

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

— В чем заключаются основные факторы успеха?

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

— Каковы направления развития проекта?

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

Также через инструмент M.DQ мы хотим фиксировать контракты – то есть требования пользователей к данным, находящихся во владении у других, и проверять исполнение этих требований через проверки качества данных. И, естественно, планируем увеличивать количество дата-активов с проверками качества данных, наращивать базу стандартных проверок для увеличения скорости внедрения.

Сеть «Магнит» создала платформу управления данными. Среди целей проекта – оптимизация работы дата-сервисов и повышение прозрачности информационных активов, чтобы обеспечить доверие пользователей к предоставляемой аналитике. О масштабах проекта, его реализации и роли для развития компании рассказывают Павел Шорохов, директор департамента по работе с данными «Магнит», и Олег Молчанов, руководитель направления по метаданным и качеству данных, — номинанты премии Data Award.

- Что привело компанию к реализации проекта платформы управления данными?

Павел Шорохов: В компании около 10 тыс. пользователей данных. Они используют многоуровневую платформу, содержащую более 1 Пбайт данных (5 Пбайт с учетом кластеров Data Science). Более 2 тыс. пользователей обращаются напрямую к центральному элементу платформы – корпоративному хранилищу данных, – которое развивается уже 12 лет и содержит 420 Тбайт данных.

За это время система стала сверхсложной: в нее интегрировано чуть больше 200 систем-источников данных, а пользователи обращаются к 5 тыс. витрин данных. Такое количество разработанного функционала требует продвинутых возможностей для поиска нужной информации. А так как бизнес самостоятельно работает в пользовательских областях (так называемых «песочницах»), которых сейчас около 80, то потребовалось также повысить переиспользуемость объектов данных (информационных активов).

В середине 2022 года мы приняли решение об одновременном внедрении полного стека инструментов Data Governance & Data Quality и методологии работы с ними. Начав в ноябре, мы за полгода разработали, внедрили и опубликовали для целевой аудитории такие инструменты, как бизнес-глоссарий, каталог данных, автоматизированную систему контроля качества данных и виртуального дата-помощника.

- Какие задачи требовалось решить?

П.Ш.: Самое главное – требовалось оптимизировать работу дата-сервисов. Во-первых, ускорить поиск данных. Регулярно проводя опросы наших сотрудников, мы видели частые ситуации, когда пользователь не мог самостоятельно найти необходимые данные, которые есть в компании. Ему необходимо было пользоваться разрозненными сервисами, которые предоставляли отдельные подразделения. В итоге слишком много времени уходило на такие рутинные задачи, как отправка запроса на поиск данных, ожидание начала работы над таким запросом, собственно работа над запросом и другие дополнительные коммуникации. Большинство из этих задач можно и нужно было автоматизировать.

Во-вторых, было важно сократить время на разбор происхождения данных и анализ влияния изменений в данных, ускорить внедрение изменений. Дело в том, что системные аналитики, чей фокус в основном на развитии хранилища, в зависимости от задачи могли тратить на «ручной» разбор зависимостей от 2 до 16 часов, что имело негативное влияние на поставку изменений. Учитывая, что вся нужная информация уже существовала где-то в метаданных, мы понимали, что наша задача только организовать их удобное хранение и анализ.

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

Кроме того, было важно снизить расходы на поддержку существующих аналитических данных за счет выстраивания правильного пользовательского пути: сначала – self-service для поиска и понимания данных, а уже в случае возникновения вопросов — обращение к эксперту по данным в бизнесе или ответственным за реализацию. Также планировали снизить расходы через создание условий для переиспользования существующих наработок и сдерживания расширения «теневого ИТ».

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

Таким образом, мы в целом планировали повысить доверие к существующей аналитике и оптимизировать способы ее получения, что является фундаментом развития data-driven культуры в компании.

- Какой подход был выбран?

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

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

При внедрении крупных изменений очень важно создать коалицию: найти группу людей среди внутренних заказчиков, которые будут вести за собой остальных. Мы так и сделали, заручившись поддержкой одного из ключевых бизнес-блоков. Совместно с ним проходило обсуждение разрабатываемых процессов и обкатка всех первых наработок во внедряемых инструментах: процесс ведения бизнес-глоссария, выбор систем для каталогизации метаданных, валидация полноты и достоверности результатов сканирования метаданных, реализация первых проверок качества данных. Это помогло нам сделать коллег неформальным заказчиком проекта, заручиться их поддержкой и «живым примером» для дальнейшего тиражирования. Главный вывод – не внедряйте инструменты и процессы Data Governance & Data Quality в отрыве от реальности.

- Какие инструменты использовались?

О.М.: Мы использовали решения, продвигаемые DIS Group: бизнес-глоссарий, каталог данных, система управления качеством данных. Виртуальный помощник реализован с помощью собственной разработки. И в соответствии с нашей стратегией cloud first мы использовали инфраструктуру «Яндекс.Облако».

Созданная в результате платформа управления данными охватывает все промышленные данные компании, использующиеся в корпоративном хранилище данных и корпоративной отчетности.

- Что представляет собой созданное решение?

П.Ш.: Созданное решение — это единый портал пользователя данных, который можно условно разделить на несколько частей.

Во-первых, это портал для поиска данных и запроса доступов к ним. Одним словом – все, что нужно пользователю, когда он знает, зачем пришел. В этом случае ему нужно только помочь понять, где это находится, и получить доступ.

Далее, в портал встроен бизнес-глоссарий – своего рода «Википедия» про данные, где можно лучше понять значение найденных данных: изучить описание информационных активов, их место в корпоративной архитектуре данных, узнать, кто владеет данными и тому подобное. Теперь, когда пользователь обладает доступом к нужным ему данным, он хочет понять, насколько они соответствуют его ожиданиям – для этого существует модуль качества данных, который содержит дашборды и отчеты по качеству информационных активов.

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

- Что такое виртуальный дата-помощник, какова его роль?

О.М.: Это чат-бот, «прикрученный» ко всем страницам платформы управления данными. Мы его с некоторых пор «забрендировали» и стали называть Data Assistant. В прошлом году о первых версиях и «внутрянке» продукта мы рассказывали в статье: Как устроен виртуальный помощник для дата-сервисов в «Магните».

Сейчас через Ассистента можно решить полный перечень вопросов, связанных в данными. Он поможет сориентироваться в том, что вообще доступно: какие есть порталы и инструменты работы с данными (например, наш собственный BI-инструмент – «Магрепорт»), найти основные статьи из базы знаний, найти своего дата-партнера, вступить в дата-комьюнити и многое другое. С его помощью можно сформировать из чата запросы на информацию, сообщить об инциденте, запросить доступ к данным или инициировать изменения ролевой модели. Еще одна функция – найти данные и связанные информационные активы по ключевым словам. Бот, в основе которого лежит простенькая ML-модель, сам подберет соответствующие вашему запросу витрины данных, аналитические отчеты, показатели и аналитики из глоссария, бизнес-процессы и информационные системы.

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

- Что в ходе проекта было самым сложным? Какие уроки для себя вы извлекли?

O.М.: Самое сложное, как и всегда, – это люди. Точнее, изменение и дополнение существующих устоявшихся бизнес-процессов, по которым они привыкли работать. На первых этапах очень важно было суметь показать пользу от внедренных изменений и доказать, что потраченные усилия позволят сократить трудозатраты на рутинные задачи по работе с данными.

Главный урок – в таком проекте следует как можно раньше начинать обсуждать методологическую составляющую и договариваться об изменениях и зонах ответственности. Важно как можно больше рассказывать сотрудникам на всех уровнях про то, как меняются процессы, и почему это важно. Доносить, какую проблему решаем, и показывать, как повлияют изменения на производственный процесс. Конечно, все это нужно делать с использованием детально продуманных и визуально понятных материалов, а не только через объемный бизнес-процесс, описанный по стандартам компании.

- Что удалось лучше всего, а над чем еще предстоит поработать?

О.М.: Я считаю, что у нас хорошо получилось позиционировать новую платформу как экосистему по управлению данными для каждого, кто работает с данными и аналитикой. Для этого, помимо самого внедрения инструментов и связанных процессов, был исполнен огромный коммуникационный план: демонстрации в разных форматах для разной целевой аудитории, регулярные письма в корпоративной почте, мессенджере и других внутренних площадках о новом контенте, новой функциональности системы или новых бизнес-процессах.

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

Если говорить о том, чем еще предстоит заняться, то, безусловно, мы продолжим наполнять контентом бизнес-глоссарий и контролировать полноту и качество этого контента. Говоря простым языком, будем делать описание показателей, аналитик, сущностей по всей группе компаний и всем предметным областям. Это очень объемный труд, в который мы вовлекаем бизнес. Этот фронт работ мы планируем добить в 2024 году.

- Какие результаты достигнуты и ожидаются?

П.Ш.: План проекта на 2023 год был выполнен полностью. Все системы, а именно четыре компонента платформы – бизнес-глоссарий, каталог данных, автоматизированная система контроля качества данных и виртуальный дата-помощник – с полной функциональностью были поставлены бизнесу даже быстрее запланированного. Я считаю, что это получилось сделать во многом благодаря хорошо проработанному коммуникационному плану и вовлечению бизнеса, за что коллегам огромное спасибо. Для нас важно, что внутренняя команда «Магнита» приступила к самостоятельному развитию функциональности и наполнению контента сразу же после выхода системы в промышленный контур.

Инструменты уже востребованы: мы получили ежемесячную базу пользователей новых инструментов в размере 1 тыс. сотрудников, которые ежемесячно создают более 5 тыс. запросов на поиск данных. Мы ожидаем, что общая база наших пользователей составит примерно 3 тыс. сотрудников, и мы будем стремиться к тому, что со временем 80% из них будут посещать портал минимум раз в месяц.

Если говорить о контенте, то мы отсканировали и каталогизировали справочники MDM, витрины основного хранилища данных и двух дополнительных хранилищ. К каталогу данных для автоматического забора метаданных по расписанию подключено 12 систем. По ним теперь можно анализировать происхождение данных и проводить анализ зависимостей. Дополнительно пользователи получили более 7 тыс. описанных информационных активов.

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

Система продолжает развиваться, растет количество пользователей и сценариев использования, подключаются новые системы-источники метаданных.

- Какое влияние это оказало на ежедневную работу сотрудников?

П.Ш.: Приведу несколько примеров изменений, произошедших после публикации портала.

Например, в 10 раз снизилось время, которое тратит сотрудник на запрос доступа к данным. Сейчас пользователь тратит менее минуты за счет выстроенного пользовательского пути в виртуальном помощнике и прозрачности ролевой модели в связке с описанными данными.

На 15% снизилось количество запросов на информацию, поступающих к централизованной команде развития корпоративного хранилища. Это достигнуто за счет доступного описания данных и сценариев самообслуживания в Magnit Data. Соответственно, мы оптимизировали трудозатраты на анализ и консультации дорогостоящих специалистов – системных аналитиков.

В среднем на 15% выросло количество активных пользователей корпоративного хранилища и нашей BI-системы «Магрепорт» за счет популяризации использования данных, снижения порога вхождения в инструмент и увеличения доверия к данным через визуализацию их «здоровья». Это косвенно говорит о росте data-driven культуры в компании.

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

- А если говорить про работу дата-команды?

О.М.: Время реагирования на снижение качества данных уменьшено до одного часа, это очень серьезный результат. Ранее выявление проблем происходило по факту работы пользователей с данными, затем о проблеме сообщалось через внутренние системы к централизованной команде, а далее на поступившие инциденты реагировали в течение четырех рабочих часов на первой линии, плюс время на работы других участников процесса. Теперь же об отклонениях известно сразу всем участникам процесса одновременно: аналитикам КХД, экспертам по данным, поставщикам данных. Еще до начала рабочего дня они получают оповещения за счет автоматизированной системы контроля качества данных. Выстроены и регламентированы процессы реагирования на инциденты.

На 15% снижены трудозатраты аналитиков, занимающихся развитием и сопровождением КХД, на проведения анализа происхождения данных и анализа зависимостей при проектировании изменений в объектах данных.

- Пытались ли оценить эти эффекты в деньгах?

П.Ш.: Да, и если эффект, связанный с сокращением трудозатрат, легко считается (у нас есть стоимость человеко-часа и понимание того, насколько мы оптимизировали работу более 1 тыс. сотрудников), то интересней влияние на скорость и верность принятия решений. Менеджер теперь получает свой управленческий отчет раньше, а благодаря повышению качества данных повышается и качество управленческих решений, основанных на данных. Этот эффект посчитать сложнее, но очевидно, что в масштабах организации с более чем 360 тыс. сотрудников важность доверия к аналитическим данным сложно переоценить.

- Какую роль играет этот проект в развитии компании?

П.Ш.: Реализованный проект является фундаментом для другой стратегической ИТ-инициативы компании по импортозамещению технологий, на которых построена корпоративная платформа данных. При миграции на новую платформу важно понимать зависимости в исторически сложившемся хранилище, требования бизнеса к качеству данных, используемость данных. Создание новой платформы должно сопровождаться инструментами, обеспечивающими прозрачность новых информационных активов, и контроль качества данных на всех этапах жизненного цикла данных.

Также платформа управления данными Magnit Data является движущей силой внедрения операционной модели и процессов управления качеством данных компании.

- Каковы планы по развитию проекта?

О.М.: Фокус в первом квартале 2024 года – на стабилизации работы решения, отработке критичных для наших пользователей багов, автоматизации мониторинга работоспособности всех компонентов системы, выстраивании внутренних процессов реагирования на них. После «взрывного» внедрения и гонки во всех направлениях под конец прошлого года мы решили позволить себе такую паузу. Количество пользователей системы значительно выросло, а значит выросли и ожидания публики, и наша ответственность.

В целом на 2024 год планируется работа по нескольким направлениям. Это наполнение качественным контентом бизнес-глоссария в сопровождении связки концептуального, логического и физических уровней, а также контроль бизнес-процесса ведения бизнес-глоссария. Это разработка новых проверок качества данных для критических элементов данных по требованиям бизнеса – потребителей данных и владельцев данных. Будем проводить каталогизацию метаданных по строящейся у нас Корпоративной платформе 2.0 на новых технологиях. Планируется детальное изучение сценариев работы целевой аудитории, работа с продуктовыми метриками и обратной связью пользователей. Наконец, планируем разработку центрального упрощенного интерфейса для поиска информационных активов, рассчитанного на максимально широкий круг пользователей.

В «Северстали» использовали передовые практики управления данными для области технологических данных. В рамках проекта решена задача сбора технологических данных с датчиков и обогащения их метаданными: технические места, единицы измерения, связи с проектами, владельцами данных. Наличие полной информации о них помогает сэкономить время на коммуникации и поиски в ходе дата-проектов. О роли достоверных и прозрачных технологических данных для компании рассказывает Евгений Курильщиков, владелец продукта «Управление данными» «Северстали» и номинант на премию Data Award.

- Почему управление технологическими данными было выделено в отдельное направление, которое требует дополнительных усилий?

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

- В чем заключается особенность решаемой задачи?

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

- Почему это важно для «Северстали»?

Здесь нам поможет Льюис Кэролл: «Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте. Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!». Чтобы быть конкурентоспособными, нужно быстро принимать решения о том, как улучшить производительность, повысить качество, сократить незапланированные простои. Мы уже реализовали много проектов, используя технологические данные, и понимаем, что при реализации проекта уходит много времени на поиск тех самых 10-20 параметров работы оборудования, которые необходимы для реализации ML-модели. Имея хорошо описанные данные, мы сокращаем время разработки дата-продукта.

- С определением владельца других данных бывают проблемы, вплоть до назначения в приказном порядке. С технологическими данными все еще сложнее?

Да, я бы сказал, что здесь все еще сложнее. Ведь владельцем технологических данных является производственный персонал, так как операторы обеспечивают появление этих данных, знают все о конкретном датчике: где он установлен, как откалиброван, в каких единицах измерения снимает показания и т.д. Безусловно, инженеры являются специалистами высокого уровня, но их не обучали тем навыкам, которых мы сейчас от них требуем. А мы хотим, чтобы помимо сбора измерений они еще и описывали эти сигналы в нашей системе. Поэтому приходится дополнительно объяснять, зачем это нужно и каким образом нужно проводить это описание.

- Кто может быть владельцем технологических данных?

Как показывает практика, это технологический персонал: инженеры АСУТП, КИПиА, специалисты по ремонту и техническому обслуживанию – то есть сотрудники, которые занимаются обслуживанием оборудования, установкой и настройкой сбора данных в технологической сети.

- Как определяется политика сбора и хранения данных?

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

- Что было сделано в рамках проекта?

В инструменте управления данными была реализована карточка объекта «тег» и «техническое место». Настроены процессы сбора метаданных и разработан регламент описания, определены обязательные и необязательные атрибуты, которые нам необходимы. По мере работы с огромным массивом информации мы начали выявлять отклонения от ожидаемого процесса. Скажем, в исторических данных могло быть пропущено один-два месяца, и сегодня уже никто не знает почему. Или, например, мы выявили случаи, когда на уровне оборудования сигнал изменял физическую сущность. Это могло произойти, если датчик меняли и на контроллере в порт подключали измерение с датчика напряжения вместо датчика тока. Подобные открытия подвели нас к проверке качества данных, которые мы собираем.

- Как боретесь за качество данных?

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

- Каковы результаты?

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

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

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

Несколько проектных команд используют наш каталог как единственный источник данных об оборудовании и датчиках, которые на нем установлены. В настоящее время описано более 10% из более чем 500 тыс. активных сигналов.

- Какова роль проекта для компании?

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

- Каковы дальнейшие направления развития?

Основная задача – распространить практику описания сигналов на все цеха и агрегаты. Это и даст возможность перейти к созданию цифровой копии комбината.

- Как проект отразится на дальнейших дата-проектах «Северстали»?

Я считаю, что по мере описания сигналов, дата-проектов станет больше, а их реализация будет занимать меньше времени. Дата-инженеры будут избавлены от необходимости проводить изыскательские работы по поиску сигналов, которые собираются с оборудования, и проверять, насколько этим сигналам можно доверять.

Работа секции «Опыт» конференции «Качество данных 2023», проведенной в феврале издательством «Открытые системы», вызвала особый интерес у ее участников. Впрочем, это вполне объяснимо: здесь они смогли познакомиться с самыми интересными из недавно реализованных проектов, связанных с получением и использованием качественных данных.

Миграция и оптимизация аналитических ландшафтов

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

По словам Вадима Уланова, директора по данным компании «ВсеИнструменты.ру», на тот момент в ландшафте аналитики царил «зоопарк» технологий: PHP, Oracle, PostgreSQL, Golden Gate, Python, ClickHouse, PowerBI и пр. Последний рефакторинг кода проводился более трех лет назад, за это время многие из тех, кто разрабатывал процедуры для хранилища данных, покинули компанию. В результате образовалось значительное количество унаследованных программных модулей, которые были плохо документированы и практически не поддерживались. Их работа была нестабильной (сбои случались часто), поэтому исправления в них приходилось вносить регулярно.

От использовавшегося прежде ПО с открытым кодом решили отказаться. Вместо него выбрали платформу с максимальным количеством нужных приложений в рамках одного стека. Полный переезд на новую платформу занял около полутора месяцев. Команде проекта удалось не только реализовать весь базовый функционал, существовавший прежде, но и высвободить около 10 млн руб. в год за счет отказа от облаков и оптимизации ландшафта бизнес-аналитики. Кроме того, были снижены требования к квалификации разработчиков, благодаря чему экономия фонда оплаты труда при найме новых сотрудников составила около 20%. Благодаря тому, что специалисты при переходе на новую платформу заново переписали бизнес-логику хранилища данных и отказались от необоснованной кастомизации, скорость ежедневного обновления данных в хранилище увеличилась на 15%.

Перечисляя важнейшие уроки проекта миграции, Уланов отметил важность обучения сотрудников и формирования культуры работы с данными: «Если пользователи по-прежнему тянутся к Excel, значит, с ними недостаточно поработали. Нужно объяснять преимущества новых аналитических инструментов и добиваться того, чтобы люди поверили в их полезность и эффективность. И конечно, надо прививать сотрудникам культуру работы с данными».

В компании «ЦЕМРОС» (ранее «Евроцемент Груп») сейчас заканчивается проект перехода с прежней системы управления мастер-данными (MDM) на новую — его планируется завершить к апрелю. Как рассказали Илья Залозных, начальник отдела НСИ департамента информационно-цифровых технологий и архитектуры компании «ЦЕМРОС», и Елена Подгайная, руководитель проектов компании SOFROS, прежде в холдинге использовали решение «Парус» в качестве единой ERP-системы и разработанную своими руками систему MDM. К моменту начала проекта назрела необходимость существенно расширить ее функционал, но стоимость доработки была слишком велика. Кроме того, много сложностей возникало из-за того, что данные справочника материально-технических ресурсов были нечетко классифицированы, неточны или неполны, причем настолько, что однозначно идентифицировать многие позиции справочника было невозможно. Наконец, записи в справочниках нередко дублировались, что затрудняло слаженное функционирование информационных систем и подразделений компании. Если учесть, что число позиций в справочниках НСИ достигало 500 тыс., стало очевидно, что без перехода на новую MDM-систему накопившиеся проблемы решить не удастся.

Было решено переходить на новую систему на базе продукта «1С:MDM». Для ее интеграции с системами «Парус» и «1С:CRM» внедрили интеграционную шину DATAREON ESB.

В настоящее время компания находится на этапе перехода от прежней MDM-системы к новой: часть дочерних предприятий уже работают на базе новой системы, тогда как другая часть — пока на основе прежней. Как пояснил Залозных, такой подход был принят, чтобы снизить уровень стресса у сотрудников.

Благодаря внедрению новой MDM-системы и нормализации базы НСИ, существенно уменьшились затраты времени на поиск и анализ позиций в справочнике, сократились сроки выполнения конкурсных процедур на торговых площадках, ускорилась обработка заявок по справочникам. А за счет выявления и устранения дублей появилась возможность в перспективе сэкономить более 40 млн рублей благодаря более четкой идентификации остатков на складах. Кроме того, удалось провести инвентаризацию позиций МТР с привязкой технической документации. В результате оптимизации и усовершенствования бизнес-процессов по ведению справочников существенно повысилась продуктивность работы службы НСИ.

Рекомендации на основе лучших практик

Как привлечь внимание бизнеса к повышению качества данных? Для этого надо понять, что качество данных дает бизнесу, считает Андрей Трянин, начальник управления методологии и контроля работы с данными компании X5 Retail Group. Основываясь на этой идее, он и его коллеги решили разделить понятия технического качества данных и их бизнес-качества.

Андрей Трянин: «Зачастую бизнес пытается решить свои проблемы на уровне процессов и людей, но не обращает внимания на слой данных»

«Одно дело — решение чисто технических проблем, таких, например, как обеспечение своевременного обновления информации в витринах данных. И другое — решение бизнес-проблем, которое возможно на основе анализа качественных данных, — поясняет Трянин. — Например, почему не продается товар, который есть и в остатках на складах, и в ассортименте? Бизнес не заявит о том, что данные о товарах нужно отслеживать и как-то анализировать. Зачастую бизнес вообще не ассоциирует подобные проблемы с данными, поэтому пытается решить их на уровне процессов, людей, но не обращает внимания на слой данных».

Предметно заниматься бизнес-качеством данных в X5 Retail Group начали с декабря. Проведенная работа уже дала вполне заметный экономический эффект.

«Мы подтвердили гипотезу, и эффект от внедрения изменений оценивается в 'скромные' 50 млн руб. — отмечает Трянин. — Для компании это немного, но для моей команды это сумма средств на два-три года».

Подход к управлению качеством данных, основанный на соглашениях SLA, описал Евгений Виноградов, директор департамента аналитических решений компании YooMoney. Он и его коллеги выяснили, на какие проблемы с качеством данных чаще всего жалуются пользователи. Как оказалось, замечания в первую очередь касались недоступности данных, их неактуальности или некорректности. У дата-инженеров обнаружились схожие претензии, но, кроме того, у них были и нарекания к качеству исходных данных.

«Решением проблем с качеством данных может стать фиксация в документе SLA требований к данным с указанием приемлемых диапазонов показателей», — считает Виноградов.

С его точки зрения, в SLA для аналитических систем наиболее важными показателями являются полнота данных и их точность. Также следует контролировать доступность данных для пользователей и соблюдение четких сроков завершения обработки информации за предыдущие периоды. Кроме того, полезно отслеживать длительность инцидентов с данными и их максимальное количество за месяц. Что касается вопроса о том, стоит ли отражать в SLA работоспособность источников данных, Виноградов и его коллеги пришли к выводу, что исключить из SLA можно только параметры работоспособности второстепенных данных. Ответственность за важные источники аналитикам все-таки приходится брать на себя. 

Евгений Виноградов: «Решением проблем с качеством данных может стать формирование документа SLA»

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

«Дело осталось за малым — добиться того, чтобы зафиксированные в SLA договоренности соблюдались», — добавляет Виноградов.

Свой подход к обеспечению качества данных нашли в «М.Видео-Эльдорадо». Как рассказал Алексей Точилов, руководитель продукта Data Governance, в компании в силу исторических причин развиваются два хранилища данных — корпоративное и аналитическое. Они подчиняются разным департаментам, выстроены на базе разных технологических стеков, их сопровождают и поддерживают разные команды. До недавнего времени требования бизнес-заказчиков к данным в разных хранилищах формировались различным образом и проверки качества данных были реализованы по-разному. Неудивительно, что в некоторых случаях возникали расхождения в данных. Немало сложностей возникало и тогда, когда приходилось переносить отдельные активы данных из одного хранилища в другое: могли появляться дополнительные требования, обнаружить которые без выстроенной процедуры их отслеживания было проблематично.

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

За основу был взят каталог данных, а точнее — хранящиеся в нем метаданные и глоссарий, который содержит не только термины и определения данных, но и информацию об их семантике и происхождении (что особенно важно для поиска точек отказа при анализе инцидентов с данными). Управление качеством данных было решено реализовать на основе каталога данных: именно в нем теперь хранятся типы проверок качества, которые необходимо применить в отношении того или иного актива данных. Типы проверок, включающие описания их методологии в терминах бизнеса и описания алгоритмов, копируются в каталог из системы качества данных (она реализована на базе собственной разработки).

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

Нередко проблемы с качеством данных возникают из-за того, что не удается снизить их сложность. По словам Федора Медведева, директора департамента компании Naumen, отвечающего за цифровые сервисы и решения в образовании, помочь справиться с этой проблемой могут системы корпоративного поиска. В частности, поисковая система Naumen Enterprise Search, обладающая встроенными механизмами машинного обучения и средствами обработки запросов на естественном языке (Natural Language Processing, NLP), интегрирует разнородные источники. Система поиска использует единое окно доступа к данным, причем не только к внутренним, но и к внешним.

Внедренная в компании «Газпром Нефть» поисковая система Naumen сегодня охватывает около 50 тыс. пользователей, 50 источников данных и 30 млн документов, обрабатывая около 2,5 тыс. запросов ежедневно. В компании «Мосэнергосбыт» на основе такого же продукта выстроен автоматический мониторинг законодательства в области электроэнергетики: система опрашивает источники (внешние сайты) и ищет информацию о подготовке новых изменений в документах регуляторов. Кроме того, система помогает анализировать найденные данные, отслеживать упомянутые в документах сроки и пр. Что важно, она обеспечивает обсуждение найденных документов внутри организации (задействованы более 50 подразделений) и сведение различных позиций к единому мнению.

Нина Адамова, руководитель направления «Умный город» компании «МегаФон», считает, что вопрос доверия к предоставляемым руководителям данным сегодня является очень важным. Чтобы снизить информационную нагрузку, «Мегафон» создает для топ-менеджеров различных организаций персональные рабочие места — информационные панели, на которых визуализируются не более чем по шесть крупных диаграмм, отражающих актуальные данные по наиболее насущным вопросам, тогда как прочие сведения отображаются в свернутом виде — при желании их можно развернуть и изучить более подробно. Данные для таких систем могут извлекаться из десятков, а иногда и из сотен различных источников — как внутренних, имеющихся в головном офисе или дочерних организациях, так и внешних. К сожалению, раскрывать детали обеспечения качества данных для систем руководителей «Мегафон» пока не готов.

Большинство компаний привлекают для получения ценной информации всё новые источники данных, причем делают это предельно осознанно, имея перед собой четкую цель. В рамках дискуссии «Можно ли предвидеть непредвиденное?», состоявшейся на форуме «Данные – катализатор цифровизации», организованном DIS Group, участники обсудили расширение спектра данных, используемых для анализа, и подходы к управлению данными.

Заглянуть в расплавленную сталь

Как отметил Максим Феопентов, директор по развитию цифровых технологий «Евраз», данные используются каждый день для принятия оптимальных решений абсолютно всеми, и сталеплавильные производства – не исключение. Однако можно отметить, что типы привлекаемых данных становятся другими, зачастую принципиально новыми. Например, в «Евраз» стали анализировать не только видео, но и звуки производственных процессов.

«Мы развиваемся, пытаясь понять, что еще можно взять из процессов, помимо табличных данных. Хочется понять, что творится в глубине сталеплавильных агрегатов, именно это подвигает компанию проводить эксперименты даже с акустической диагностикой процессов», — подчеркнул Феопентов.

Максим Феопентов: «Хочется понять, что творится в глубине сталеплавильных агрегатов, именно это подвигает компанию проводить эксперименты даже с акустической диагностикой процессов»

Финансовый сектор тоже ищет свой путь: рынок требует максимальной скорости. Модели предвидения ситуации и различных расчетов в зависимости от внешних факторов занимают большую часть работы банков. Данные проникают во все процессы, в том числе связанные с оценкой рисков и борьбой с мошенничеством.

«Мы большинство усилий концентрируем на способности предугадать потребность клиента и предложить ему максимально подходящий продукт. Данные для этого используются повсеместно, начиная с сегментации клиентов и выявления их моделей поведения на основе транзакционных данных и до анализа записей звонков в контакт-центр», — рассказала Светлана Бова, CDO ВТБ. Отдельное направление – метаданные, которым в ВТБ сейчас уделяется очень много времени и усилий, это крайне важная часть работы. Автоматизируется их сбор и интерпретация, что помогает как в ускорении процессов, так и в оптимизации отчетности.

«Можно разделить вопрос на две части: зачем нам данные и каким образом они используются», — считает Павел Шорохов, директор департамента по работе с данными сети «Магнит». По его словам, потребности в большинстве компаний одинаковы: data science, выверенная корпоративная отчетность, ad-hoc аналитика, системы лояльности и оптимизация логистики. А вот сценарии использования у многих уникальные. Например, «Магнит» ежедневно доставляет товары из 45 распределительных центров в 26 тыс. магазинов. Требуется отслеживать наличие каждого из товаров, оценить необходимый объем доставки, стимулировать продажи промоакциями. Главная цель при этом – увеличение доходности торговли и минимизация логистических издержек.

Доверие к данным и ответственность за них

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

Как рассказал Феопентов, «Евразу» помогла концепция ‘гражданских’ (citizen) дата-сайентистов, находящихся в бизнес-подразделениях. Им предоставляется поддержка и обучение, а затем они работают в автономном режиме. Таким образом расширяется штат профессионалов, появляется возможность быстро проверять бизнес-гипотезы и в конечном итоге экономятся ресурсы. Сейчас в «Евразе» идет уже третья волна обучения таких экспертов.

«Вопрос, где брать кандидатов на обучение и что с ними потом делать – нужно понимать, где должно быть их место после получения новых компетенций», – признал Феопентов. По его словам, около 60% обучившихся применяют полученные знания на практике – это очень хороший результат, и позитивный эффект от такого подхода очень заметен.

Феопентов отметил растущую роль дата-партнеров – экспертов, аккумулирующих бизнес-потребности определенного блока. До сих пор это направление в «Евразе» не сильно развивалось: функция Data Governance до определенного времени не получала приоритета, однако сейчас она есть в целях компании и активно развивается. Запрос со стороны бизнеса на данные породил потребность в выстраивании процессов по управлению данными.

«Важно вовлечение бизнеса в управление данными напрямую, и с этой точки зрения большое значение имеет доверие к данным. Когда данными управляют сотрудники твоего подразделения, доверие к ним выше», — констатировала Бова. Именно поэтому такая распределенная система управления данными и признана в мире. Распространение Data Governance как ответственности за данные внутри бизнес-единиц набирает обороты, потому что доказывает свою эффективность.

Если говорить про ВТБ, то концепция Data Governance все сильнее прорастает в бизнес-подразделения. С точки зрения выстраивания ответственности по всей цепочке следования данных банк выходит за контур хранилищ и проникает на уровень фронт-офисных систем. Распределение ответственности за данные перешло в операционную модель, в жизнь сотрудников, а в будущем планируется оценивать влияние качества данных на процессы и их этапы.

Изменения в «Магните» начались пару лет назад, когда стало очевидно, что департаменту управления данными не хватает гибкости с точки зрения управления своими приоритетами и ресурсами; кроме того, оставляла желать лучшего скорость реакции на запросы бизнеса – требовалось сокращение сроков разработки систем.

Павел Шорохов: «Естественно, бизнес-заказчикам не хочется подстраиваться под режим работы ИТ. Напротив, они предпочитают, чтобы ИТ-специалисты встраивались в их команды»

«Естественно, бизнес-заказчикам не хочется подстраиваться под режим работы ИТ. Напротив, они предпочитают, чтобы ИТ-специалисты встраивались в их команды. Пару лет назад у нас это не получалось из-за того, что подразделение было монолитным», — сказал Шорохов. Эта проблема была решена внедрением института дата-партнеров. Фактически это мини-CDO по направлениям бизнеса, находящиеся в общем офисе CDO. Для них главным показателем является удовлетворенность бизнеса, но при этом они участвуют в развитии данных в соответствии с общей стратегией.

«Нам это очень помогло: во-первых, мы стали работать гораздо быстрее, во-вторых, мы действительно стали партнерами бизнеса», — резюмировал Шорохов. Как следствие, в компании началась сервисно-продуктовая трансформация. Элементы корпоративной платформы данных разделились на продукты, у которых появились свои владельцы.

***

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

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

Управлению нормативно-справочной информацией был посвящен целый блок докладов в рамках организованного издательством «Открытые системы» форума «Управление данными — 2021», и эти выступления вызвали чрезвычайно высокий интерес у слушателей. Одним из докладчиков стала Яна Соколова, заместитель руководителя департамента PLM и САПР Объединенной двигателестроительной корпорации, рассказавшая о результатах внедрения и тиражировании системы класса Master Data Management (MDM) на базе решения Semantic MDM. Мы поговорили с ней об итогах и уроках проекта, а также о достигнутых бизнес-эффектах.

- Как в ОДК пришли к необходимости централизовать справочники на базе единой системы MDM? Какие для этого были предпосылки?

Мы дошли до состояния, когда у нас стало слишком много справочников и данных в них. Справочники никак между собой не синхронизировались и жили отдельной жизнью. Данные такого объема было невозможно консолидировать вручную. Однако для подготовки междисциплинарных отчетов требовалась синхронизация справочных данных в общей архитектуре ИТ-систем предприятия. И решать эту задачу становилось все сложнее.

- Что стало непосредственным толчком для начала проекта?

В 2012 году мы начали внедрение на заводе «Салют» системы САПР технологических процессов и поняли, что все эксплуатируемые решения используют собственные справочники.

Ввод очередной такой системы уже становился проблемой — справочники необходимо было централизовать. Возможно, тот проект и мог быть реализован в существовавшей архитектуре, но получить от него полноценный эффект было бы нереально. Мы отложили внедрение САПР и начали устанавливать систему класса MDM, планируя подключить ее ко всем существующим решениям. Впоследствии все внедряемые решения мы также подключали к ней, и новых справочников с тех пор не создаем.

- С чего был начат проект, какие этапы он включал?

Справочники — общая дисциплина, в равной степени относящаяся и к бухгалтерии, и к закупщикам, и к инженерам. Но исторически сложилось так, что проект реализовывала служба главного технолога — именно он был главным функциональным заказчиком. Поэтому начали с инженерного контура — технологических и конструкторских данных. Затем постепенно перешли на остальные: финансовый, закупочный. Далее подтянули справочник контрагентов и т. д.

- С какими проблемами пришлось столкнуться при реализации проекта? Какие из них были сложнее — организационные или технические?

Сама система довольно сложна — это не офисное приложение, которое работает «из коробки». Она требует существенной кастомизации, но не из-за особенностей процессов, как это бывает с большинством бизнес-приложений, а из-за необходимости учитывать нюансы. Например, понадобилось значительно доработать решение с точки зрения возможности встроить его в другие системы, являющиеся потребителями справочной информации. Пришлось выполнять много интеграций, преобразований данных. На сегодняшний день к MDM подключены 34 информационные системы, и с каждым годом мы наращиваем их число. Конечно, все эти годы мы работаем с разработчиком системы — SDI Solution, постепенно дорабатываем функциональность: расширяем, улучшаем, оптимизируем.

Однако технические вопросы доставляют не так уж и много проблем, тем более что мы постоянно ощущали поддержку разработчика. Всегда сложнее решать организационные моменты, ведь в процесс изменений было вовлечено много народа. Подразделение, действующее по определенным, давно сложившимся бизнес-процессам, вовсе не горит желанием работать по-новому. Скорее, его сотрудники негативно отнесутся к попыткам «ломать» их процессы.

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

- Часто говорят о важности административного ресурса. А реально ли в принципе выполнить подобные проекты без поддержки руководства?

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

Кроме того, одновременно на предприятии внедряли новую систему ERP. Руководители этого проекта тоже заявляли о пользе централизованной MDM и настаивали на использовании нового справочника. Это усилило наши позиции.

- Почему выбрали именно Semantic MDM? Каковы были ключевые критерии выбора системы? Существовали ли альтернативы? Ведь рынок MDM-решений далеко не пуст.

Это сейчас рынок не пуст. А почти 10 лет назад большинство решений были представлены импортными производителями. Дорого и сложно. К тому же зарубежный поставщик всегда неприятен для оборонной промышленности. Тренд на импортозамещение еще не был обозначен, но отечественные разработчики все равно были в приоритете.

Кроме того, к внедрению MDM мы пришли через другие проекты — в частности, САПР технологических процессов. А в этой области можно рассматривать только отечественных производителей. Остановились на решении Timeline компании SDI Solution, и наличие у этого поставщика системы MDM стало серьезным аргументом в его пользу.

- В чем заключалось участие в проекте производителя системы?

Сотрудники компании были полностью вовлечены в наш проект, в начале пути мы работали одной командой. Они присутствовали на нашей территории, совместно с нами разрабатывая проектные решения. Это важно, потому что у нас совсем не было опыта работы с MDM.

- Какие преимущества построенного решения вы можете выделить? Чем можно гордиться?

За 10 лет мы внедрили систему MDM, которая содержит более 4 млн объектов, 1,5 млн из них — справочник номенклатуры. К централизованному справочнику подключены 34 системы, использующие его данные. Это говорит о том, что система нормативно-справочной информации разрослась, «пустила корни» и плотно вошла в ИТ-архитектуру холдинга. Мы масштабировали ее на 12 площадок, и культура управления нормативно-справочной информацией уже охватила общие бизнес-процессы компании. Этим, безусловно, можно гордиться.

Мы начали раньше большинства компаний: «мода» на внедрение MDM начала появляться лишь к 2015 году. Сейчас у нас охват больше, чем у многих других, и подключено большее число предприятий. Кстати, многие крупные компании — например, из нефтегазовой отрасли — также серьезно продвинулись в области MDM, но до поры они предпочитали зарубежные решения. Сейчас в этом секторе также появилась тенденция перехода на отечественные разработки.

Мы поменяли много версий системы, каждый год внедряем серьезные обновления. Процессы управления НСИ выстроены таким образом, что между инициаторами заявок и экспертами, обрабатывающими их, получается хороший диалог. Удобно подавать заявки и обрабатывать их, удобно отслеживать выполнение SLA и KPI. Мы можем переработать достаточно большой объем исторических данных, сформировали довольно большую экспертную базу.

В этом году мы перешли на веб-версию системы. Это важно, так как инициаторов подачи заявок становится все больше, к системе подключаются целыми службами. Пользователям уже не нужно даже устанавливать клиент. Процесс подачи заявок становится все менее трудоемким и более прозрачным.

- А что можно было бы сделать лучше? Какие уроки вы вынесли из этого проекта?

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

- Каковы эффекты от реализации проекта, в том числе экономические?

Можно выделить несколько уровней эффектов. Самый первый — качество данных. Конечно же, создание централизованной системы управления НСИ серьезно повышает качество данных по сравнению с использованием локальных справочников. И это уже само по себе достойный результат. Когда мы нормализовали исторические объемы из двух основных контуров — инженерного и коммерческого — и смогли их свести между собой, то они совпали далеко не полностью. До внедрения MDM никто не мог точно сказать, какова потребность в материалах и обеспеченность ими.

Во-вторых, выяснилось, что в коммерческом контуре (то есть на складах) около 30% неидентифицируемых, «мусорных» данных. Они либо были неверно введены, либо дублировались. В результате такие объекты на складах представляли собой мертвый груз, который нельзя списать на производство из-за невозможности его идентифицировать. И 20% таких данных находилось в инженерном контуре. Мы не пытались это перевести в денежное выражение, но очевидно, что потери были существенные. И при масштабировании на другие площадки полученный эффект возрастает кратно.

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

- Масштабирование проекта — отдельная сложная задача. Как происходит этот процесс в территориально распределенной структуре Объединенной двигателестроительной корпорации?

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

- Какими вы видите перспективы развития проекта? Куда движется созданная система?

Дальше речь пойдет об использовании достигнутых результатов: MDM должна начать полноценно работать и приносить максимальный эффект.

Будем создавать озеро данных, в которое планируем подгружать транзакционные данные, порождаемые учетными системами, — их много. Будем внедрять BI и настраивать различные аналитики, которые позволят оптимизировать основные бизнес-процессы корпорации. Планируем отслеживать разрывы между потребностью и обеспеченностью, оценивать остатки на складах, выявлять тренды по заказанным и списанным материалам, отслеживать рассинхронизацию между заказанными и списанными в производство материалами. Управление такими показателями станет прозрачнее и проще.

Управление на основе данных постепенно превращается из роскоши в необходимость для организаций любого масштаба и отраслевой принадлежности. Однако внедрение подходов data-driven — сложный проект, затрагивающий все аспекты деятельности организации: от технологий до управленческих практик, бизнес-процессов и культуры. Форум «Управление данными — 2021», организованный издательством «Открытые системы», охватил все эти направления. У компаний постепенно накапливается опыт «правильной» работы с данными, что отражается и на программе форума: с каждым разом все больше места в ней отводится практике.

«Умейте выжидать, умейте нападать…»

У каждой организации свои цели, видение и миссия, свои потребности, особенности и окружающая среда. Именно поэтому универсальных рецептов в управлении данными не существует, компаниям многое приходится придумывать самим. Тем не менее, по мнению Александра Погосьяна, исполнительного директора по направлению «Качество данных» в «Сбере», все стратегии по управлению данными можно разделить на два типа: «защита» и «нападение».

Александр Погосьян: «При выборе стратегии управления данными не стоит ударяться в крайности»

«Защита» подразумевает обилие регуляторных ограничений и приоритет требований безопасности. Но когда ограничений не слишком много, можно уделить гораздо больше внимания «нападению» — захватывать рынок и развиваться. По словам Погосьяна, типичная отрасль, для которой характерна стратегия защитного типа, — здравоохранение, а атакующего — ретейл; финансовый сектор находится примерно посередине. Эти стратегии отличаются технологическими и организационными особенностями. Например, для защитной стратегии характерна высокая степень централизации; это касается и функции CDO, и бюджета. В ее рамках все централизовано и часто доминирует теория: тратится много усилий на создание «единой версии правды», единых стандартов, политик, методик.

Когда же преобладает нападение, приоритет получает децентрализация. Функция CDO расплывается по бизнес-подразделениям, формирующим собственные бюджеты. И подразделения при работе исходят из собственных, сугубо практических задач.

«Как и в спорте, защиту выстроить проще, поэтому компании обычно начинают с нее, а затем переходят к нападению. Обратный подход гораздо сложнее», — отметил Погосьян. Тем не менее, как обычно, не стоит ударяться в крайности. Должен быть баланс между развитием бизнеса и соблюдением комплаенс-требований.

По-прежнему с бубнами

«Счетная палата является одним из лидеров цифровой трансформации органов государственной власти, цифровизируются и объекты ее контроля. Но в реальной работе мы сталкиваемся с тем, что без танцев с бубнами никак не обойтись. Очень печально, что государственным органам не удается выбрать другую музыку», — посетовал Валерий Сохоров, руководитель центра экспертно-аналитических и информационных технологий Счетной палаты РФ.

Валерий Сохоров: «85% рабочего времени инспектора тратится на поиск данных в информационных системах объектов контроля. Если эту рутину удастся снизить с 85% хотя бы до 50%, это станет отличным результатом»

Казалось бы, все необходимые системы внедрены и работают, но по факту инспекторы продолжают работать в электронных таблицах и текстовых документах. Дело в том, что органы власти не слишком сильно хотят делиться информацией не только с бизнесом, но и с органами аудита. Логика очевидна: если данные будут слишком хороши, то с их помощью будет легче выявить нарушения и наказать за них. Как подчеркнул Сохоров, 85% рабочего времени инспектора тратится на поиск данных в информационных системах объектов контроля. Если эту рутину удастся снизить с 85% хотя бы до 50%, это станет отличным результатом.

В Счетной палате работают более 700 инспекторов, которые проводят в среднем 150 проверок в год. В этих условиях Счетная палата остро нуждается в комплексной системе управления данными. Если возникает необходимость проверки, инспектор должен обращаться не к объекту контроля и тратить время на взаимодействие с ним, а непосредственно к данным.

В 2021 году в Счетной палате была создана единая команда по работе с данными, в которую, помимо «технарей» и дата-аналитиков, входят 52 дата-стюарда, являющихся, по словам Сохорова, «переводчиками между айтишниками и чиновниками».

Путь осознанного потребления

«В будущем компании будут управлять данными, потому что этого будут требовать не регуляторы и руководители, а клиенты и партнеры. Приходит время культуры, основанной на осознанности потребления данных», — считает Полина Минеева, руководитель практики Applied Intelligence в Accenture.

Полина Минеева: «В будущем компании будут управлять данными, потому что этого будут требовать не регуляторы и руководители, а клиенты и партнеры. Приходит время культуры, основанной на осознанности потребления данных»

Действительно, все компании начинали свой путь к управлению данными с проектов, заключающихся в разработке стратегии использования данных и повышения их качества, стремясь ускорить получение регуляторной и управленческой отчетности. Эти проекты реализовывались исключительно по требованию регуляторов и руководства компании. Они характеризовались жестко централизованной моделью и созданием единого центра компетенций внутри организации. Впоследствии приоритеты существенно изменились: компании начали управлять данными, потому что увидели в этом ценность для себя. Как результат, в ходе проектов стали появляться два-три центра компетенций, в бизнесе произошла федерализация данных. Изменились и технологии: на смену традиционным хранилищам данных пришли гибридные решения и микросервисная архитектура.

Сейчас наблюдается новая тенденция, — data minimalism: происходит переход от больших (big data) и умных данных (smart data) к minimum viable data — минимально необходимым данным для создания конкретного информационного продукта. Такая осознанная фильтрация данных не только сокращает стоимость их хранения и обработки, но и, например, позволяет четко ответить клиентам на вопрос, какие данные о них собираются и с какой целью.

Большие данные для малых предприятий

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

«Не имея достоверных данных, решения о старте и развитии бизнеса принимать очень сложно: предприниматель, организуя свое дело, должен просчитать множество факторов. Крупный бизнес для этого привлекает консалтинг и пользуется услугами профессионалов высокого класса, а у ‘малышей’ таких возможностей нет», — подчеркнула Мария Поликанова, управляющий директор SberData и руководитель стратегического комитета Ассоциации больших данных. Предпринимателям нужна поддержка принятия решений: отчеты, фактически обрисовывающие перспективы на ближайшее будущее, а в идеале – финансовый план на три года.

Мария Поликанова: «Не имея достоверных данных, решения о старте и развитии бизнеса принимать очень сложно: предприниматель, организуя свое дело, должен просчитать множество факторов»

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

Без бизнеса не обойтись

«Далеко не все аналитические проекты являются успешными. Где-то нарушается бюджет, где-то — сроки, где-то достигаются не все цели. Всегда что-то может пойти не так», — признал Иван Вахмянин, генеральный директор компании Visiology. По его убеждению, большая часть проблем связана не с технологиями, а с соответствием бизнес-задачам, наличием компетенций и готовности меняться. Основной эффект дает не само внедрение BI, а именно управление на основе данных. Для этого необходимы и качество данных, и корректная их обработка, и визуализация, и заточенность на предметную область. Но самое главное — должны быть внедрены соответствующие управленческие практики. Если менеджеры не привыкли работать с данными и не верят в это, то им не помогут даже лучшие инструменты.

«Большое количество возникающих в ходе проектов проблем связано не с техническими решениями, а с неверным подходом. Пробивать лбом стены — не самое правильное занятие», — согласился Олег Гиацинтов, технический директор DIS Group.

Роль CDO в компании до сих пор размыта, на него часто взваливают много лишнего. Например, его обязанности могут включать защиту и обеспечение безопасности данных, создание аналитических систем. В результате Data Governance в компании часто остается «на бумаге», за теоретической деятельностью не доходит до реальной работы с данными. Отсутствие реального финансового эффекта предсказуемо приводит к смене CDO. Гиацинтов привел примеры «лучших практик» CDO-долгожителей: необходима стратегия управления данными; нужны наглядные примеры того, как аналитика данных может стимулировать бизнес-результат; в обязательном порядке следует выбрать одного-двух передовых директоров для поддержки и показать другим руководителям результаты их работы.

К слову, именно таким путем пошла Светлана Бова, CDO ВТБ, заручившись в начале своей работы поддержкой департамента рисков. Она рассказала о выстраивании в банке карт потоков данных — data lineage. Наличие такого инструмента радикально сокращает время решения аналитических задач. Возможно, он не обязателен для небольших компаний, но когда речь заходит о больших масштабах, то все меняется. Например, такой подход позволяет просчитать, на какие из систем повлияет изменение части корпоративного ландшафта, а также серьезно помогает в решении инцидентов, касающихся качества данных.

«Наша цель — стать data-driven-компанией. Самое привлекательное в этом — возможность отдать рутинные процессы искусственному интеллекту, а человеку оставить лишь стратегические задачи», — заявил Сергей Иванов, CDO «Уралхима». Чтобы это стало реальностью, нужна трансформация культуры и открытость бизнес-подразделений новшествам, их помощь в создании цифровых продуктов. Как подчеркнул Иванов, пока бизнес не вовлечен в этот процесс, серьезного эффекта не будет. Как следствие, на первый план у ИТ-подразделения выходят задачи по обучению бизнеса.

«Данные — это актив. Мы просчитали, что произойдет, если не будет соответствия между одинаковыми продуктами в разных странах, и результаты нас впечатлили», — рассказала Анна Дудина, руководитель функции по управлению мастер-данными IDS Borjomi International. Сразу после восприятия данных как актива естественным образом встает вопрос управления ими и контроля их качества. Актив необходимо описать и оценить, и он должен иметь хотя бы одного бизнес-владельца, а в идеале — ровно одного. Кроме того, данные публикуемые цифровыми продуктами, должны ссылаться на описание используемых активов данных.

В 2020 году в IDS Borjomi International был начат масштабный MDM-проект, в ходе которого пришли к необходимости создания совета по управлению данными (data council) — совещательного органа, на котором принимаются решения, связанные с анализом данных, а также с планированием и контролем работы с данными.

В пивоваренной компании «Балтика» тоже разработали ролевую модель, привлекающую бизнес-функции к управлению данными. «Данные должны иметь 'имя и фамилию' — только так можно добиться их качества», — уверена Варвара Макарьина, отвечающая в компании «Балтика» за реализацию стратегии Data Governance. Практика показывает, что до 30% времени сотрудников тратится на поиск данных и оценку их качества. Более того, часто компании зависят от экспертов, которые знают о данных все и уход которых может стать катастрофой. Внедрение в «Балтике» каталога данных позволило решить эти проблемы.

Варвара Макарьина: «Данные должны иметь 'имя и фамилию' — только так можно добиться их качества»

«В онлайн-продажах, в отличие от традиционного ретейла, решение о покупке зачастую принимается исключительно на основании представленной информации о товарах, поэтому качество данных приобретает критически важное значение», — отметил Юрий Кротков, менеджер проектов в «Яндекс.Маркете». Любой инцидент, связанный с качеством данных, влияет на продажи, а иногда и на логистические процессы. При этом в ряде случаев искажения в данные вносят умышленно — это делают с различными целями поставщики продукции и их партнеры. По признанию Кроткова, раньше в «Яндекс.Маркете» пытались «максимально эффективно тушить пожары». После внедрения решения Ataccama в компании появились дата-стюарды, настраивающие логику автоматического контроля качества данных.

***

Как отметили многие участники форума, до недавнего времени акцент делался исключительно на технологиях сбора и анализа данных, а управление ими отходило на второй план. И до сих пор компании часто не знают, кого нанимать на позиции, связанные с управлением данными, ведь эта функция у многих только создается. Более того, руководители и специалисты — от CDO до аналитиков — имеют субъективные представления о целях управления данными, часто оно сводится лишь к быстрой окупаемости проектов.

Пандемия коронавируса дала сильный импульс развитию медицинских информационных технологий, и проблема доступа к большим медицинским данным получила шанс сдвинуться с мертвой точки. Состояние отечественного рынка данных здравоохранения, отраслевые кейсы применения аналитики и технологий искусственного интеллекта, а также ситуацию с доступом к медицинским данным и нормативным регулированием повторного использования обезличенных данных для машинного обучения эксперты обсудили на форуме BIG DATA 2021, проведенном издательством «Открытые системы». Кульминацией тематической сессии стал круглый стол «Качественные медицинские данные для ИИ-решений: где их взять?», организованный при поддержке Ассоциации «Национальная база медицинских знаний».

Сырьевая база

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

В числе самых многообещающих областей применения искусственного интеллекта в здравоохранении — предсказательная аналитика, включающая решения по прогнозированию возникновения эпидемий, нехватки лекарств и нежелательных событий в организме конкретного пациента. «Мы научились использовать большие данные для сокращения неэффективных затрат на оказание медицинской помощи», — сообщил директор по развитию проекта Webiomed Александр Гусев, представляя участникам BIG DATA 2021 обзор рынка искусственного интеллекта для здравоохранения. По его мнению, два главных вызова для этого рынка в России — особый правовой статус стартапов в сфере больших данных и искусственного интеллекта, а также развитие национальной платформы, которая позволит собирать медицинские данные, предоставлять доступ к ним доверенным компаниям и осуществлять государственный надзор в этой чувствительной сфере. Планы создания такой отраслевой федеральной платформы искусственного интеллекта, основой которой станет защищенный банк обезличенных медицинских данных, были недавно анонсированы Минздравом. Разработчики рассчитывают, что в процессе реализации этого проекта основные проблемы, связанные с использованием больших данных в медицине, будут решены.

К 2020 году медицинские информационные системы внедрили 82% медицинских организаций России. И хотя 80% информации в электронных медкартах хранится в неструктурированном виде, с ней вполне можно работать с помощью технологий обработки текста на естественном языке (Natural Language Processing, NLP). По мнению Гусева, основные сложности на пути развития российского рынка «умных» решений для медицины создает неурегулированный оборот обезличенных медицинских данных и отсутствие понятной схемы возврата инвестиций в это рискованное направление.

Закон на подходе

Между двумя нежизнеспособными крайностями «данные должны быть доступны всем» и «данные не должны быть доступны никому» лежат компромиссные варианты порядка обращения обезличенных данных, пока еще не оформленные юридически. Медицинские данные выделены в специальную категорию особо чувствительных данных и не могут обрабатываться без согласия субъекта даже в обезличенном виде. Как сообщила Александра Орехович, директор по правовым инициативам ФРИИ, поправки, предусмотренные законопроектом об обезличенных персональных данных, который сейчас готовится ко второму чтению, дают надежду, что вопрос доступа к данным с целью разработки систем искусственного интеллекта вскоре будет урегулирован. Доступ будет предоставляться в определенном порядке определенным категориям организаций, которые соответствуют определенным требованиям. Но никакой конкретики в отношении этого порядка, категорий и требований пока нет — ясность появится только вместе с подзаконными актами. Когда будут выпущены проекты документов с правилами обезличивания данных и правилами доступа к ним, тогда и развернется по-настоящему острая дискуссия на эту тему.

Сегодня, когда одновременно идут процессы усиления защиты данных и полной открытости цифрового следа, настало время поднять вопрос о донации данных, полагает Борис Зингерман, гендиректор ассоциации «Национальная база медицинских знаний». «Сделать донацию данных легче, чем донацию крови, а пользы от нее тоже можно получить немало, — подчеркнул он. — Я с удовольствием поделюсь своими данными для науки, и таких пациентов будет немало».

Три диагноза от искусственного интеллекта

Интересный пример полезного использования данных о первичных приемах пациентов, накопленных в столичной системе здравоохранения, привела первый заместитель начальника Управления заместителя мэра Москвы по вопросам социального развития Юлия Урожаева. Она рассказала о системе поддержки принятия врачебных решений на основе искусственного интеллекта, которая с октября прошлого года работает во всех взрослых поликлиниках города. Для обучения нейросети, которая была разработана и откалибрована при помощи специалистов лаборатории искусственного интеллекта Сбера, использовали уникальную методологию разметки данных, сообщила Урожаева. Около 95% случаев обращения в поликлинику связано с одним из 265 диагнозов. На них и сосредоточились разработчики.

Проанализировав анамнез и введенные врачом жалобы пациента, система подсказывает три наиболее вероятных предварительных диагноза, а затем подбирает стандартные пакеты инструментальных и лабораторных исследований для подтверждения диагноза или его опровержения. К настоящему времени с помощью системы проведено около 4 млн амбулаторных приемов, и в 70% случаев выбор врача совпадает с предложением нейросети. Систему продолжают дорабатывать и обучать, пополняя новыми данными и диагнозами и повышая точность ее работы.

Свое выступление Урожаева завершила приглашением к сотрудничеству. «Очень ждем нестандартно мыслящих людей для разработки следующих продуктов», — обратилась она к участникам форума.

Видеть цель

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

«При использовании публичных датасетов, которые непонятно как собраны, приходится проводить процедуру кросс-разметки данных нашими врачами», — подтвердил операционный директор компании «Цельс» Никита Николаев. По его словам, качественных медицинских данных на сегодняшний день мало. Однако если качественно отстраивать процедуры разметки данных, можно повысить и точность решений, построенных на их основе. Николаев поделился опытом по оптимизации затрат на разметку медицинских изображений с помощью псевдо- и кросс-разметки, а также результатами эксперимента по привлечению к процедуре разметки маммограм силами сообщества «Яндекс.Толока». Эксперимент показал, что люди, размечающие снимки для обучения ИИ, находили рак не менее точно, чем врачи.

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

«Российское здравоохранение находится в двух шагах от того, чтобы перейти к медицинской аналитике на основе первичных данных, — полагает Игорь Башков, коммерческий директор «Нетрика Медицина». — В 2020 году COVID всех к этому подстегнул».

Так, многие регионы организовали автоматическое формирование регистров заболевших коронавирусом и оперативную передачу первичных данных о заболевших на федеральный уровень в структурированном виде. Это лишь одна из множества задач, которые «Нетрика Медицина» помогает решать региональным управленцам, интегрируя данные из 70 медицинских информационных систем различных организаций.

На распутье: NLP или cтруктурированная галлюцинация?

Структурированные или неструктурированные данные — важная развилка на пути дальнейшей цифровизации российского здравоохранения. Как отметил Павел Пугачев, заместитель министра здравоохранения РФ, идти по пути структурированных электронных медицинских документов (СЭМДов), добиваясь перехода всех медицинских организаций на единый формат — правильно, но долго, хотя этот подход прекрасно себя показал в ряде регионов, где интероперабельность и обмен данными с федеральным сегментом Единой государственной информационной системы здравоохранения обеспечивается с помощью СЭМДов. «Мы будем двигаться по этому пути, но нельзя отбрасывать и неструктурированные данные», — подчеркнул он. По мнению Пугачева, сегодня недостаточно проектов, которые работают с неструктурированными текстами и результатами анализов, между тем это направление может стать прорывным. В нем следует создавать заделы и реализовывать сервисы для медработников.

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

Гусев поделился историей, когда по настоянию заказчика разработчики сделали форму врачебного осмотра, включавшую почти тысячу полей. Заполнение данных осмотра одного пациента стационара занимало 40 минут. Неудивительно, что врачи сразу переходили в конец формы, меняя лишь несколько полей и оставляя остальные шаблонными. «В итоге на выходе получилась очень качественно подготовленная и прекрасно машино-обрабатываемая… галлюцинация», — констатировал Гусев. Эксперимент подтвердил, что абсолютная формализация в реальной медицинской практике невозможна, и имеет право на жизнь разве что в клинических исследованиях. А в клинической практике более применим подход, сочетающий заполнение текстом крупных блоков структурированных документов, и последующее извлечение информации из них с помощью NLP-технологий.

Чем сложнее экранная форма, тем менее достоверны данные, ее заполняющие, согласен Пугачев. Он, в свою очередь, привел пример неудачной попытки наполнить регистр больных ковидом подробнейшими данными о хронических заболеваниях, в результате которой получили множество пациентов, у которых вообще отсутствовали хронические заболевания. Лишь когда в регистре оставили только группы хронических заболеваний, качество его данных существенно повысилось. Для повышения качества данных также важно использовать данные, поступающие с анализаторов, носимых устройств и предоставляемые самими пациентами. К примеру, при вакцинации заполняемость дневников наблюдения на портале госуслуг оказалась существенно выше ожидаемой, а этот формат дает возможность не только собрать дополнительные сведения, но и разгрузить врачей при сборе анамнеза.

«Нам нужен спрос на датасеты для создания сервисов на основе искусственного интеллекта, чтобы иметь возможность внутренней приоритизации, выстраивания процессов разметки, создания эталонных датасетов и их предоставления вовне, — заявил Пугачев. — Мы хотим поддерживать именно российских разработчиков и готовы выстраивать с ними коммуникации». Удачный опыт НПЦ «Радиология Москвы» по тестированию ИИ-решений, по его мнению, нужно расширять, и не только на анализ медицинских изображений.

Самое важное и самое сложное звено системы управления данными — люди. В ходе практической конференции «Качество данных — 2021. Стратегия, инструменты, практика», организованной издательством «Открытые системы», очень многие эксперты фокусировались вовсе не на технологиях. По их мнению, в вопросах управления данными и обеспечения их качества гораздо важнее методология, правильно выстроенные процессы и отношения с людьми, причем на всех уровнях корпоративной иерархии. (О конференции см. также "Качество данных: советы бывалых".)

Сизифов труд для марафонцев

«Качество данных — это не только формальные процедуры проверки того, насколько они удовлетворяют заданным критериям. Это в большой степени и вопрос культуры организации, выстраивания процессов, дающих необходимый результат», — подчеркнул Михаил Петров, директор департамента цифровой трансформации Счетной палаты РФ.

Исторически в обязанности Счетной палаты не входили аналитика и работа с данными, этот орган выполнял контрольные функции. Сейчас происходит движение в сторону аналитической работы с данными, в том числе профилактики и системного анализа проблем. Переход к цифровому формату работы требует совсем другой культуры — необходимо менять мышление с «карательного» на аналитическое.

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

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

«Термин 'качество данных' олицетворяет боль любой крупной организации: данных становится все больше, компании старательно собирают их, но чистить данные — сизифов труд, — признала Светлана Бова, директор по управлению данными ВТБ. — Можно достичь сколь угодно больших успехов, но с каждой новой порцией данных, с каждым структурным изменением все начинается заново».

Тем не менее без цикличного процесса контроля качества данных состояние «цифрового здоровья» организации будет ухудшаться. Команда, которая занимается качеством данных, сродни марафонцам: только у них достаточно воли и терпения для выполнения повторяющихся рутинных действий. Такая работа не всегда благодарная, поэтому, чтобы ею заниматься, необходимы высокая степень мотивации и понимание ценности данных для организации. Это достаточно сложный профиль при подборе персонала.

Управления данными не существует без бизнеса

«Люди — значимая история в нашей системе координат по управлению данными. Именно они выполняют процессы и корректируют их, используют внедренные инструменты в своей работе», — отметила Любовь Кайдалова, руководитель направления по качеству данных компании «Газпром нефть».

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

«Обязательно вовлекайте бизнес-подразделения в работу с данными, потому что не существует управления данными без бизнеса», — порекомендовала Кайдалова.

Александр Афонин, директор департамента развития платформы по управлению качеством данных X5 Retail Group, рассказал о том, как важно правильно позиционировать роль подразделения Data Quality. «Мы не собираемся становиться клининговой службой, прибирая за бизнесом и исправляя некачественные данные», — заявил он. Верный подход — выстроить вместе с бизнесом правильные процессы, чтобы не допускать повторения ошибок в дальнейшем, а затем совместными усилиями устранить их. При этом ответственность за качество данных несет бизнес, а специалисты по качеству данных вынуждены иногда быть «плохими полицейскими», попутно объясняя и бизнесу, и ИТ, как нужно работать, чтобы качество данных повышалось.

Качество — забота каждого

Когда компании задумываются о рациональном управлении — то есть о принятии решений на основании данных, а не чьих-то субъективных мнений и эмоций, они осознают необходимость обеспечить отчетность. Как отметил Сергей Горшков, директор компании «ТриниДата», желание получать информацию для решения всех прикладных задач быстро приводит к тому, что отчетности становится очень много. Работа с ней занимает значительное время, а вот извлечь пользу из нее удается не всегда. Помимо выявления данных низкого качества, необходимо фиксировать методики расчета каждого показателя, но в компаниях не сразу приходят к пониманию важности решения этой задачи.

«Чтобы правильно работали процессы управления данными, должна быть выстроена мощная структура из методологических подходов», — уверен Олег Гиацинтов, технический директор компании DIS Group. Обеспечить возможность каждому пользователю легко воспользоваться данными — очень непросто. И правильные процессы здесь гораздо важнее, чем внедряемые для их реализации ИТ-решения.

При этом важно определить тех, кто отвечает за данные. «Вероятно, все думают, что их будут бить, поэтому отчаянно сопротивляются. Хотя на самом деле должно быть наоборот: они сами должны выдвигать требования к данным и наказывать нарушителей», — считает Гиацинтов. В любом случае бизнес может гораздо быстрее и лучше обеспечить качество своих данных. И самое главное — когда бизнес-пользователь хочет сделать что-то быстро, нужно дать ему возможность сделать это самостоятельно. Пользователи, желающие заказать данные, должны получить их быстро и автоматически, причем с качеством, которому будут доверять.

Анна Серебряникова, президент Ассоциации больших данных, рассказала о выстраивании работы с данными за рамками закрытого контура. По ее словам, 70% данных, интересных компаниям с коммерческой точки зрения, так или иначе связаны с персональными данными. Работать с такой информацией очень сложно с законодательной точки зрения, и это не позволяет ни развивать кросс-отраслевые проекты, ни обогащать данные, ни обучать качественные модели. Поэтому в Ассоциации сейчас активно занимаются проблемой работы с обезличенными данными.

Алексей Ильин: «Управление качеством данных должно стать в буквальном смысле задачей каждого сотрудника»

По словам Алексея Ильина, генерального директора российского офиса компании Ataccama, много проектов data governance приходят к тому состоянию, когда система внедрена и «лампочки мигают», но люди с ней не работают. Это проблема: нужно менять процессы, чтобы люди пользовались решением; задача управления качеством данных должна стать массовой. Каждый должен стараться улучшать их или хотя бы не ухудшать.

Надо стремиться к тому, чтобы все пользовались внедряемыми инструментами управления данными. Однако для этого важно дать пользователям удобный инструмент для работы с качеством в реальном времени, причем «оторвать» его от ИТ, предоставить возможность самообслуживания. Платформа должна помогать пользователям решать рутинные задачи — например, самостоятельно выявлять аномалии в данных, автоматически их идентифицировать и предлагать проверки по ним.

Самая большая проблема в проектах data governance — управление изменениями, в том числе культурными. Мало кому удается поменять культуру в организации настолько, чтобы качество данных стало задачей каждого.

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

Выступая на конференции «Качество данных 2020», которую провело издательство «Открытые системы», генеральный директор компании Mechanica AI Александр Хайтин мастерски добавил «Ложку дегтя в озеро данных». Так он назвал свой доклад, в котором поделился опытом выполнения проекта для предприятия черной металлургии — весьма полезным для тех, кто работает с машиногенерируемыми данными.

Озеро или отстойник?

Прямой связи между ростом объемов данных и принятием лучших управленческих решений нет. Сами по себе данные — это источник затрат на их сбор, хранение, обработку. И очистку! «В реальной жизни data lake больше похоже не на альпийское озеро меж сосен, а на отстойник жидких отходов: подойти страшно, но теоретически полезная вещь», — пошутил Хайтин.

Чтобы превратить данные в бизнес-актив, к ним применяют технологии искусственного интеллекта и другие методы. По сути в Mechanica AI занимаются переработкой вторсырья, превращая его в три полезные вещи: в виртуальные сенсоры, применяемые там, где слишком долго или дорого измерять что-либо физическими сенсорами; в предсказания, позволяющие улучшить управление объектами за счет предотвращения проблем, и, наконец, в прямую оптимизацию и экономию.

Но чтобы получить результат, приходится отделять ценное вторичное сырье, которое можно переработать, от токсичных отходов.

Кунсткамера проблем

Подготовка данных занимает до 80% времени работы с ними, при этом накоплению исторических данных, необходимых для построения модели, часто не уделяется должного внимания.

«Мы по определению с самого начала работаем с мусором и собрали целую коллекцию проблем с данными», — сообщил Хайтин. Пропуски, в том числе из-за поломок сенсоров и сбоев архивирования, а также явные ошибки — самые дешевые из них, так как их легко обнаружить и от них легко избавиться. Главное условие для этого — большой объем данных и не очень большая доля пропусков и ошибок, чтобы не уничтожить весь датасет.

К категории дорогих и очень дорогих проблем он отнес так называемую эзотерическую схему данных — несколько тысяч полей с именами в виде сокращений, аббревиатур и индексов. Также дорого обходится бизнесу неаккуратное агрегирование с усредненными по времени показателями, сделанное в расчете на то, что эта информация уже никому не понадобится. «Данные за много лет, превращенные в бесполезные агрегаты, — это необратимые потери: фарш обратно в мясо уже не превратишь», — отметил Хайтин.

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

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

Традиционно накопление данных ведется в компаниях по функциональным подразделениям, и в результате «озера данных» на практике часто оказываются фрагментированными. «В этой ситуации достаточно того, чтобы одно подразделение не передало свои данные в озеро, — и тогда ценность всех накопленных в нем данных резко упадет. Не на полпроцента, соответственно объему непоступивших данных, а на все 90%», — подчеркнул Хайтин.

Но проблема-рекордсмен в практике Mechanica AI — сбитые отметки времени в разных информационных системах внутри организации. Причем в некоторых случаях — с плавающей разницей между часами. Для оператора, управляющего физическим процессом в реальном времени, эта разница не имеет значения, так как он собственными глазами одновременно видит показания приборов. А вот сопоставить исторические данные разных систем и использовать их — в этом случае уже нельзя. Чтобы спасти ситуацию, приходится строить интеллектуальные программные решения, что обходится гораздо дороже, чем время системного администратора на настройку часов.

Для предотвращения подобных проблем рекомендуется крайне аккуратно относиться к процессу накопления исторических данных. «Не надо выкидывать сырье, хуже всего бороться потом с алгоритмами агрегации и очистки», — предостерег Хайтин. Он также советует протестировать собранные данные на целостность, построив учебную модель. А также не забывать притчу: «Если лошадь сдохла, слезь с нее, а не пытайся ее оживить». Иногда не стоит «городить огород» интеллектуальных решений, а надо просто смириться с потерей данных.