Перезагрузка. Руководство McKinsey по преодолению конкуренции в эпоху цифровых технологий и искусственного интеллекта - читать бесплатно онлайн полную версию книги автора Lamarre (ч. 5)

Пример решения, сценарий использования и связанные с ним потребности в данных

Пример страховой компании

Советники

Внутренние функции

БИЗНЕС-ДОМЕНЫ

Продажи

Обслуживание клиентов

Решения

Примеры использования

Домены данных

Цифровое хранилище

Обеспечение микрополитики и предоставление услуг

Подробная документация

Атрибуты внешнего потребителя

Индекс соседства

История приобретения недвижимости

Данные о ценах на недвижимость

Вероятность наводнения по данным FEMA

Советы по защите имущества

Индекс риска землетрясений Геологической службы США по округам США

Данные о рынке активов

Индекс риска ураганов NOAA по округам США

Данные о катастрофах и безопасности

Помогите защитить активы

Цифровой след клиента

Размещение на случай жизненных событий

Помощь в управлении учетной записью и политикой

Общие активы и послужной список

Система отслеживания рисков

Помогите подготовиться к чрезвычайным ситуациям

Помогите оптимизировать покрытие

Рекомендовать дополнительные услуги

Консультант по дополнительным услугам

Консультант с оплатой за услуги

Профиль застрахованного лица и демографические данные

Данные о стоимости автомобильного рынка

Рекомендации по микрополитике

Страховые предпочтения

Консультант по комплексному обслуживанию

Каналы взаимодействия

Советы по защите

Быстрая связь

Оценка готовности данных

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

Девять параметров для оценки качества данных

Точность

Степень соответствия данных согласованному источнику

Своевременность

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

Последовательность

Степень, в которой идентичные данные должны иметь одинаковое значение, где бы они ни хранились или отображались

Полнота

Степень заполнения поля, а также необходимая широта, глубина и история.

Уникальность

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

Когерентность

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

Доступность

Степень доступности текущих и исторических данных для анализа

Безопасность

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

Взаимозаменяемость

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

ПРИЛОЖЕНИЕ 24.2

Оценка данных по этим параметрам включает три этапа для каждого элемента данных. Во-первых, учитывая известные и вероятные будущие потребности бизнеса в данных, определите набор правил качества данных. Например, возьмем элемент данных "адрес клиента": Правило, актуальное для многих B2C-организаций, гласит: "Адрес клиента должен быть точным".

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

В-третьих, измеряйте качество данных и составляйте отчеты о результатах работы в соответствии с установленными правилами качества данных. Большинство компаний используют программные пакеты (например, Talend Open Studio, Ataccama ONE, Informatica Data Quality) для измерения производительности в соответствии с правилами и проведения более широкого сканирования для выявления проблем с качеством данных. Независимо от того, используется программное обеспечение или нет, процесс определения правил качества данных и целевых показателей остается критически важным.

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

Одна из самых больших проблем, с которой сталкиваются компании в ходе этого процесса, заключается в том, что оценка качества данных и их очистка могут отнимать много времени и стоить дорого, хотя мы видим, что появляются инструменты искусственного интеллекта, которые помогают в этом процессе. По этой причине важно сосредоточиться на наиболее важных данных для ваших приоритетных сценариев использования. Например, в страховой компании, о которой идет речь в Примере 24.1, важно было иметь данные, которые были бы менее трех месяцев назад и были легко доступны, а также отвечали строгим требованиям конфиденциальности и секретности. Но они не должны были быть на 100 % точными. Или в случае с компанией, занимающейся недвижимостью, актуальность данных была крайне важна, но только на рынках Нью-Йорка и Лос-Анджелеса.

Разработка минимального жизнеспособного продукта (MVP) с использованием менее совершенных данных может быть успешной, если имеется необходимая критическая масса данных и команда четко понимает, какую ценность они хотят получить. Кроме того, компании все чаще обращаются к инструментам машинного обучения и искусственного интеллекта, таким как Talend, Trillium Quality, Sypherlink, Syncsort и AI4DQ1, чтобы очистка существующих данных (хотя некоторые проблемы всегда требуют определенных ручных усилий, например, выравнивание иерархии продуктов в регионах для согласованной глобальной отчетности).

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

Разработка дорожной карты данных

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

По нашему опыту, вы будете работать на трех разных уровнях параллельно:

Уровень 1 сосредоточен на создании капсул данных, которые будут выполнять конкретную работу по обеспечению готовности приоритетных элементов данных и созданию путей потребления этих данных (подробнее об этом в следующей главе).

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

Уровень 3 закладывает основу для здорового управления данными, чтобы все ваши усилия по очистке и обработке данных не пропали даром, обеспечивая правильный сбор будущих данных (см. главу 27).

Примечание

1. AI4DQ - это продукт компании QuantumBlack AI by McKinsey.

Глава 25.

Продукты для работы с данными: Многоразовые строительные блоки для масштабирования

Данные - ценная вещь, и они прослужат дольше, чем сами системы.

-Тим Бернерс-Ли

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

Подробнее о цифровых двойниках

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

