Тема управления данными становится все более популярной, количество CDO в компаниях стремительно растет. Тем не менее, внедрение в любой компании работы с данными – это долгий и весьма тернистый путь. В X5 Retail прошли его чуть дальше многих, и не случайно были удостоены премии CDO Award 2020.

Выступая в «Клубе CDO», организованном Newprolab, Тигран Саркисов, директор по работе с данными Х5 Retail Group, поделился опытом, который может быть полезен компаниям, делающим первые шаги в выстраивании процессов работы с данными. Первая часть охватила лучшие практики и типовые ошибки внедрения института CDO, а вторая была посвящена работе по Data Governance и практическим советам, которые удалось выработать в X5.

Ожидания и подходы

Можно привести несколько типовых проблем при внедрении подходов Data Governance и на их основе попытаться сформировать лучшие практики в этой области. Первая из них связана с неправильными ожиданиями.

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

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

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

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

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

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

Команда и культура

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

Отсутствие хотя бы одной из этих ролей приводит к проблемам.

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

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

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

Итак, существует четыре типовых лучших практики: управление ожиданиями от CDO, подход к внедрению CDO, состав верхнеуровневой команды и культура сотрудничества.

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

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

Отдельный вопрос касается показателей эффективности, которыми должна поддерживаться работа CDO и владельцев данных (data owner). Если говорить о глобальном CDO, помогающем бизнесу получать выгоду из данных (тот самый «бизнесмен»), то ему специфические KPI не нужны: его главный показатель – бизнес-результат. Если говорить про Data Governance и возникающие при этом роли, такие как владельцы данных, то у них есть цели, и основная из них – удовлетворенность пользователей бизнес-функции работой с данными.

Как измерять успехи

С какими граблями приходилось сталкиваться на пути выстраивания работы с данными?

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

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

Исходя из этого в X5 была выстроена дальнейшая структура Data Governance: отдельные направления, занимающиеся качеством данных, методологией данных (отвечающие за «понятность») и архитектурой данных (отвечающие за доступность). Все вместе они работают на повышение зрелости работы с данными.

Метрики для измерения успехов в Data Governance описаны в «Своде знаний по управлению данными» (DMBOK), часть из них X5 адаптировали под себя.

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

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

Практические советы

По каждому из упомянутых направлений Саркисов дал несколько советов.

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

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

Измерять качество данных лучше как по сценариям использования («юзкейсам») – например, в ценообразовании или по управленческой отчетности, так и по доменам. В разных сценариях качество данных может серьезно отличаться.

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

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

Необходимо создавать службу поддержки по работе с данными (Data Help Desk). Наверняка в компании есть системы ITSM и службы поддержки, которые работают с пользователями. Практика X5 и многочисленный опыт других компаний показывают, что службы поддержки должны охватывать и вопросы работы с данными. У многих людей в больших компаниях нет понимания, к кому можно обратиться в случае проблем со знаниями о корпоративных данных. Между тем, для этой цели достаточно одного человека, который может решать массу проблем. Этот сервис очевидно полезен и вызывает позитивные отзывы от пользователей.

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

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

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

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