Читать «Данные решают. Как управлять данными, чтобы создавать ценность для бизнеса» онлайн

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

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

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

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

• Следить за «законодательством»: отслеживать изменения в законах и нормативах, чтобы правила работы с данными всегда оставались актуальными.

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

«Я — НЕ Я, И ЛОШАДЬ НЕ МОЯ!»: КАК ПРЕОДОЛЕТЬ СТРАХ ОТВЕТСТВЕННОСТИ

Панический страх перед новым и неизведанным «бременем ответственности» можно назвать синдромом чужой лошади. Представьте ситуацию: новоиспеченный CDO, полный энтузиазма, начинает обход потенциальных «владельцев» — руководителей ключевых подразделений. Его цель — закрепить за ними ответственность за данные. А в ответ он слышит вежливое, но твердое: «Это не моя зона ответственности!» Такой страх рождается не из-за слабости или недальновидности менеджеров. Его источник — абсолютная новизна самой парадигмы управления данными для большинства сотрудников. В их головах звучат закономерные вопросы: «Что мне будет, если я соглашусь?», «Почему именно я должен отвечать за эти данные, а не мой коллега?» Управление данными — молодая дисциплина для российского бизнеса, она еще не стала частью кровотока корпоративной культуры. А все новое и непонятное, особенно подкрепленное словом «ответственность», закономерно вызывает психологическое сопротивление.

Что же делать CDO, когда он сталкивается с этой стеной? Решение лежит на поверхности, но требует системной работы.

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

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

БАНК — НЕ АВИАКОМПАНИЯ! ПОЧЕМУ ОТРАСЛЕВОЙ ОПЫТ РЕШАЕТ ВСЕ

Один зарубежный банк искал кандидата на позицию CDO. Руководство ответственно подошло к требованиям и четко сформулировало основные цели и KPI: привести ландшафт бизнес-процессов и ИТ-систем в соответствии с требованиями BCBS 239[16] и GDPR в части управления данными, оптимизировать стоимость владения хранилищем данных и внедрить культуру управления данными.

Рынок кандидатов с релевантным опытом в стране присутствия банка был не так велик. Рассматривались специалисты как с техническим бэкграундом, так и из бизнес-направлений. HR вел поиск не только в банковской среде, но и в других отраслях, не отказываясь от претендентов, имеющих дата-специализацию, и используя для отбора такие модные слова, как Big Data / DWH / BI / Data Lake, а также оценивая опыт руководства людьми.

Выбор пал на управленца-технаря с 20-летним опытом работы в различных авиакомпаниях на позиции CIO. На собеседовании кандидат уверенно перечислил ключевые домены данных, апеллируя к международным стандартам референтной модели BIAN[17]: «Клиент», «Сделка», «Финансовый актив». Но на вопрос «А кто в банке должен владеть данными о клиенте?» последовал мгновенный ответ, основанный на авиационном опыте: «Конечно дирекция по продажам! У нас все просто: продажи отвечают за клиентов и билеты, а дирекция авиапарка — за самолеты и запчасти».

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

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

КУРИЦА ИЛИ ЯЙЦО? ЧТО ПЕРВИЧНО: ДАННЫЕ, ПРОЦЕССЫ ИЛИ СИСТЕМЫ?

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

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

И в первом (владение данными от процессов), и во втором (владение данными от систем) подходах дополнительным подспорьем для поиска и назначения ответственных за данные становится внутренняя нормативная база, которая регламентирует цели, функции и задачи каждого подразделения организации. Если возникают спорные вопросы или недопонимание границ ответственности, она помогает расставить точки над i.

Однако стоит отметить, что в некоторых компаниях функции использования данных превалируют над принципом «перворождения», и, например, в телеком-операторах данные о трафике сигналов физически производит техническое подразделение, тогда как требования к этим данным — как хранить, в каких разрезах проводить аналитику, с