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

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

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

Пирамида самообслуживания потребностей (изображение автора)

Я вспоминаю 90-е годы, когда впервые появились инструменты самообслуживания бизнес-аналитики (BI), такие как Business Objects и Cognos. Черт возьми, как и все слишком энтузиазмированные инженеры-программисты, я даже помог построить один из них на короткий срок в Citigroup. В то время мой юный взгляд делал два очень быстрых прогноза:

  1. Excel мертв
  2. Самообслуживание данных быстро овладеет

Хорошо, так я не совсем Нострадамус. После Citigroup я нашел себя в бизнес-интеллект и консультант BI уже десять лет, выполняя инженерию данных (тогда была ETL, а не ELT), использовал инструменты BI, обучал бизнес-пользователей, повторял. Мы создали “великолепные вещи”, но проект за проектом давал неудовлетворительные результаты:

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

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

Реклама продавца BI: 100% самообслуживание данных демократии

Мои ожидания: 60-80% принятия

Реальность: менее 20% принятия, оптимистически

Со временем эти проекты начали казаться возможностью учиться, а не полным провалом. Что было виной? Инструменты, пользователи, ИТ, консультанты? Мы находимся где-то в 2010 году, и начинает появляться множество документации о неудачных проектах BI. Не “неудачных” в том смысле, что проекты никогда не давали значимых результатов, но “неудачных” в том смысле, что они редко достигали своего полного потенциала. Бизнес-сферы все еще сильно зависели от ИТ для получения данных. Чистые и надежные данные были не быстро доступны.

В этот момент времени происходит интересное явление: визуализационный продукт данных под названием Tableau начинает получать широкое распространение. Он везде и является решением для демократии данных. Затем приходит Power BI как инструмент визуализации и отчетности, сочетающий в себе лучшие черты обоих миров. Однако, спустя десятилетие или даже более, мы все же видим то же самое с этими новыми инструментами: жалкое принятие самообслуживания инструментов BI. Я явно не одинок.

Глобальная степень принятия BI во всех организациях составляет 26%. (360Suite 2021)

49 Потрясающих статистических данных о бизнес-аналитике на 2021 год

Поскольку рынок бизнес-аналитики продолжает развиваться, эти статистические данные показывают, насколько важными будут инструменты бизнес-аналитики…

www.trustradius.com

Мне не могло позволить просто сидеть в стороне. Естественно, мне пришлось создать то, что всегда было нужно миру: инструмент BI, чтобы решить самообслуживание. Да, я наконец-то сделаю все правильно, сказал я себе. Итак, я создал FlexIt Analytics с этой целью. Что ж, помните мои прогнозы ранее? Да, вот опять, я очень ошибался. Давайте сразу перейдем к сути:

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

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

Иерархия потребностей Маслоу

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

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

Иерархия потребностей Маслоу

Иерархия потребностей Маслоу представляет собой пирамиду потребностей, мотивирующих людей. Наименее основные потребности отдельных лиц – в основе…

www.simplypsychology.org

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

Иерархия потребностей самообслуживания

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

Один раз еще, DJ:

Иерархия потребностей самообслуживания (изображение автора)

Сбор данных

В основе, физиологические потребности Маслоу являются очевидными: пища, вода, пристанище. Аналогично, наиболее очевидный уровень иерархии потребностей самообслуживания – это сбор данных. Вам нужно собрать данные. Позвольте нам пойти дальше и сказать, что ваша база должна собирать необработанные данные из разных источников. В современном мире данных это часть извлечения и загрузки данных (Extract, Load, Transform), что приводит к созданию, для упрощения, так называемого озера данных. Обратите внимание на различие между традиционной/старой концепцией хранения данных ETL (Извлечение -> Трансформация -> Загрузка), которая уже неактуальна по многим причинам, которые мы рассмотрим в другой статье.

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

Трансформация

Следующий уровень в иерархии Маслоу – это безопасность, которая включает в себя такие вещи, как безопасность, социальная стабильность, предсказуемость и контроль. В нашей иерархии потребностей самообслуживания мы достигаем этой предсказуемости, стабильности и контроля путем очистки и организации наших данных как бизнес-моделей в нашем хранилище данных. Обычно это принимает форму многомерных моделей звездного схемы. Используя исходные необработанные данные с нижнего уровня Сбора, аналитики могут объединить множество разных таблиц для данных о клиентах. На этом уровне эти различные данные были объединены в общую таблицу, называемую “измерением клиента”. Также в этом процессе данные очищены (дублирующиеся, несоответствующие имена для одного и того же клиента) и выполняются полезные вычисления (например, дата первого заказа), что позволяет использовать гораздо более простой SQL.

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

Семантический слой

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

“Semantic-free” – будущее бизнес-аналитики

Как dbt, метрики, головной безоссовый и универсальный семантический слой обеспечивают “семантически свободную” бизнес-аналитику

towardsdatascience.com

