Какую дорожную карту можно рекомендовать для гармоничного встраивания инструментов и процессов качества данных в бизнес-процессы, чтобы, реализовав подход Data Quality by Design, получить ощутимые выгоды для организации ― как краткосрочные, так и долгосрочные? В каких документах организации следует эту дорожную карту описать и отразить? И что нужно, чтобы не просто встроить управление качеством данных в процессы, а сформировать в организации культуру доверия к предоставляемым данным и решениям на их основе? На эти вопросы мы попросили ответить экспертов, планирующих участие в ближайшей конференции «Качество данных».

Дорожная карта DQ by Design

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

Георгий Нанеишвили: «Самый провальный путь — это “сделать все как в DAMA DMBOK”»

«Самый провальный путь — это “сделать все как в DAMA DMBOK”, — заявляет Георгий Нанеишвили, руководитель отдела по работе с клиентами и развитию бизнеса компании DATAREON. — Да, в идеале все должно быть так, как описано в этом руководстве, но до этого еще надо дорасти, причем органично. Для начала найдите “дата-звездочек” — энтузиастов работы с данными, а также недовольных потребителей отчетов, пусть они сформируют требования бизнеса, исходя из которых вы сможете сформулировать план действий, начиная с устранения грубых ошибок и постепенно переходя к получению все более чистых данных. Впрочем, это будет невозможно без формирования дата-офиса и центра компетенции, поиска и привлечения сотрудников всех основных отделов компании, их обучения, организации совместной работы и обсуждений, предоставления инструментов работы с данными».

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

Екатерина Каннуникова: «Дорожная карта сильно зависит от компании, где внедряется DQ, и задач, которые она перед собой ставит»

Екатерина Каннуникова, директор по продуктам направления дата-сервисов VK Tech, отмечает, что дорожная карта сильно зависит от компании, где внедряется DQ, и задач, которые она перед собой ставит: «Внедрять инструменты DQ стоит начать с процессов, в которых данные играют наибольшую роль и где недостаточное их качество может сказаться на показателях особенно сильно. Примером может быть подготовка регуляторной отчетности».

Кирилл Евдокимов: «Внедрение DQ следует начинать с пилотного проекта в конкретной бизнес-области или бизнес-процессе — там, где компания сталкивается с “болью” в данных»

Кирилл Евдокимов, директор по продуктам Data Ocean Governance EMM и DQ компании Data Sapience, рекомендует начинать с пилотного проекта в конкретной бизнес-области или бизнес-процессе, где компания сталкивается с «болью» в данных: «Такой проект должен быть ограниченного объема (на практике до 20 правил, которые влияют на бизнес-процесс) и длиться не более одного-двух кварталов. Ключевая цель — наглядно показать ценность реализации системы управления качеством данных, а заодно заручиться поддержкой первых сторонников из числа бизнеса. Второй этап — масштабирование проекта с методичным охватом критичных для бизнеса данных процедурами контроля качества. Перед началом масштабирования необходимо зафиксировать базовые роли и стандарты, формализовать процесс управления инцидентами и выбрать технические инструменты для автоматизации проверок. Следующими этапами будут оптимизация и прогнозирование, включающие активности по “сдвигу” процедур контроля “влево” относительно пайплайна данных (для выявления проблем, сокращения затрат на их решение и снижения рисков в процессах), тиражирование процедур контроля и реализация предиктивного мониторинга. Дорожная карта обычно фиксируется в дата-стратегии компании».

Григорий Бокштейн: «Начать нужно с пилотного проекта, охватывающего один критичный процесс»

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

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

Дарья Кагарлицкая: «Гонка за качеством данных не должна препятствовать или усложнять сами бизнес-процессы»

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

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

Павел Савченко: «В дальнейшем необходимо организовать планомерную работу по устранению наиболее критичных проблем DQ»

Павел Савченко, presale-архитектор CedrusData, предлагает сначала охватить процессами DQ первичные источники появления проблем с данными — как внутренние, так и внешние, затем провести систематизацию актуальных систем в части состава данных (сущности, атрибуты, назначение), дедублицировать атрибуты или сущности, оптимизировав ETL-процессы, внедрить инструменты поддержки процессов DQ, после чего провести проверки имеющихся систем на наличие проблем DQ, зафиксировать выявленные инциденты. «В дальнейшем необходимо организовать планомерную работу по устранению наиболее критичных проблем DQ, — добавляет Савченко. — Документы для описания дорожной карты следует отразить в презентации будущих инициатив на комитете правления с описанием основных результатов и экономического эффекта. Детали дорожной карты должны найти отражение в документации проектов, нацеленных на улучшение качества данных».

Александр Галайдюк: «Дорожная карта DQ может быть как самостоятельным направлением в рамках ИТ-стратегии, так и частью стратегии Data Governance»