Цифровые двойники состоят из двух основных частей: эмуляторов и симуляторов. Эмуляторы - это продукты данных, которые объединяют разрозненные наборы данных для мониторинга реальных систем. Эмуляторы обеспечивают возможность захвата, хранения и воспроизведения данных в масштабе (например, мониторинг сбоев в работе сети, выявление узких мест на производственной линии). С другой стороны, симуляторы - это программные приложения, основанные на реальных данных, которые позволяют компаниям экспериментировать с гипотетическими сценариями "что-если", такими как перенаправление запасов через логистическую сеть и изменение конструкции двигателя.

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

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

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

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

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

Это представляет собой фундаментальный сдвиг в том, как компании думают о данных и управляют ими (см. иллюстрации 25.1 и 25.2).

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

Продукты данных включают в себя проводку, необходимую для "потребления" данных различными бизнес-системами, например цифровыми приложениями или системами отчетности. У каждого типа бизнес-систем есть свой набор требований к хранению, обработке и управлению данными; мы называем их "архетипами потребления".

Примеры продуктов данных

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

Например, продукт данных для инвестиций, ориентированных на экологические, социальные и управленческие показатели (ESG), мог бы принести

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

Унаследованная система данных во многих организациях может быть сложной и неэффективной.

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

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

Озеро необработанных данных

Основные системы обработки данных

Внешние данные

Неструктурированные данные

Хранилище данных

Поток данных

Системы учета

Хранилище оперативных данных

Цифровое банковское приложение

Инвестиционный портал

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

Предиктивная модель оттока

Финансовый отчет

Отраслевая экосистема данных

Примеры использования

технологии

наборы данных

Использование в зависимости от конкретного случая Использование в зависимости от конкретного случая

Платформа данных

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

Источник: Верал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Лучший способ использовать данные в работе", Harvard Business Review, июль-август 2022 г.

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

Поток данных

Системы учета

Поставщик

Цифровые приложения

Цифровое банковское приложение

Инвестиционный портал

Клиент

Расширенная аналитика

Филиал

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

Отчетность

Продукт/услуга

Предиктивная модель оттока

Обмен внешними данными

Финансовый отчет

Работодатель/ Данные по отрасли

агент экосистема

Discovery Песочница данных исследование

Платформа данных

Продукты данных

Архетипы потребления

Примеры использования

Основные системы обработки данных

Хранилище данных

Внешние данные

Озеро необработанных данных

Неструктурированные данные

Хранилище оперативных данных

Источник: Верал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Лучший способ использовать ваши данные в работе".

Harvard Business Review, июль-август 2022 г.

ПРИЛОЖЕНИЕ 25.2

Хотя в "дорожной карте" организации могут быть сотни вариантов использования, обычно она потребляет данные одним из пяти способов, которые мы называем архетипами потребления (см. Рисунок 25.3). Продукты данных, созданные для поддержки одного или нескольких таких архетипов потребления, могут быть легко использованы в нескольких бизнес-приложениях с аналогичными архетипами.

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

Архетипы потребления продуктов данных

ARCHETYPE ТРЕБОВАНИЯПРИМЕР ИСПОЛЬЗОВАНИЯ

Цифровые приложения

Очистка и хранение специфических данных в определенном формате и с определенной периодичностью (например, предоставление доступа в режиме реального времени к потокам данных GPS или датчиков)

Приложение для маркетинговых трендов или приложение для отслеживания транспорта

Передовые аналитические системы

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

Механизмы моделирования и оптимизации

Системы отчетности

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

агрегированные на базовом уровне и представленные в аудированной форме

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

Песочницы открытий

Сочетание необработанных и агрегированных данныхСпециальный анализ для поиска новых вариантов использования

Внешние системы обмена данными

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

Банковские системы, которые обмениваются информацией о мошенничестве

Источник: Верал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Лучший способ использовать ваши данные в работе".

Harvard Business Review, июль-август 2022 г.

ПРИЛОЖЕНИЕ 25.3

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

Определение продуктов данных, приносящих прибыль

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

Понимание потребности бизнеса в том или ином продукте данных сводится к тщательному анализу, который отвечает на следующие вопросы:

Является ли продукт данных уникальным? Аналогичные данные могут уже существовать в организации или на рынке.

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

Как выглядит "хорошо"? Четко определите минимальную планку качества. Например, для данных по коммерческой недвижимости может быть важно иметь данные в течение месяца для приоритетных рынков, в то время как для других рынков такие свежие данные могут быть не нужны. Аналогично, важно определить, насколько точными должны быть данные. В этом же примере с недвижимостью необходимо, чтобы данные были на уровне квартала, района или почтового индекса?

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

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

Настройка стручков продуктов данных

Продукты данных требуют специальных подразделений и финансирования. У каждого продукта данных должен быть владелец продукта (данных) и межфункциональная группа.

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

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

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

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

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

Пример стручка, разрабатывающего продукты данных

Владелец продукта данных

Возглавляет работу по разработке продукта данных

Техническое обеспечение (инженеры, ИТ-руководители)

Предоставляет экспертные знания в области инфраструктуры и DataOps

ТД

DPO

Управляющий(ие) данными

Управление соответствующими доменами данных

D DPA

Дизайнер

Создает легкую для

Аналитик(и) продуктов данных

потребление опыта для пользователей (если это рассматривается как модель потребления)

Приносит голос пользователей/клиентов

Архитектор данных Инженер(ы) по данным

Разрабатывает общую архитектуру данных для продукта

