Rewired полностью

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

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

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

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

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

ТД

DPO

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

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

DS

D      DPA

Дизайнер

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

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

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

DA

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

DE

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

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

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

ПРИЛОЖЕНИЕ 25.4

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

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

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

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

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

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

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

4

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

5

Поиск данных

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

1

2

6

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

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

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

Предварительное планирование - "спринт 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.

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

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

-Тофер Грейс