• Зоны ответственности и компетенций – множество различных задач для каждого из архетипов, начиная от разработки цифровой стратегии, заканчивая поддержкой клиента в CRM-системе.
• Бизнес-результат и KPI – CDO может иметь как явный бизнес-результат, так и неявный, и быть лишь центром затрат с соответствующими показателями оценки эффективности деятельности.
• Платформы и компетенции – в зависимости от модели будет также изменяться технологический ландшафт, например, необходимость включения CRM или IoT.
Получение быстрого результата потребует от организации эффективного пост-пространства для креативной работы сотрудников.
Так, консультанты компании McKinsey предложили использовать Agile для формирования совместных эффективных небольших Data Teams[47].
При этом так же упрощаются существенно сами этапы получения данных и инсайтов:
• Харвестинг данных (или сбор данных)
• Использование гипотез при исследовании
• Создание аналитических сервисов (продуктов на основании данных)
• Модель управления данными (Governance)
• Презентация полученных кейсов.
Первое, о чем стоим договориться команде, – как выглядит Definition of Done[48][49] по Аналитическому продукту или продукту с использованием данных.
Для организационных структур, которые требуют конкретного описания процессов, всегда доступны стандартные swim lane диаграммы, разработанные командами ведущих компаний.
Например, команда Microsoft[50] представила исчерпывающую методологию построения процесса изучения данных и получения исследований, опираясь на жизненный цикл данных и стандартизированную ролевую модель:
• Архитектор решений (solution architect)
• Руководитель проекта (project manager)
• Исследовать данных (data scientist)
• Руководитель проекта (project lead)
С другой стороны, для извлечения максимальной ценности и получения адаптивного к моменту процесса управления данными, появилась методология DEVOPS, которая была сформулирована Энди Палмером (Andy Palmer[51]), СЕО и сооснователем компании TAMR (ранее – основатель компании Vertica).
По его мнению, на ее распространение повлияло несколько ключевых факторов:
• Демократизация аналитики – сегодня все больше людей по всему миру работают с аналитикой.
• Создание специальных баз данных (Vertica, VoltDB, StreamBase, BigTable) под задачи – реляционные базы данных устарели, и сегодня одно решение не подходит для любых задач.
С одной стороны, решения перестали быть универсальными, с другой – решения должны иметь стандартные интерфейсы (API) для интеграции различных решений. Вместе эти тенденции создают «давление с обоих концов технологического стека».
В верхней части стека – все больше пользователей хотят получить доступ к большему количеству данных в большем количестве комбинаций. А на дне стека – сейчас доступно больше данных, чем когда-либо, и лишь некоторые из них агрегированы.
Единственный способ для профессионалов данных справиться с давлением неоднородности как сверху, так и снизу стека состоит в том, чтобы использовать новый подход к управлению данными. Он объединяет операции и сотрудничество для организации и доставки данных из многих источников, надежно совместимым с происхождением необходимых для поддержки воспроизводимых потоков данных.
Сегодня инфраструктура, необходимая для поддержки количества, скорости и разнообразия данных, имеющихся на предприятии, радикально отличается от того, что предполагали традиционные подходы к управлению данными. Характер DataOps включает в себя необходимость управления многими источниками данных и многопотоковыми конвейерами данных с широким спектром преобразования.
Звучит адски сложно, но тем не менее это факт.
Выбор подхода по организации работы с загрузкой, обработкой и агрегацией данных для разного количества данных будет зависеть от многих факторов, которые могут быть индивидуальны для организации. Например, если количество источников данных мало, и они контролируются централизованно со стороны организации, то DataOps как подход избыточен. Но если у организации множество источников данных, различные потребители, потребности в аналитических сервисах и нет возможности проконтролировать сам источник, то единственным эффективным решением по организации работы команды будет DataOps.
Когда ты уже сделал большую работу, повозился с базами данных, нашел и обработал эти данные, то остается, как ни странно, самое сложное – умение их правильно показать.