Выполняет работы по проектированию данных

ПРИЛОЖЕНИЕ 25.4

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

Разработка продуктов данных

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

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

Подход к разработке продуктов данных

Рецепт продукта "6S" - пример

Структурирование данных для создания сценариев использования, например, архитектура

Обмен данными и создание необходимых отчетов, информационных панелей и т.д.

Поиск данных

3 и измерить его текущее состояние

Определение направлений развития для создания стоимости

Выбор данных для хранения в течение долгого времени

Управление продуктом путем утверждения ролей и процессов

Предварительное планирование - "спринт 0"

для разработки бэклога продукта

Agile-спринты для итеративной разработки продукта

Разработка плана для следующего выпуска

Пример из практики: Компания по выпуску кредитных карт создает "единый источник правды" о своих клиентах

У крупного мирового эмитента кредитных карт было около 200 различных приложений, управляющих данными клиентов. Обслуживание каждого из этих приложений обходилось в среднем в 300 000 долларов в год. Хуже того, такое распространение приложений привело к проблемам с регулирующими органами, которые утверждали, что в приложениях не было единого "источника истины" для информации о клиентах, необходимой для оценки рисков и других факторов.

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

Примечание

1. Джошан Чериан Абрахам, Гильерме Круз, Себастьян Кубела, Томаш Лахус, Кайваун Роушанкиш, Санчит Тивари и Родни Земмель, "Цифровые близнецы: От одного близнеца к метавселенной предприятия", McKinsey

.com, октябрь 2022 года, https://www.mckinsey.com/capabilities/mckinsey

-digital/our-insights/digital-twins-from-one-twin-to-the-enterprise

-метаверс.

Глава 26.

Архитектура данных, или система "труб" данных

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

-Тофер Грейс

Если представить данные как воду, то архитектура данных - это система "труб", по которым вода доставляется от места хранения к месту использования. Архитектура данных - это основная среда для управления хранением, преобразованием, анализом и потреблением данных пользователями или приложениями. Без продуманной архитектуры данных компаниям приходится нелегко, поскольку данные часто разбросаны и заперты в десятках информационных силосов (например, в унаследованных базовых системах).

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

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

По их словам: Платформа данных для обеспечения гибкости

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

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

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

-Анил Чакраварти, президент подразделения Digital Experience Business, Adobe

Архетипы архитектуры данных

Существует пять архетипических архитектур данных для создания современной платформы данных (см. Рисунок 26.1). Каждая из них построена на базе облачного масштабируемого хранилища, предлагаемого ведущими поставщиками облачных услуг, но базы данных и технологии доступа к данным, построенные на их основе, отличаются друг от друга.

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

Архетипы архитектуры данных

ОБЛАЧНОЕ НАТИВНОЕ ОЗЕРО ДАННЫХ

Централизованная бессерверная архитектура, использующая объектное хранилище и вычисления, которые могут масштабироваться независимо друг от друга

Оптимизирован для (очень) крупномасштабных карт данных для SQL-аналитики и современных приложений AI/ML

Гибкая основа для добавления возможностей (например, DWH,

в режиме реального времени), но начинает рассматриваться как "унаследованная" архитектура

ОБЛАЧНОЕ ХРАНИЛИЩЕ ДАННЫХ

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

Реализует современное преобразование данных с помощью SQL или

Ориентированные на пользовательский интерфейс инструменты ETL (например, dbt, Matillion)

Очень хорошая производительность в подавляющем большинстве корпоративных аналитических нагрузок

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

LAKEHOUSE

Сочетает в себе преимущества

Использование nextgen

Справляется с самыми

Менее развитая инструментальная база, но

Озеро данных и DWH

технологии хранения

сложные пакетные данные

быстрые темпы технического прогресса

в интегрированную платформу для аналитики (например, BI, SQL) и использования AI/ML

(например, Delta Lake или Iceberg), поддерживающие ACID-транзакции поверх объектных хранилищ.

задания и большие объемы потоковых данных (например, IoT).

инновации

ДАННАЯ СРЕДА

Возникающий архетип;

Децентрализованный

Продукты данных

Создание продуктов данных

фундаментальное отступление

архитектурный подход

проверено на качество,

используя любой из

от централизованных ИТ и

сосредоточен на данных

каталогизированы, и

архитектура данных

функции данных

продукты, полностью принадлежащие бизнес-доменам

доступ через четко определенные службы данных

архетипы, определенные выше

ДАННАЯ ТКАНЬ

Новая стратегия для

Ткань сшита

Предназначен для решения

Отсутствие существующей оснастки

создание единой системы данных

вместе через

многооблачные сценарии

В настоящее время позволяет использовать истинный

среда по всему

метаданные в защищенном виде,

для неоднородных

Data Fabric, он должен

Ландшафт данных предприятия

унифицированный уровень управления данными

источники данных и инфраструктура

лучше строить своими силами

ПРИЛОЖЕНИЕ 26.1

сосуществуют архетип (для искусственного интеллекта) и архетип облачного хранилища данных (для BI). Это были два доминирующих архетипа для

в последнее десятилетие. В начале 2020-х годов появился новый архетип - "дом у озера", который стремится объединить технологический стек данных для обслуживания как BI, так и AI.