По словам Александра Галайдюка, менеджера проектов DWH & BI направления технологической практики компании Kept, его компания придерживается следующей концептуальной дорожной карты внедрения DQ в организациях: анализ бизнес-процессов и текущих подходов к обеспечению качества данных; расчет экономического эффекта; создание концепции управления качеством данных; проектирование артефактов (методики, требования, реестры); разработка технических и бизнес-требований к инструментам DQ; выбор и внедрение инструментов; обучение руководителей и сотрудников лучшим практикам DQ; реализация процедур контроля и отчетов по качеству данных; повышение эффективности процедур контроля, актуализация ключевых метрик, развитие культуры качества данных. «Эта дорожная карта может быть как самостоятельным направлением в рамках ИТ-стратегии организации, так и частью стратегии Data Governance, — поясняет Галайдюк. — Для гармоничного встраивания инструментов DQ и получения ощутимых выгод мы рекомендуем дополнять собственные команды DQ представителями опытных консультантов и интеграторов, имеющих опыт и бизнес-экспертизу в соответствующих задачах и отраслях».

Дарья Капланская, руководитель Центра экспертизы НСИ российской платформы B2B- и B2G-торговли В2В-РТС, рекомендует отталкиваться от аудита самых болезненных точек — тех, где проблемы с данными напрямую влияют на работу бизнеса: «На первом этапе, который обычно занимает один-два месяца, важно собрать рабочую группу из представителей тех процессов, где проблемы с качеством данных наиболее критичны: финансовый блок, продажи, закупки, логистика, производство. Затем нужно провести честный аудит бизнес-процессов и выявить реальные узкие места. После этого имеет смысл проранжировать процессы по степени влияния на бизнес и определить конкретные показатели качества данных. На этом же этапе хорошо работает точечная диагностика качества справочников и ключевых наборов данных, позволяющая быстро проверить данные по нескольким десяткам параметров и получить отчет на понятном языке для владельцев процессов — это дает быстрый эффект и убеждает в пользе дальнейших шагов. Второй этап — запуск пилотного проекта на самых проблемных участках, обычно длится три-шесть месяцев. Для каждой болевой точки описываются целевой процесс и правила работы с данными, подбираются и внедряются инструменты автоматизации и контроля, запускается работа по достижению целевых показателей качества, а полученные результаты обязательно фиксируются. Третий этап — масштабирование решений на другие процессы. На этом этапе формируется центр компетенций по данным или аналогичная функция, закрепляются роли и зоны ответственности, разрабатываются стандарты и политики, запускаются регулярные проверки и, по возможности, прогнозирование возможных сбоев. Здесь логично подключать сервисы нормализации данных и справочников, чтобы закрепить единые правила описания и исключить возврат к хаосу. Четвертый этап — поддержание культуры постоянной работы с качеством данных: регулярный мониторинг метрик, пересмотр правил по мере изменений в бизнесе, обновление регламентов и обучение сотрудников».

Дарья Капланская: «Дорожную карту разумно зафиксировать в нескольких контурах документации»

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

Формирование культуры доверия к данным

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

Сергей Белостоцкий: «Встроить инструменты DQ в процессы недостаточно — важно сформировать доверие к данным»

«Встроить инструменты DQ в процессы недостаточно — важно сформировать доверие к данным, — подчеркивает Белостоцкий. — Для этого у каждого набора данных должны быть ответственные, понятные правила использования и прозрачная история (Data Lineage). Пользователь должен знать, куда обратиться, если данных не хватает, если они кажутся некорректными или если требуются разъяснения. Культура доверия возникает тогда, когда люди внутри компании понимают: данные — это понятный и доступный инструмент, за которым стоят реальные эксперты и понятные процессы.

Евгений Евстратьев: «Встраивание DQ в бизнес-процессы — это стратегическая организационная трансформация»

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

Герман Ганус: «Формирование культуры доверия к данным — это процесс превращения данных из “просто цифр” в надежную основу для принятия решений»

По мнению Германа Гануса, руководителя направления внешних проектов разметки данных в Yandex Crowd Solutions, формирование культуры доверия к данным — это процесс превращения данных из «просто цифр» в надежную основу для принятия решений: «Культура доверия возникает, когда сотрудник, открывая отчет или используя данные для решения, не сомневается в их правильности: он уверен, что, во-первых, данные точны (или, по крайней мере, известна степень их точности), во-вторых, в случае возникновения проблемы есть ясный путь ее решения, и, в-третьих, данные — это актив, который помогает ему лично и компании в целом достигать целей. Доверие строится не на обещаниях, а на прозрачных процессах, четкой ответственности и постоянной демонстрации ценности качественных данных».

Бокштейн отмечает, что эта культура строится на прозрачности и вовлеченности: «Метрики качества должны быть доступны и видимы всем потребителям данных. Кроме того, в определение правил DG необходимо вовлекать бизнес. Такой подход мы реализуем в своем продукте RT.DataGovernance со встроенным модулем Data Quality. Доверие возникает, когда каждый видит и понимает: данные, которые он собирается использовать, — качественные».

