Мероприятие OCS и DIS Group, российской IT-компании, которая предлагает решения в области управления данными, бизнес-аналитики, защиты информации, а также осуществляет консалтинг и внедрение проектов по данным направлениям. В рамках мероприятия будет проведён обзор основных сценариев использования, возможностей инструмента с точки зрения пользователей и администраторов решения.
Спикер: Александр Работаев, технический менеджер, DIS Group.
Сегодня мы поговорим про кооперативное управление данными, про решения, которые мы предлагаем в этой части. Наша компания представлена на рынке уже давно, 18 лет мы на рынке. Мы занимаемся управлением данными как в части проектов, так и в части ПО.
Мы долго работали с ПО компании Информатика. А сейчас мы переключились на российские решения, мы предлагаем решения Data Инновации, Юниверс Дата и ДАТАФЛОТ. Большое количество проектов мы выполнили самостоятельно, большое количество проектов - с партнерами. Компания у нас очень пестрая, из разных секторов рынка. Это и финансовые организации, и телеком, и ретейл, и промышленные компании, в том числе нефтегазовые. Мы беремся за любые проекты в части управления данными и интеграции данных, решения по управлению мастер данными. Мы эти решения реализуем на платформе, которую предлагаем, т.е. это основные компоненты, которые отвечают за управление данными. Это, повторю, интеграция данных, решения по обеспечению качества данных, решения по работе с мастер-данными и решения по управлению данными, это бизнес-глоссарий и каталог данных.
Почему управление данными стало в последнее время такой модной и популярной темой? Потому что сейчас у заказчиков появилось большое количество самых разных программ, направлений для решения разных задач.
Управление данными – стратегическая задача организаций: современное обеспечение пользователей данными, данные должны быть доступными, защищенными и достоверными, пользователи на должны сами их искать или оценивать качество данных.
Стек обычно у крупных заказчиков включает несколько единиц, десятков, а то и сотен различных систем, которые содержат разные данные. И этими данными хорошо бы воспользоваться не только внутри этой системы. Данных много, и со временем становится все сложнее понять, где какие данные находятся. Т.е. нет единой системы, которая, во-первых, позволяла бы найти необходимую информацию, а, во-вторых, все большее количество людей пользуются этими данными, многие BI-инструменты, какие-то другие приложения предлагают работу в режиме сервиса, и человеку, незнакомому с конкретной системой, сложно разобраться, где находится тот или иной набор данных, кто за него отвечает, как получить доступ, какое там качество данных, откуда они берутся.
И для решения всех этих задач используется инструмент управления данными. Они позволяют быстро и удобно либо предоставить пользователям информацию, это зависит от проектного подхода, как в организации принята работа с данными, это либо специальное подразделение, которые по запросу пользователя может предоставлять нужную информацию. У них есть инструмент, они умеют им пользоваться, быстро ищут необходимые наборы и пользователю предоставляют информацию. Либо это может быть самостоятельная работа пользователя с этим инструментом, т.к. он позволяет легко и просто искать необходимую информацию с точки зрения бизнес составляющей. Человек может просто сказать: "Я хочу понять, что такое наши доходы, и где они находятся". Этот инструмент позволяет системе понять, что такое доход, или выручка, или прибыль, и в каких системах эта информация находится. Какие отчеты с этими терминами связаны, каким образом все это формируется. При этом инструмент управления данными позволяет избежать необходимости в том, чтобы пользователи сами «ходили» в какие-то системы источники, искали, где находится та или иная информация, пытались получать доступ к ней.
Это ускоряет решение рутинных задач. У нас были примеры, когда заказчики при внедрении инструмента управления данными проводили следующий эксперимент. Два человека решают одну и ту же задачу с нашим инструментом и без его применения, классическим, прежним способом. Выигрыш во времени получался в десятки раз. если стандартный аналитик входит во все системы, ищет какие-то наборы данных, ему, возможно, приходится при этом получить доступ, оценить качество. На это обычно требуется много времени, вплоть до недели. Если же мы используем инструмент управления данными, то время сокращается до нескольких часов. Т.е. выигрыш во времени очевиден, и к тому же при этом можно получить дополнительную информацию о качестве данных. Т.о. этот инструментарий стал популярным и модным в последнее время.
На следующем слайде показаны ключевые элементы Data Governance.
Если говорить про сами элементы управления данными, то здесь, если говорить про проекты, про внедрение у заказчика, то просто инструментом, к сожалению, не обойтись. Платформ, которые позволяют найти необходимые данные и каким-то образом внедрить практику управления, недостаточно. Должен быть использован определенный подход, должны быть внедрены соответствующие бизнес-процессы, потребуются скорее всего какие-то изменения в организационной структуре. Все это тоже является важными элементами в управлении данными.
Должны быть выстроены соответствующие процессы, должны быть внесены, пусть не глобальные, небольшие изменения в организационную структуру. Хотя в больших организациях обычно для этого создаются специальные подразделения, которые отвечают за управление данными, есть Chief Data Officer (CDO), есть data-стюарды. Но как минимум, должны быть выделенные роли в смежных подразделениях с тем, чтобы управлять такими процессами. Хочу подчеркнуть, что просто купить коробку и пользоваться - не получится. Всегда требуется какое-то предварительное обследование, небольшой проект с вашей, либо с нашей помощью, который позволит выстроить необходимые процессы, ввести необходимые изменения в организационную структуру, проработать методологические подходы.
Поговорим про ключевые элементы. На слайде приведена глобальная организационная структура для большой компании, когда есть комитет по управлению данными, есть корпоративный владелец данными, есть функциональные владельцы данных. В этот же комитет входит Chief Data Officer. Есть стратегия по управлению данными, политики, стандарты. Все это важно. Хотя в небольших организациях, возможно, избыточно. Но это правильный подход, когда даже создаются контракты на качество данных. Например, когда одно подразделение предоставляет данные другому, то это не просто из одной системы в другую систему просто перелили их, они также подписывают документ о том, каким должно быть качество данных, не менее определенного процента. И такие истории встречаются в разных организациях. Важно, что бизнес подразделения уверены в том, что им предоставляются корректные и качественные данные на регулярной основе.
В комитете по управлению данными есть роль Chief Data Officer, у него обычно в подчинении отдел по управлению данными. В него могут входить архитекторы данных, которые отвечают за разработку слоев данных, интеграционных потоков, стюарты данных, которые отвечают за описание бизнес глоссариев, аналитики, которые могут находиться в функциональных подразделениях или в службе ИТ, и специалист по качеству. Это не обязательно должно быть отдельное подразделение. И все эти роли решают свои конкретные задачи по описанию наборов данных для того, чтобы другие пользователи могли быстро найти им необходимые данные, по ведению реестра проверок качества, чтобы показывать, что данные не просто лежат в этой системе, но они могут быть уверены в том, что они актуальны и достоверны.
Подразделения, которые являются пользователями этой системы и этих процессов, могут пользоваться ею по-разному. Бывает так, что система используется всей организацией, когда пользователь из любого департамента может зайти и самостоятельно искать какой-то показатель. Но такое встречается не часто. Чаще пользователь включается в стандартную заявочную систему.
Он пишет, например, такой запрос: "Я хочу найти набор данных, который соответствует моим бизнес ожиданиям." Этот запрос попадает в подразделение по управлению данными. Там есть пользователь, который умеет работать с инструментами, и он на основе той информации, которая была в заявке, формирует ответ. Это стандартный подход в крупных организациях. Потому что обычно бизнес пользователям некогда изучать новую систему, им проще поставить задачу специалисту, и получить квалифицированный ответ.
На этом слайде пример этого процесса. Бизнес пользователь пишет какой-то запрос в привычной для себя системе управления заявками. Этот запрос попадает к стюарду данных, который уже работает с инструментом управления данными, он обрабатывает запрос, ищет необходимые термины. Если ему не удается их найти, он обращается к экспертам по данным, чтобы собрать пояснения. Архитектор данных должен актуализировать модель в рамках этого запроса бизнес пользователя. При необходимости могут применяться бизнес-глоссарии, если недостаточно той информации, которая была. Или переходит сразу к аналитику данных, который на основе связей между бизнес-глоссарием и данными в системах найдет нужные атрибуты, проверит их качество. Могут вовлекаться офицер по качеству данных. Но это условное разделение. В принципе все это может делать один человек, который отвечает за все эти процессы.
При необходимости, если этот запрос изначально бизнес-пользователя подразумевает, что новый показатель необходимо внести для изменения структуры витрины, то привлекается архитектор данных, который создает соответствующие таблицы. После этого аналитик создает ТЗ на реализацию, разработчик реализовывает. После этого аналитик проверяет, все ли реализовано, а стюард данных предоставляет отчет о выполнении запроса. И бизнес-пользователю приходит информация о том, что, например, новый показатель добавлен в отчет. Это сложный процесс.
Проще, когда бизнес пользователь послал какой-то запрос, например: "Как считается такой-то показатель?" Тогда стюард данных идет в инструмент управления, находит информацию и предоставляет информацию по этому запросу. В этом случае бизнес пользователь может и сам воспользоваться инструментом и найти необходимую информацию. Т.е. это процесс с точки зрения добавления новых функций, новых терминов или пересчета показателей, это процесс по работе с данными.
Мы поговорили про организационную структуру, про методологию инструмента. Теперь поговорим про возможности самого инструмента Юниверс DG. Это классический инструмент по управлению данными, который включает в себя бизнес-глоссарий. Это описание различных терминов, отчетов, показателей эффективности, организационных структур, политик, процессов и прочее. Он не ограничен какими-то определенными объектами. В зависимости от задач заказчика, это могут быть разные объекты. Бизнес-глоссарии - это концептуально разные уровни, когда мы описываем понятия, которые использует организация, и как эти понятия связаны друг с другом. Все это позволяет в рамках инструмента выстраивать связи между различными понятиями. Например, у нас есть понятие "клиент", есть представление о том, как он связан с договором, что такое договор. В разных организациях бывают разные определения понятия "клиент" даже в рамках разных департаментов. Например, у нас был проект в Сбере, там было 46 определений "клиента" в разных департаментах. Кто-то считает потенциальных клиентов, кто-то что это тот клиент, у которого есть договор. Вся эта терминология сводится воедино, и за счет этого появляется понимание о том, где находятся какие объекты.
Следующее, что позволяет делать инструмент, это описание логических объектов, наборов данных. Клиент, например, взял кредит. Он описывается такими атрибутами. А клиент в телекоме описывается другими атрибутами. Все это можно настраивать и моделировать в том виде, какой нужен заказчику. Связка бизнес-глоссария с логическими структурами. Также инструмент позволяет подключаться к физическим базам данных, физическим приложениям на уровне таблиц, атрибутов, считывать мета-данные, которые есть в реальных системах. Для этого есть специальные сканеры, которые могут читать мета-данные и их каталогизировать. Это два больших концептуальных блока: бизнес-глоссарий, где мы ведем всякие описания, логическую модель и каталог данных, который отвечает за сбор информации с реальных таблиц, реальных витрин и их каталогизацию. На основе собранных данных выстраиваются связи. Например, в какой таблице находится информация о клиентах. Пользователь может разными способами работать с инструментом. Он может найти понятие "клиент". Скажем, понятие "клиент" входит в такую-то и такую-то систему, используется в таких-то таблицах. Это позволяет сразу понять, если ему нужно собрать новую витрину, где находится клиент, если он до этого это не знал. И в обратную сторону, системный аналитик может найти таблицу в базе данных или в приложении, и увидеть, что в этой таблице находится информация о клиенте. Это работает в обе стороны, для разных ролей.
Сам инструмент включает в себя возможность выстраивать процесс согласований. Кроме платформы, должны быть выстроены соответствующие процессы. В проектах управления данными сама концепция управления данными, процессы согласования играют важную роль. Потому что с концептуальной точки зрения будет неправильно, если любой пользователь будет иметь возможность вносить любые изменения. Любые изменения должны быть согласованы всеми заинтересованными лицами. И для этого есть возможность выстраивания по настройке в инструменте бизнес-процессов. Все это делается через специальный конструктор. Это легко настраивается. Все делается через интерфейс настройки. Есть возможность добавлять собственные модули и программировать. Но большую часть задач всегда можно решить стандартными способами.
Есть возможность визуализации проверок качества данных их профилирования. Над всем этим есть ролевая модель, статусная модель, есть возможности работать с подписками. Это полноценный инструмент, который закрывает все задачи управления данными с точки зрения платформ. Выстраивание бизнес-глоссария, выстраивание связей между различными уровнями, проверки качества ведения реестров – все это инструмент закрывает практически в едином окне.
Основным преимуществом является сокращение time to market, то есть уменьшение времени на решение рутинных задач по поиску где какие данные находятся, какое у них качество, как они связаны.
Кроме того, происходит рост доверия к данным, например, кроме написанных отчетов можно посмотреть метрики качества, сразу увидеть какие проверки проводились. Плюс возможности по расследованию различных инцидентов, когда выстроены связи между системами и если по какой-то причине какой-то отчет вызывает сомнения, можно сразу понять из каких данных он брался, какие системы являются источниками этого отчета, можно пойти на карточки этих систем и проверить результаты проверок качества, может сегодня там был какой-то сбой, можно сразу увидеть ответственного и владельца этих систем, к нему обратиться и понять что в результате произошло.