Последние два архетипа, перечисленные на предыдущей иллюстрации, появились недавно в связи с тенденцией к децентрализации управления данными (data mesh) и потребностью крупных корпораций в управлении данными в многооблачных средах (data fabric).

Ниже мы опишем, для чего лучше всего подходит каждый архетип и каковы его ограничения:

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

До недавнего времени озера данных располагались в локальных сетях в виде сложной платформы Hadoop. Облако изменило ситуацию: основные возможности Hadoop предоставляются через масштабируемые и надежные сервисы данных, управляемые облачным провайдером в виде объектного хранилища (например, S3, ADLS), Spark (например, AWS Glue, Azure Synapse Analytics) и распределенного механизма запросов (например, Amazon Athena, BigQuery).

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

Облачное хранилище данных (например, Snowflake, Synapse, BigQuery) - это доминирующий дизайн для создания BI для оперативной и управленческой отчетности, а также пользовательских BI-отчетов. Эта архитектура радикально упрощает технологический стек для быстрого предоставления сложных возможностей бизнес-анализа и аналитики. Эта конструкция ставит SQL в центр работы по проектированию данных, которые все еще могут быть организованы в современные, хорошо протестированные конвейеры данных, используя DBT, инструмент для преобразования данных. Эта архитектура особенно привлекательна для организаций, ориентированных на облачные технологии, и крупных организаций, переходящих на облачные технологии.

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

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

Несмотря на расширенный набор возможностей, он требует значительных инженерных навыков для разработки и эффективного управления. Наибольший финансовый смысл она имеет для больших массивов данных (100+ ГБ). Все крупные облачные провайдеры и новые нишевые игроки, такие как Tabular (Apache Iceberg), Onehouse (Apache Hudi) и Dremio (Arctic), продвигают архетип Lakehouse, подтверждая, что Lakehouse - это современный паттерн архитектуры данных, а не просто собственная разработка одного вендора.

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

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

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

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

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

Облачная и локальная инфраструктура данных

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

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

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

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

Принятие решения о возможностях работы с данными и внедрение эталонных архитектур

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

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

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

Возможности данных

ПОТОК ДАННЫХ

каталог, мониторинг моделей и

Качество данных, наблюдаемость и централизованность

ПОТРЕБЛЕНИЕ ДАННЫХ

АНАЛИТИКА ADVANCED ПРИМЕНЕНИЯ

(BI и отчетность) АНАЛИТИКА (Операционные системы)

Разработка BI иDSВнутренняя операционная

Визуализация Окружающая среда системы

Специальный анализ SQLПроизводство моделейМобильные и веб-приложения

Окружающая среда приложения

ДАННЫЕ СЕРВИСЫ

Конечные точки API данных Публикация/Метрика и функция и API подпискиКонечные точки Хранилища(например, Transform, Management (RESTstore , serve, monitor, and and/or GraphQL). Аналитика управление многократно используемыми функциями

оптимизированные данные для BI и искусственного интеллекта)

(например, Parquet) в федерации данных и конечных точках SQL, уточненная зона и/или виртуализация

(JDBC и/или ODBC) DS Sandbox

ХРАНИЛИЩА ДАННЫХОБРАБОТКА ОБЪЕКТОВХРАНИЛИЩА ДАННЫХ ИИ/МЛ

(структурированный или неструктурированный)

Реляционные (например, SQL) Обучение и оптимизация

DS Sandbox Сервер, Oracle, ML-модели (например,

(для Analytics/ML) Postgres) Распределенный

NoSQL (например, KVS, обучение, БД документов, графооптимизация , БД GPU) вычисления)

Хранилище данных STREAM

(например, магазин ПРОЦЕССИНГ

структурированный, интегрированный

Хранение данных на дешевых, надежных носителях для поддержки BIT-трансформации и "бесконечно" масштабируемых медиаактивностей , аналитика) анализ данных

в режиме реального времени

ВЛИВАНИЕ ДАННЫХ

БАТЧ СОБЫТИЕ ЧУВСТВИТЕЛЬНЫЙ ПАКЕТНЫЙ ПРИЕМ ПОТОКОВАЯ ПЕРЕДАЧА ДАННЫХ ОБРАБОТКА ДАННЫХ ОБРАБОТКА

Ввод в системуВвод в систему в режиме реального времениУправление ПИИОчистка , планирование Потоки данных (например, обнаружение, преобразование и пакеты) Изменение данныхСохранение и обогащение данных в

Захватывайте потоки, управлять чувствительными партии,

датчики, трансак-данные ) обычно ежедневные данные о событиях)

СОЗДАНИЕ КОНВЕЙЕРОВ ДАННЫХ Создание конвейеров данных с помощью Планирование процессов обработки данных в

И ОРКЕСТРОВКА SQL или код (например, Python) надежный и интеллектуальный способ

Управление моделью Master DataML: Модель Управление данными: Каталог, Линейка данных,

GOVERNANCE (MDM) централизованные метаданные для MLOpsметаданные для DataOps

Защита данных: Авторизация, расширенные инструменты: Контроль доступа к данным, аутентификация, шифрование и аудит Предотвращение потерь, конфиденциальность данных, сохранение данных и др.

Инфраструктура как код (IaC), DevOps и автоматизация, администрирование, ведение журналов, мониторинг

БЕЗОПАСНОСТЬ ДАННЫХ

