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

Другая причина роста популярности проектов создания корпоративных аналитических платформ — рост разнообразия и объемов данных. Благодаря «оцифровке» все большего числа бизнес-процессов, которые ранее отслеживались лишь вручную через файлы Excel, а также увеличению объемов «внешних» данных: рыночная аналитика; дополнительные справочники; информация из личных кабинетов различных сервисов, используемая, например, для отслеживания исковых требований, становится очевидной потребность в эффективных аналитических инструментах. Хранение и анализ таких данных в системах с «первичкой» часто оказываются нецелесообразными из-за высокой стоимости доработок систем ERP или необходимости быстрого решения в виде полупромышленного прототипа. Тем не менее очень высока ценность аналитики и централизованное ведение таких данных. При этом само хранилище может быть небольшим, включая лишь два-три источника данных в виде централизованных корпоративных ИТ-систем и набора xls-файлов, которые ведутся вручную.

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

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

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

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

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

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

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

Кого нужно искать и нанимать для формирования новой культуры работы с данными? Речь идет о CDO (Chief Data Officer) — директорах по данным.

На рынке труда можно встретить CDO разных типов. Безусловно, каждый специалист, действительно соответствующий C-level, обладает уникальным набором компетенций, но прежде всего это: «Управление», «Методология» и «Платформа». Управление — умение выстраивать процессы, контролировать задачи и управлять ожиданиями заказчиков. Методология — способность гармонизировать и стандартизировать бизнес-процессы, связанные с аналитикой; написание регламентов и конвенций; умение внедрять институты управления данными, включая терминологию, документирование и унификацию и пр. (все, что входит в термин Data Governance). Платформа — глубокое понимание технологического стека, перспектив развития архитектуры и задач интеграции.

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

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

Чаще всего компании сначала нанимают CDO, который проводит анализ текущей ситуации и в течение 1–3 месяцев (в зависимости от размеров бизнеса) разрабатывает план действий. За это время он выявляет точки оптимизации, устанавливает приоритеты и формирует стратегию. Не всегда важно начинать с самой критичной проблемы, а, скорее, с наиболее формализованной, с точки зрения бизнеса, задачи, поскольку первые шаги потребуют от CDO сосредоточиться на запуске инструментов и организации процесса разработки.

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

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

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

Будет ли в это время кто-то заниматься аналитикой и разработкой? На практике бизнес не позволит следовать строгой последовательной модели waterfall и ждать готовности среды — CDO придется предоставить результаты своей работы уже через месяц после презентации стратегии. Поэтому крайне важны специалисты, которые могут быстро собирать прототипы первых бизнес-задач или проводить системную аналитику для наполнения аналитической платформы, пока идет финальная защита стратегии и развертывание окружения. Если начинать с задач, хорошо проработанных с точки зрения бизнес-требований, то дата-аналитики смогут сразу после найма приступить к созданию своего первого продукта, сэкономить время и не допустить ошибок из-за незнания всей специфики бизнес-процессов в компании.

Одним из ключевых качеств, которым должен обладать дата-аналитик, привлекаемый к первым продуктам, является способность сформировать конечный результат «под ключ». К сожалению, без выполнения полного цикла — от поиска данных и проверки гипотез до написания рабочего кода (хотя бы не всегда оптимального) — добиться результатов, которые можно презентовать руководству и бизнесу, не получится. На начальных этапах проектирования первые скрипты часто не оформлены в стандартизированный фреймворк для производства данных и обычно представляют собой простые Python- или SQL-скрипты, запускаемые по расписанию (порой просто через cron). Не стоит ожидать, что эти начальные продукты будут идеальными, но они помогут выровнять ожидания с бизнес-заказчиком и сформировать «физический» образ результата. Если в компании запущен проект по трансформации культуры работы с данными, то это означает, что уже существует какой-то привычный процесс, который нуждается в оптимизации. Многие бизнес-подразделения компании склонны к консерватизму, поэтому первые результаты могут стать отправной точкой для формирования доверия со стороны бизнес-заказчика и корректировки постановки задачи.

Следующий шаг — это нанять «второго» человека в команду офиса данных. К этому времени CDO уже поймет, какие области («Управление», «Методология», «Платформа») он будет развивать сам, а какие необходимо усилить или делегировать. По сути, «второй» человек будет лидером команды аналитики или архитектором, либо руководителем проектов.

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

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

***

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

Источник: Открытые Системы.

Больше новостей читайте в телеграм-канале SAPLAND: Новости экосистемы.