Я утверждаю, что этот уровень является самым важным для обеспечения истинного самообслуживания и что владельцы бизнес-доменов должны быть активно вовлечены. «Универсальный семантический слой» может обеспечить источник правды, который поддерживает аналитику самообслуживания через грамотность в работе с данными, простоту и доверие. Аналитики могут полагаться на дружественные для бизнеса названия полей и сущностей, описания каталога данных и, возможно, самое важное, им не нужно знать, как таблицы связаны друг с другом (или по крайней мере, как писать SQL). У нас также есть доступ к важным вещам, таким как генеалогия данных (отследить поле до исходной таблицы), синонимы (вы называете это “продажами”, я называю это “доходом”) и свежесть данных (когда последний раз обновлялись данные).

Важно отметить, особенно для историков, которые могут сказать: “У Business Objects это уже было в 90-х”. Мы еще не достигли “Уровня анализа” (уровень инструмента бизнес-аналитики). По многим причинам, которые подробно описаны в статье по ссылке выше (“Semantic-free – это будущее бизнес-аналитики”), крайне важно не заполнять семантический слой логики бизнеса в инструмент бизнес-аналитики. Уровень «семантического слоя» в нашей иерархии самообслуживания должен поддерживать следующий уровень, а не быть им.

Анализ

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

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

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

2. Диагностическая – анализ, который показывает, почему это произошло

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

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

Самореализация и преодоление

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

3. Прогнозирующая – определение, что произойдет дальше

4. Прескриптивная – на основе прогнозов рекомендация оптимального пути вперед

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

Компоненты организации, ориентированной на данные

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

Компоненты организации, ориентированной на данные (изображение от автора)

Люди

Я работаю в сфере технологий и хочу создавать технические решения для решения бизнес-проблем. Конечно, если у меня есть требования бизнеса, я закроюсь в темной комнате и напишу некоторый код, и тогда я смогу создать программное обеспечение, которое ответит на бизнес-потребности. Моя ошибка, и ошибка многих других, заключается в недостатке внимания к мягкой стороне вопроса: люди. Кажется очевидным, но я думаю, что мы, технари, должны признать, что мы часто создаем удивительные программные продукты, а затем передаем их бизнес-пользователям и говорим “Вот оно!” Мы озадачены, когда они не используют его так, как мы предполагали, или “просто не понимают”.

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

Процесс

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

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

Гибкая или водопадная методология управления проектами: что лучше для вас?

www.forbes.com

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

Инструменты

В начале мы полагались на инструменты, чтобы они были нашими магическими решениями для наших проблем. Как я установил ранее, инструменты не являются решением. Они даже не приближаются к 1/3 решения. Я думаю, что это что-то вроде 50% Люди, 30% Процесс и только 20% Инструменты. Как поставщик BI-инструментов, это грубая перспектива. Тем не менее, это правда.

Сказав это, существует ряд вещей, которые инструменты могут сделать, чтобы обеспечить общие компоненты людей и процесса. Они должны быть интуитивными, чтобы не требовать глубоких знаний о том, как их использовать, и я думаю, что многие современные BI-инструменты это делают. Одной из областей, где я считаю, что они не соответствуют, является “подключение и использование”. Как я уже упоминал ранее, мы помещаем слишком много бизнес-логики в наши инструменты, поэтому переключение с одного инструмента на другой занимает много времени. Не говоря уже о том, что у многих организаций есть 3 или более BI-инструментов, часто доступа к одним и тем же наборам данных. Мы должны вынести эту бизнес-логику из BI-инструмента и перенести ее в централизованный семантический слой, в который можно включить все BI-инструменты.

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

Шаги для создания организации, ориентированной на данные

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

Шаг 1: Поддержка

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

Шаг 2: Начать с малого

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

Шаг 3: Создать процесс

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

Шаг 4: Демократизация

Управление данными позволит нам более безопасно внедрять эти продукты данных с большей уверенностью и меньшими рисками. Чтобы демократизировать данные, нам необходимо:

  • Устранить отделения данных – это “закрытые” источники данных, контролируемые одним отделом, часто техническим, и изолированные от широкой организации.
  • Развивать компетенцию в области данных – мы не можем ожидать, что бизнес-пользователи сразу поймут то, что IT предоставляет, даже если это их данные. Каталоги данных могут существенно помочь в развитии данной компетенции, но это может быть сложно. В большинстве случаев мы получаем устаревшие таблицы справочников данных, которые пылятся на полках. Нам нужно перейти к более динамичному и активному каталогу данных, который позволяет бизнес-пользователям действовать на объектах каталога данных, а также предоставлять обратную связь по определениям и т.д. для непрерывного улучшения.
  • Построить доверие – чтобы демократизировать данные, IT должно доверять тому, что бизнес будет правильно использовать данные. Бизнес должен доверять, что IT будет предоставлять точные, надежные и своевременные данные. В каждом шаге необходимо устанавливать и поддерживать доверие.

Шаг 5: Сотрудничество

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

Шаг 6: Оценка

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

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

Заключительные мысли

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

  1. Фреймворк – иерархия потребностей, которая поможет определить, что нам нужно построить, чтобы создать организацию, основанную на данных
  2. Компоненты – компоненты организации, основанной на данных: люди, процессы и инструменты.
  3. Шаги для создания – шестиступенчатый подход, фокусирующийся на компонентах, чтобы построить организацию, основанную на данных, в рамках фреймворка.

Удачи в вашем проекте самообслуживания!

Пожалуйста, оставьте комментарий, я с удовольствием выслушаю ваши мысли здесь или свяжитесь с Андреем Тафтом