ИНФРАКРАСНЫЕ РАБОТЫ

ИСТОЧНИКИ ДАННЫХ

Структурированные данные

Транзакционные и событийные данные

Структурированные основные и справочные данные

Другие третьи лица

Структурированные данные

Неструктурированные данные

Машина и звук , сенсорное изображение и

ДанныеВидеоданные

Неструктурированные текстовые данные

Данные о контенте социальных сетей

После того как вы выбрали необходимые вам возможности работы с данными и определили последовательность построения, можно приступать к выбору конкретных технологий работы с данными. Именно здесь важна эталонная архитектура. В целом, основные технологические компоненты будут определяться выбранным архетипом и выбранным поставщиком облачных услуг (CSP). На рисунке 26.3 показан выбор технологии для архитектуры Lakehouse, построенной с использованием Databricks на Azure. В данном конкретном случае дизайн максимально использует возможности Databricks. В качестве альтернативы можно было бы использовать программное обеспечение с открытым исходным кодом, чтобы минимизировать привязку к поставщику, снизить стоимость и/или обеспечить лучшие в своем классе возможности. Аналогичные архитектуры Lakehouse существуют и для других облачных сред.

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

Лучшие практики проектирования архитектуры данных

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

Эталонная архитектура: Lakehouse с использованием Databricks в Azure

Ведение журнала и мониторинг:

Мониторинг Azure

Интеллектуальные приложения и другие операционные системы, основанные на данных

ПРИЛОЖЕНИЯ

ПОТРЕБЛЕНИЕ ДАННЫХ

Среда моделирования лаборатории DS

Azure ML

Azure ML Studio DS Notebooks Kedro ML pipelines

BI и визуализация

Power BI, QlikView, DB Notebooks

SQL Analytics

Блокноты Databricks

РАСШИРЕННАЯ АНАЛИТИКА

АНАЛИТИКА

Конечные точки API данных: Azure API Manage- ment, собственные API

ДАННЫЕ СЕРВИСЫ

Конечные точки SQL:

Databricks SQL

Конечные точки публикации/подписки: Темы Kafka на Azure EventHubs

Аналитические оптимизированные данные: Дельта-таблицы на ADLS

Azure Data Lake Gen 2

(исходные данные)

ОЗЕРО ДАННЫХ DATABRICKS DATA LAKEHOUSE

ХРАНИЛИЩА ДАННЫХ

Озеро Дельта

Песочница (для лаборатории DS)

ПОТОК ДАННЫХ

Хранилище метрик и характеристик: Databricks Feature Store, Tecton

Федерация данных / виртуализация: Denodo, Trino/ Starburst, Dremio

Databricks (pySpark, Spark SQL)

ПАКЕТНАЯ ОБРАБОТКА

Системы обработки данных (потоковая передача данных Spark)

ПОТОКОВАЯ ОБРАБОТКА

Databricks ML Runtime Azure ML

ИИ/МЛ

ПРОЦЕССИНГ

Создание конвейеров данных:

Python, ADF, DB Notebooks

Оркестровка конвейера данных:

Вакансии Databricks, ADF, Airflow

Управление моделями: Каталог данных:

БД mlFlow или Azure Purview, Datahub

Наблюдаемость Линейность инадежность данных: МонтеМетаданные : Данные Маркеса Карло, Datafold и OpenMetadata

OSS, Collibra, Alation

Реестр ML

Управление идентификацией: Azure Active Directory

Управление секретами: Azure Vault

Инфраструктура как код: ARM DevOps: Azure DevOps,

шаблоны, Terraform, Pulumi

Github, GitLab

Золото

Серебро

Бронза

Зона высадки

ИСТОЧНИКИ ДАННЫХ

Структурированные данные

Неструктурированные данные

Транзакционные Структурированные

Другие третьи лица

Машина и Звук,

Неструктурированные

Социальные сети

& Event DataMaster &

Структурированный

SensorImage , и

Текстовые данные

Содержание

Справочные данные

Данные

ДанныеВидеоданные

Данные

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

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

Создайте высокомодульную и эволюционную архитектуру данных, использующую лучшие компоненты, которые при необходимости можно заменить новыми технологиями, не затрагивая другие части архитектуры данных. Сосредоточьтесь на интерфейсах, основанных на конвейере данных и API, чтобы упростить интеграцию между разрозненными инструментами и платформами. Создайте платформу управления API (часто называемую шлюзом API) для создания и публикации API, ориентированных на данные, внедрения политик использования, контроля доступа, измерения использования и производительности. Аналитические верстаки, такие как Amazon SageMaker и Kubeflow, упрощают создание комплексных решений в высокомодульной архитектуре данных.

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

Примечания

Свен Блюмберг, Хорхе Мачадо, Хеннинг Соллер и Асин Таваколи, "Выход из тупика архитектуры данных для масштабирования ИИ", McKinsey

.com, 26 января 2021 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/breaking-through-data-architecture- gridlock-to-scale-ai; Antonio Castro, Jorge Machado, Matthias Roggendorf, and Henning Soller, "How to build a data architecture to drive innovation - today and tomorrow", McKinsey.com, June 3, 2020, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ how-to-build-a-data-architecture-to-drive-innovation-today-and- tomorrow.

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

Глава 27. Сделайте сайт

, чтобы получить максимальную отдачу от данных.