Светлана Кузнецова: «Полезно показывать на реальных примерах, как именно некачественные данные влияют на бизнес»

Светлана Кузнецова, руководитель направления бизнес-автоматизации в компании SimbirSoft, для формирования культуры доверия рекомендует демонстрировать значимость данных, уделять пристальное внимание их качеству и доказывать их надежность: «Например, нужно демонстрировать пользователям метрики DQ — что-то вроде этого: “Качество данных составляет 98% (в 2% записей не указаны контрагенты)”. Также нужно определять ответственность: если в отчете ошибка, ее причина может скрываться не собственно в данных, а в человеческом факторе (например, мог ошибиться менеджер по клиентским данным). Полезно показывать на реальных примерах, как именно некачественные данные влияют на бизнес, проводить разбор реальных инцидентов с данными. Правдивость данных нужно доказывать на конкретных примерах, а если возникли сомнения в отчетах, разбирать их детально и выяснять, откуда в нем те или иные цифры. И конечно, надо поощрять обратную связь — хотя бы снабдить пользователей кнопкой, чтобы они могли сообщить об ошибках в данных. DQ by Design — это жесткое встраивание проверок качества в каждый этап работы с данными. Когда валидация почты происходит до записи в CRM, а аномалия в продажах обнаруживается до утреннего совещания, данные перестают быть проблемой и становятся конкурентным преимуществом».

Павел Толчеев: «Топ-менеджмент должен не только говорить о важности качества данных, но и подкреплять слова практикой»

Павел Толчеев, директор по технологиям и данным российской платформы B2B-и B2G-торговли В2В-РТС, исходит из того, что встроить инструменты — это только часть задачи, и ключевой вопрос здесь — как сделать так, чтобы люди действительно доверяли данным и решениям на их основе: «Первое условие — лидерство и вовлеченность руководства: топ-менеджмент должен не только говорить о важности качества данных, но и подкреплять слова практикой: принимать решения на основе показателей, опираться на единые источники, публично поддерживать инициативы по улучшению качества. Второе — прозрачность: нужен открытый дашборд качества данных, доступный ключевым пользователям, где видны текущие показатели, тренды и статус работ. Каталог данных должен показывать владельцев, показатели качества и уровень доверия, чтобы любой пользователь понимал, с чем он работает. Также нужны инструменты, позволяющие бизнес-пользователям самостоятельно запускать базовые проверки и не зависеть от ИТ-служб в типовых ситуациях. Третье — практическое обучение: важно не только обучать теории, но и анализировать конкретные кейсы. Четвертое — интеграция качества данных в систему мотивации и управления проектами: показатели качества данных должны быть частью KPI владельцев процессов и ответственных за данные в предметных областях, проверка качества должна быть обязательной в проектах по доработке систем и внедрению новых решений. Кроме того, инциденты с данными важно рассматривать наравне с ИТ-инцидентами, фиксировать, анализировать причины и устранять последствия. Наконец, пятое — позитивная повестка: важнее не искать виноватых, а поддеривать тех, кто помогает улучшать ситуацию. Полезно отмечать команды и конкретных сотрудников, сумевших предотвратить крупные ошибки или предложить изменения, которые повысили качество данных. Отдельный эффект дает демонстрация успехов достижений в области качества данных. Когда сотрудники видят, что руководство опирается на данные, процессы поддерживают их качество, инструменты делают его контроль понятным и несложным, а личный вклад в эту работу замечают и ценят — в этот момент качество данных перестает быть узкой задачей ИТ-служб и становится общей основой для эффективной работы компании».

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

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

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

Павел Егоров: «Культура доверия страдает из-за качества дата-продуктов, которые работают неоптимально или оперируют невалидными данными»

По наблюдениям Егорова, культура доверия страдает в основном из-за качества дата-продуктов, которые с первых релизов работают неоптимально или оперируют невалидными данными: «Чтобы сформировать доверие к ним, необходимо синхронизировать процессы DQ с процессами разработки и CI/CD. В результате разработчики не смогут сдать в продуктивную эксплуатацию дата-продукты, в которых не отлажен контроль качества информации. Кроме того, важно повышать доступность данных: у сотрудников должна быть возможность оперативно проверять свои гипотезы, не ожидая месяцами нужных данных. Долгое ожидание сильно раздражает пользователей, да и доверие к данным, предоставляемым с большим опозданием, не может быть высоким».

Коллег дополняет Каннуникова: «Главное — помнить, что качество данных сильно зависит он контекста их использования. Качественный, с точки зрения дата-инженера, почтовый адрес может быть вполне качественным для одного сотрудника и абсолютно некачественным для другого. Так, для отчетности, предназначенной для Агентства по страхованию вкладов, адрес с двумя запятыми подряд может считаться нормальным, а для отдела взыскания “хорошим” может считаться только тот адрес, который соответствует адресу в паспорте».

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