Хаос среди хаоса - это не смешно, но хаос среди порядка - это смешно.

-Стив Мартин

Операционная модель данных - это общий подход к тому, как организация должна управлять данными. Она состоит из четырех основных компонентов: организация, таланты и культура, инструментарий и DataOps, а также управление и риски (см. Рисунок 27.1).

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

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

Компоненты эффективной модели работы с данными

Организация

Степень централизации

Структура руководства

1 2 Роли и карьерные пути

Культура, основанная на данных

Талант и

культура, основанная на данных

Повышение квалификации (Академия данных)

Процессы управления

Управление и риски

Стандарты политики

4 3 Автоматизация процессов и расширение возможностей

DataOps

Передачи и точки интеграции

Организация

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

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

Степень централизации

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

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

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

Структура руководства и управленческие форумы

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

Типичная настройка для всех областей возможностей данных в передовой федеративной модели

Степень централизации1

Отчет о возможностях

Что предоставляет центр2

Что поставляется федеративным способом

Стратегия работы с данными

Управление продуктами данных

Архитектура данных

Инженерия данных

Управление данными

Операции с данными

Главный офис данных

>50-

75%

<25%

Руководитель отдела данных или ИТ

>75%

Руководитель отдела данных или ИТ

25-

50%

Главный офис данных

<25%

Руководитель отдела данных или ИТ

50-

75%

Общеорганизационная стратегия в области данных, обеспечение ценности данных для всех подразделений

Стандарты продуктов данных, инструментальные средства и игровые программы; управление некоторыми корпоративными продуктами.

Архитектура корпоративных данных, архитектурные ограждения и обзор

Глубокая экспертиза, объединенный потенциал для реализации практических решений

Политика и стандарты управления данными, метрики и информационные панели, управление некоторыми доменами предприятия

Группа по работе с данными, которая занимается решением проблем и запросами данных (например, выписки, новые наборы данных)

>75%

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

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

Владение и управление исходными системами; определение потребностей во внешних данных

Команды инженеров по обработке данных, согласованные с бизнес-направлениями (в частности, по мере повышения уровня зрелости данных)

Повседневное управление доменами данных (например, определение метаданных, измерение и улучшение качества данных)

Устранение проблем, характерных только для данного подразделения или требующих глубоких знаний в области бизнеса

Риск, связанный с данными (включая конфиденциальность данных)

Руководитель отдела по работе с данными или юридического отдела/отдела нормативно-правового соответствия

Таксономия рисков в данных; интерпретация нормативных актов; политики, стандарты и средства контроля для управления рисками

Риски, характерные для конкретного подразделения, и нормативные требования. Руководство по допустимым рискам для бизнеса.

Талант и культура работы с данными

>75%

Типичный % ЭПЗ в центре

Руководитель отдела данных или HR

Создание потенциала данных, стратегия и управление талантами, управление изменениями

Ролевое моделирование целевой культуры и поведения. Оценка эффективности работы ресурсов. Наращивание потенциала конкретного подразделения.

Обычно в офисе корпоративных данных, но некоторые области обычно принадлежат ИТ-отделу, юридическому отделу, отделу рисков и другим.

ПРИЛОЖЕНИЕ 27.2

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

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

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

Таланты и культура, основанная на данных

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

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

Ключевые роли данных

Категория Роль Обязанности

Роли, согласованные с доменом данных

Управляющий доменом данныхРуководит работой по управлению данными для определенного домена данных,

работа по повышению качества и удобства использования данных

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

Роли, согласованные с продуктом данных

Владелец продукта данныхОпределяет направление и контролирует разработку

продукт данных - т.е. минимальный набор данных для решения конкретной бизнес-задачи (часто с использованием данных из нескольких областей данных)

Архитектура данных - согласованные роли

Владелец платформы данныхУстанавливает направление и контролирует развитие

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

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

Роли, которые охватывают

возможности

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

Аналитик качества данныхОценка качества данных в соответствии с потребностями бизнеса, определение

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

ПРИЛОЖЕНИЕ 27.3

Инструментарий DataOps

DataOps использует принципы и технологии agile для сокращения времени, необходимого для разработки новых и обновления существующих активов данных.

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

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

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

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

Управление и риски

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

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

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

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

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

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

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

Пример глобального банка

Определение

Название метрики

Результаты метрики

Данные Данные

Имя

Тренд

лидер спонсоров

Данные

Отслеживание

Процент выполнения этапов

96%

Джон Джейсон

соблюдение политики и стандартов

соответствие политикам и стандартам управления данными

требуется для управления данными в обычном режиме

(10/10)

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

Оценка качества данных с точки зрения бизнес-процессов и поставщиков данных

Количество дефектов открытых данных

Вопросы открытых данных

243 из 27 671*

Кейт Кевин

Навыки работы с данными и талант

Оценка состояния навыков и талантов, необходимых для реализации программы данных

Приоритетный набор на руководящие должности и на должности ниже по уровню заполнения данных

87% (94/108)

95% (103/108)

Кейт Марвин

Риск для данных

Отслеживание снижения рисков при использовании данных

Процент VaR, на который повлияли корректировки (скользящая средняя за 3 месяца)

69%

45% Цель

Джон Сьюзен

Сокращение разницы в общих расходах в рамках Примера 1

21% ($12.1B)

Сокращение на 29% Целевое сокращение

Джон Сьюзен

ПРИМЕРНЫЕ ПОКАЗАТЕЛИ ОТСЛЕЖИВАНИЯ

FRAMEWORK

Проблема Под угрозой По плану Завершено

Ход выполнения программы

прогресс программы управления данными

подотчетная команда (владелец)

Процент вех в прошлом

(47/49)

Джон

Джейсон

реализация

Выполняется подотчетной командой (владельцем)

(2/49)

Данные

Мера

Запуск форумов по управлению данными

100%

Кейт

ПРИЛОЖЕНИЕ 27.4

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

Инструменты и платформы управления данными помогают организациям отслеживать все свои данные, повышать их качество и управлять основными данными, а также многое другое. На рынке представлено большое разнообразие инструментов, включая как новые платформы (например, Alation, Tamr, data.world, Octopai или erwin), так и уже зарекомендовавшие себя решения (например, Informatica и Collibra)2.

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

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

Примечания

Брайан Петцольд, Матиас Роггендорф, Кайваун Роушанкиш и Кристоф Шпорледер, "Проектирование управления данными, обеспечивающее ценность", McKinsey.com, 26 июня 2022 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/designing-data-governance- that-delivers-value.

Метаданные: "Метаданные - это информация, которая описывает различные аспекты информационного актива для улучшения его пригодности на протяжении всего жизненного цикла". Источник: Gartner, "Линейка данных включает в себя происхождение данных, то, что с ними происходит, и то, куда они перемещаются со временем. Линейка данных обеспечивает видимость и значительно упрощает возможность отследить ошибки до их первопричины в процессе анализа данных". Источник: Натали Хоанг, "Линейность данных помогает повысить ценность бизнеса", Trifacta, 16 марта 2017 г.

Раздел 5

Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:

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

Понимаете ли вы, какие продукты данных необходимы вашей организации для достижения успеха?

Есть ли у вас специальные команды по работе с данными?

Вы четко представляете, где объединение внутренних данных с внешними позволит создать конкурентное преимущество?

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

Измеряете ли вы потребление данных?

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

Кто является распорядителями данных в вашей организации и какую пользу они приносят?

Раздел 6. Ключи к разблокировке принятия и масштабирования

Как заставить пользователей принять ваши цифровые решения и масштабировать их в масштабах предприятия

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

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

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

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

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

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

Глава 30: Обеспечение воздействия путем отслеживания того, что имеет значение. Эффективное отслеживание требует жесткой архитектуры управления эффективностью, которая связывает OKR с операционными KPI, а также сильного процесса поэтапного отслеживания, подкрепленного инструментарием.

Глава 31: Управление рисками и построение цифрового доверия. Остерегайтесь новых рисков, возникающих в результате трансформации цифровых технологий и ИИ в таких областях, как кибербезопасность, конфиденциальность данных и предвзятость ИИ. Управляйте ими, внедряя функции контроля в процесс разработки.

Глава 32: А как же культура? Обратите внимание на "цифровые" лидерские качества 300 лучших сотрудников и инвестируйте в развитие навыков в масштабах всего предприятия.

Примечание

Майкл Чуй и Брайс Холл, "Как высокоэффективные компании разрабатывают и масштабируют ИИ", Harvard Business Review, 19 марта 2020 г., https://hbr.org/2020/03/how-high-performing-companies-develop- and-scale-ai.

Глава 28.

Принятие пользователями и изменение бизнес-модели

Любая достаточно развитая технология неотличима от магии.

-Артур К. Кларк

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

Определение принятия и масштабирования

Принятие: Использование цифровых решений сотрудниками и/или клиентами

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

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

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

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

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

Двустороннее внедрение пользователей

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

Если решение улучшает пользовательский опыт, вам, возможно, придется провести программу управления изменениями, чтобы обеспечить его принятие. Управление изменениями заключается в оказании влияния на конечных пользователей с помощью ряда конкретных мероприятий, чтобы они действительно использовали решение. Эти мероприятия по изменению отражены в хорошо известной и проверенной модели влияния1 , состоящей из четырех элементов (см. Рисунок 28.1):

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

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

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

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

Модель влияния в действии

Пример: Внедрение решения по управлению доходами для грузового бизнеса авиакомпании для 250 торговых представителей по грузовым перевозкам.

Вовлечение лидеров и ролевое моделирование

Убедительная история изменений и коммуникации

Привлечение руководителя грузового бизнеса к участию в ключевых этапах разработки решения

Продемонстрируйте решение на ежегодной конференции по продажам

Расскажите в информационном бюллетене компании о ценности нового решения по управлению доходами для клиентов, авиакомпании и сотрудников

Ролевые тренинги и развитие навыков

Измерение и производительность

Обучение 250 торговых представителей по всему миру работе с новым приложением

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

Измерьте степень внедрения решения через частоту использования приложения

Включение показателя внедрения в анализ эффективности работы руководителей высшего звена отдела продаж

ПРИЛОЖЕНИЕ 28.1

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

Адаптация бизнес-модели

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

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

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

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

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

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

Смена бизнес-моделей, вызванная внедрением новых цифровых решений

Примеры

ПРОДАЖИ

Прямые продажи на местах Электронная коммерция

Последствия для бизнес-модели

Правильное определение размера штата продавцов на местах с течением времени

Увеличение численности группы по работе с клиентами

Интеграция ИТ внутри

команда электронной коммерции

МИКС ДОХОДОВ

Продукт Услуги

Последствия для бизнес-модели

Потребность в сервисной поддержке на местах

Увеличивается продолжительность и сложность контрактов с клиентами

ОПЕРАЦИИ

Ручная сборка Сборка Cobot1

Последствия для бизнес-модели

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

Новое сотрудничество между командами по проектированию коботов и производственными операциями

СООТНОШЕНИЕ КАПИТАЛЬНЫХ И ОПЕРАЦИОННЫХ ЗАТРАТ

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

Последствия для бизнес-модели

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

Капиталоемкость растет Требуются инвестиции в обслуживание(могут быть инвестиции в людей, аналитику или и то, и другое)

1. Кобот: совместный робот, способный обучаться нескольким задачам, чтобы помогать людям, в отличие от автономного робота, который жестко запрограммирован на многократное выполнение одной задачи, самостоятельную работу и неподвижность.

ПРИЛОЖЕНИЕ 28.2

Оценка влияния сквозного процесса

Пример авиакомпании

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

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

ПРИМЕР ВОЗДЕЙСТВИЯ НА ВОСХОДЯЩИЙ ПОТОК

ПРИМЕР ВОЗДЕЙСТВИЯ НА ПОСЛЕДУЮЩУЮ ДЕЯТЕЛЬНОСТЬ

Сквозные процессы: Как влияет на процесс?

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

Увеличение времени в аэропортах для погрузки/разгрузки большего количества грузов

Управление эффективностью: Как отслеживать эффективность?

Сбросьте план продаж, поскольку можно продать все больше и больше грузов

Новые цели и стимулы для дополнительного пассажирского багажа

Организация и навыки: Как влияют на людей?

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

Операторам грузовых перевозок в аэропортах необходимо пройти обучение оптимальным процедурам паллетирования

Установки и поведение: Как привлечь людей к работе?

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

ПРИЛОЖЕНИЕ 28.3

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

Создание команды по усыновлению

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

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

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

Примечания

Скотт Келлер и Колин Прайс, "За пределами производительности" (Hoboken, NJ: Wiley, 2011).

Аджай Агравал, Джошуа Ганс и Ави Голдфарб, Сила и предсказание

(Бостон: Harvard Business Review Press, 2022).

Глава 29.

Разработка решений для легкого воспроизведения и повторного использования

Часто бывает так, что когда вы думаете, что закончили что-то, вы оказываетесь в начале чего-то другого.

-Фред Роджерс

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

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

Разработка эффективного подхода к тиражированию

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

Далее необходимо выбрать архетип масштабирования. Выбор правильного архетипа зависит от общей сложности решения, готовности организации принять изменения и срочности масштабирования преобразований в масштабах предприятия. В разных решениях могут использоваться разные архетипы (см. Рисунок 29.2). Три основных варианта:

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

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

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

Определите последовательность масштабирования

Пример горнодобывающей промышленности

Бизнес-подразделение А Бизнес-подразделение Б

Сайт E

Сайт A

Сайт G

Сайт B

Сайт F

Сайт C

Сайт H

Сайт D

Сайт E

Сайт C

Сайт B

Сайт F

Сайт G

Сайт A

Сайт J

Сайт I

Сайт H

Сайт I

Простота внедрения

Расчетная годовая экономия

Существующий

Возникающие Критический пробел

(6 измерений вправо)

Сайт J

Tech

технико-экономическое обоснование

Возможности

и ресурсы

Готовность

меняться

Сходство

с другими сайтами

Открытость для

сотрудничать

Подходит для организации

цели

ПРИЛОЖЕНИЕ 29.1

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

Различные способы продвижения по пути масштабирования

Пример типа

Определите, какие

решения для масштабирования и где

Определите

последовательность модулей

Выберите

архетип масштабирования

Подход

Горная промышленность

Горнодобывающая компания разработала решение по оптимизации заданных параметров для своих обогатительных фабрик

Оптимизатор заданного значения

Масштабирование по всем 12 концентраторам

Упорядочить концентраторы по потенциальному воздействию, зрелости ИТ и доступности данных датчиков

Линейные волны

Внедрять на каждом участке

Начните с каждого сайта: оценка данных, настройка, обучение, а затем запуск.

Постройте индивидуальное решение для сайта 1 и передайте модель данных на сайты 2 и 3, чтобы обеспечить более быстрое внедрение на сайте 3+

Автомобили

Автомобильная компания разработала семейство решений по контролю качества для различных продуктов (т.е. систем и компонентов)

Масштабный пакет решений

Масштабирование по платформам транспортных средств

Упорядочить растения по потенциальному воздействию и схожести платформ

Экспоненциальные волны

Развертывание на заводах, производящих один и тот же продукт, с ведущим заводом, за которым следуют волны из 2, 4, 8+ заводов.

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

Авиакомпания

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

Решение для управления доходами

Масштабирование всех 1200 сетевых маршрутов

Все маршруты имеют одинаковый приоритет

Большой взрыв

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

Разработка производственной версии решения для всех маршрутов

"Переключение" с помощью решения, интегрированного в внутреннюю систему планирования грузоперевозок