Self-service - аналитика как иерархия потребностей
От еды и крова до самореализации: как для создания основ self-service аналитики использовать научный подход
Я часто вспоминаю 90-е годы, когда на рынке появились такие self-service инструменты, как Business Objects и Cognos. Как и все увлеченные инженеры-программисты, я принимал активное участие в создании подобных инструментов, работая в Citigroup. В то время моя молодая горячая голова была уверена в том, что:
- Excel – пережиток прошлого;
- Self-service данные очень скоро захватят весь мир
Согласен, до Нострадамуса мне еще очень далеко. После Citigroup я в течение десяти лет рпаботал в качестве BI-консультанта - занимался проектированием данных (тогда еще ETL, а не ELT) и обучал бизнес-пользователей. Мои коллеги и я создали несколько "замечательных вещей", но при этом мы были вынуждены констатировать, что:
Бизнес-пользователи внедряют программное обеспечение и self-service инструменты не так быстро, как нам того хотелось бы.
Новые инструменты «пользовались успехом» лишь в узком кругу специалистов (как правило, технических), которые с их помощью создавали дашборды и отчеты, остальные же сотрудники компании оставались к ним равнодушны. Потребность в консультантах была по – прежнему велика.
Обещания BI-поставщиков: 100-процентное принятие self-service инструментов
Мои ожидания: 60-80% принятия
Реальность: <20% в лучшем случае
Через некоторое время все эти проекты стали восприниматься, как полный провал отличная возможность для обучения. Кто (что) был в этом виноват? Инструменты, пользователи, ИТ, консультанты? В 2010 году появилось огромное количество документов, свидетельствующих о неудачных BI-проектах. "Неудачных" не в том смысле, что проекты так и не дали значимых результатов, а в том, что они так и не раскрыли весь свой потенциал. В плане получения качественных данных бизнес по-прежнему опирался на ИТ: «добыть» достоверные данные было не так-то и просто.
Чуть позже происходит одна интересная вещь: популярность набирает self-service продукт для визуализации данных под названием Tableau. Затем появляется его главный конкурент Power BI. И все же, спустя уже много лет, мы по-прежнему не можем сказать, что self-sevice BI-инструменты внедрены повсеместно.
Глобальный показатель внедрения BI –инструментов составляет всего лишь 26 % (360 Suite 2021)
Я не мог оставаться в стороне. Я должен был создать то, что нужно всему миру, а именно оптимальный self-service BI-инструмент… Вуаля, FlexIt Analytics. Помните мои прогнозы из 90-х гг.? Да, все по-прежнему совсем не так, как я себе это представлял. Позвольте мне перейти к делу:
Никогда не было и не будет единого волшебного решения для того, чтобы сделать аналитику данных доступной для широких масс.
Ни один BI-инструмент не способен решить проблему самообслуживания. Но все же мы можем сделать шаг назад и взглянуть на ситуацию с другой стороны, не обращая внимания на технологии, и тогда, возможно, нам откроется то, что было скрыто от нас все эти годы.
Пирамида потребностей по Маслоу
Перенеситесь в прошлое, а именно в среднюю школу, и попробуйте вспомнить эту бодрящую лекцию по психологии о человеческой мотивации. Если Вы не проходили эту тему в школе или просто не можете вспомнить, то вот ее краткое содержание:
Абрахам Маслоу, американский психолог, разработал теорию человеческой мотивации, согласно которой в первую очередь должны быть удовлетворены базовые потребности человека, и только потом можно будет говорить о потребностях более высокого порядка. Таким образом, мы двигаемся от краткосрочных потребностей низшего уровня, таких как пища и вода, к потребностям более высокого уровня, которые более долгосрочны, сложны и труднодостижимы. Потребность наивысшего уровня – это самоактуализация.
В двух словах: прежде чем перейти на следующий уровень, нам нужна база. Любой человек, занятый в сфере данных, сразу же поймет, что это напрямую связано с "самореализацией данных", что, несомненно, является "самообслуживанием". В конце концов, в обоих случаях есть понятие "само", а это не может быть простым совпадением. Давайте разбираться.
Иерархия потребностей самообслуживания
Подобно пирамиде Маслоу, иерархия потребностей самообслуживания в аналитике данных показывает, как каждый уровень поддерживает и обеспечивает вышестоящий уровень. Кроме того, чем выше Вы поднимаетесь, тем больше требуется доверия.
Сбор данных
Физиологические потребности Маслоу очевидны: еда, вода и кров. Точно так же очевиден и базовый уровень в иерархии потребностей в самообслуживании – это сбор данных. Прежде всего необходимо собрать данные (если быть точнее, то необработанные данные из разных источников).
Любой анализ данных, произведенный на этом уровне, должен быть выполнен высококвалифицированными аналитиками данных, при этом у него самый низкий уровень доверия. Аналогия может быть такой: можете ли Вы сразу перейти к самоактуализации? Возможно, но как только вечеринка закончится, Вы сразу же возвратитесь на землю =)
Преобразование данных
Следующий уровень в иерархии Маслоу – это безопасность, которая включает в себя такие вещи, как безопасность, социальная стабильность, предсказуемость и контроль над ситуацией. В нашей иерархии самообслуживания мы достигаем предсказуемости, стабильности и контроля путем очистки и организации данных в виде бизнес-моделей в хранилище данных. Часто это принимает форму многомерных моделей в виде звезд. При использовании исходных данных с нижнего уровня аналитикам, возможно, придется объединить множество разрозненных таблиц для получения данных о клиентах. На этом уровне разрозненные данные объединяются в общую таблицу, называемую измерением клиента, и очищаются.
Таким образом, мы установили еще один уровень безопасности и доверия к нашим данным, а также предоставили возможность новой группе аналитиков для самообслуживания, поскольку им больше не нужно разбираться во всех сложностях, связанных с исходными данными. Также необходимо отметить, что на данном этапе важно активное участие владельцев бизнес-доменов. Процесс преобразования данных призван удовлетворять реальные потребности бизнеса, поэтому владельцы бизнеса должны быть вовлечены в этот процесс.
Семантический слой
Третий уровень по Маслоу - это любовь. Корреляция с нашей иерархией самообслуживания просто поразительна, поскольку семантический слой - это буквально то место, где Вы устанавливаете свои отношения с данными (а именно соединяете таблицы).
Я со всей ответственностью утверждаю, что этот уровень является наиболее важным для обеспечения истинного самообслуживания, и что владельцы бизнес-доменов должны принимать в этом процессе самое активное участие. Универсальный семантический слой может стать единым источником истины, который обеспечит возможность самообслуживания благодаря простоте и доверию к данным. Аналитики могут со всей уверенностью полагаться на удобные для бизнеса описания каталогов данных, и, что, возможно, самое важное, им совсем не нужно знать то, как именно таблицы соединяются друг с другом. У нас также есть доступ к таким важным вещам, как data lineage и свежесть данных (информация о том, когда данные обновлялись в последний раз).
Здесь следует отметить еще одну важную вещь: мы еще не достигли "уровня анализа" (уровень BI-инструментов), иными словами, Вы не должны «запихивать» семантический слой бизнес-логики в BI-инструмент. Уровень "семантического слоя" в нашей иерархии самообслуживания должен поддерживать следующий уровень, а не быть им.
Анализ данных
На этом уровне мы говорим об инструментах BI, отчетах, дашбордах, а также о том, что представляет собой самоослуживание в области данных. Если Вы нашли корреляцию семантического слоя с иерархией Маслоу такой же потрясающей, как и я, тогда Вам лучше сесть. Итак, наивысший уровень потребностей по Маслоу – это самоактулизация или самореализация. Здесь он поразделяет потребности на "низшие", такие как статус, признание, слава, престиж и внимание, и "высшие", такие как сила, компетентность, мастерство, уверенность в себе, независимость и свобода. Привет "героям данных", "мастерам дзен" и гуру.
На этом уровне иерархии самообслуживания мы видим владение бизнес-доменом и аналитику самообслуживания с упором на два из четырех типов аналитики:
1. Описательная - отчеты и дашборды, которые показывают, что произошло;
2. Диагностическая – анализ причин, показывающий, почему это произошло
Вы создаете дашборды на основе чистого хранилища данных с хорошо смоделированным слоем трансформации и универсальным семантическим слоем, не так ли?
Парадоксально, но именно BI-инструменты, которые, как мы думали, обеспечивают самообслуживание, на самом деле могут оказать медвежью услугу. Мы знаем, что Tableau (потрясающий инструмент для визуализации данных) получил огромную популярность благодаря тому, что смог обогнать медлительные ИТ-процессы и дать бизнесу то, что он хочет видеть. Однако он также способен и затянуть бизнес в болото, сделать так, чтобы он никогда не смог выйти на новый уровень и занимался только лишь созданием описательных дашбордов.
Самоактуализация и трансценденция
Высший уровень иерархии Маслоу связан с самореализацией, личностным ростом и раскрытием своего потенциала. Как и в жизни, в мире данных не существует вершины, достигнув которой, Вы скажете: "Все, готово". Это постоянная работа, бесконечный процесс. На этом уровне мы выходим за рамки базовой описательной и диагностической аналитики и устанавливаем очень высокий уровень доверия к нашим данным. Это позволяет использовать следующие два типа аналитики:
3. Прогностический - выяснение того, что произойдет дальше;
4. Предписывающий - определение оптимального пути развития на основе прогнозов.
На данном этапе мы имеем прочную основу для дальнейших действий и вполне имеем право сделать первые шаги в направлении использования искусственного интеллекта, автоматизации бизнес-процессов и решения других более сложных задач.
Составляющие организации, управляемой данными
Итак, мы создали основу для улучшения нашей "жизни с данными", поставив перед собой самую высокую цель - самореализацию данных. Теперь давайте разберемся, как этого достичь. Во-первых, давайте посмотрим, на чем нам нужно сосредоточиться в первую очередь: люди, процессы и инструменты.
Люди
Я - технарь, поэтому хочу создавать эффективные технические решения для решения бизнес-задач. Конечно, если мне озвучат бизнес-требования, я запрусь в комнате, напишу несколько кодов и в итоге создам ПО, полностью отвечающее потребностям бизнеса. Моя ошибка в данном случае будет заключаться в том, что я не уделю должного внимания «мягкой» стороне вопроса, а именно людям. Это очевидно, но я думаю, что нам, технарям, нужно признать тот факт, что зачастую мы создаем невероятные программные продукты, передаем их бизнес-пользователям и говорим: "Тадам, вот оно!"… А потом недоумеваем, потому что их используют не так, как мы предполагали, или совсем не понимают.
Человеческая сторона технологий может вызывать недоумения и казаться мистической, но так быть не должно. В основе всего лежит установление доверия, для чего необходимо сосредоточиться на нескольких ключевых областях. Во-первых, необходимо обеспечить заинтересованность сотрудников, в противном случае силы, направленные против Вас, могут свести на нет даже самые правильные технические решения. Все, что мы делаем, должно учитывать реальные потребности бизнеса. Во-вторых, необходимо обеспечить "грамотность в работе с данными" с помощью каталогов данных и семантических слоев. Наконец, когда мы внедряем решения, не достаточно просто провести стандартную сессию по внедрению и тренинг, которые больше похоже на лекции. Мы должны сосредоточиться на обучении, которое базируется на реальных потребностях в данных в тот момент, когда бизнес-пользователю необходимо решить существующие проблему с данными.
Процесс
Даже если мы правильно подберем людей, нас все равно можно легко сбить с пути. Чтобы не сбиться с пути, нам необходимо правильно организовать процесс. Одна из наиболее очевидных проблем последних десятилетий, особенно в сфере технологий, заключается в том, что многие проекты выполнялись по принципу водопада, когда конечный результат должен быть определен в самом начале проекта. Наш первый шаг, особенно в мире данных, где на создание управляемой данными организации может уйти много лет, - это быть проворным и сосредоточиться на постоянно меняющихся потребностях бизнеса, используя гибкий подход.
«Agile - гибкий метод, позволяющий менять направление работы даже на самых поздних этапах, а также учитывать мнение всех заинтересованных сторон на протяжении всего процесса»
Forbes
Одна из главных ошибок людей, занимающихся "Agile", заключается в том, что они работают над кучей разрозненных проектов, которые в итоге не приводят к целостному конечному продукту. Поэтому очень важно иметь конечную цель и стандарты управления данными. Также важно, чтобы данные принадлежали бизнес-пользователям, а не техническому отделу, - они должны принимать непосредственное участие в этом процессе. Наконец, процесс должен быть направлен на постоянное совершенствование. Что работает/ что не работает? Почему? Затем нужно это исправить и двигаться дальше.
Инструменты
В самом начале мы искренне верили в то, что инструменты станут волшебным решением всех наших проблем. Как я уже говорил, инструменты - это не решение. Я думаю, что успех – это что-то вроде 50 % людей, 30 % процессов и только 20 % инструментов. Будучи поставщиком BI-инструментов, я считаю, что это достаточно грубый подсчет. Тем не менее, это правда.
При этом есть несколько вещей, которые инструменты могут сделать для того, чтобы обеспечить слаженную работу людей и процессов. Очевидно, что они должны быть интуитивно понятными, не требовать глубоких знаний о том, как их использовать. На мой взгляд, многие современные BI-инструменты справляются с этой задачей на ура. Одна из областей, которую, на мой взгляд, стоит доработаит, - это "plug-and-play". Как я уже говорил, мы закладываем в наши инструменты слишком много бизнес-логики, поэтому переключение с одного инструмента на другой сопряжено с большими трудностями. Не говоря уже о том, что многие организации используют 3 и даже больше BI-инструментов, часто обращающихся к одним и тем же наборам данных. Нам нужно вынести бизнес-логику из BI-инструмента и перенести ее на централизованный семантический слой, к которому могут подключаться все BI-инструменты.
Кроме того, наши инструменты должны хорошо интегрироваться с другими инструментами, а не пытаться быть обособленным универсальным инструментом. При этом важно, чтобы мы не впали в другую крайность и не получили 100 инструментов, которые создают запутанную и беспорядочную архитектуру данных. В конце концов, помните, что инструменты нужны только для помощи людям и для облегчения протекания процессов.
Этапы создания организации, управляемой данными
Теперь, когда мы определили рамки и общие компоненты организации, управляемой данными, давайте поговорим о том, как ее создать.
Этап 1: Buy-in
Прежде всего, Вам необходимо определить ключевых заинтересованных лиц и получить поддержку на уровне руководства. Без этого Вы рискуете столкнуться с нехваткой "человеческих ресурсов" для реализации компонентов самообслуживания. Добиться всеобщего одобрения сразу может быть очень сложно, поэтому определите тех, кто может стать Вашей поддержкой на первых порах, и сосредоточьтесь на них. По завершении всех этапов Вы снова вернетесь к этапу 1 и продолжите строить свою организацию, управляемую данными, добиваясь все большей степени вовлеченности в процесс. Вам нужно добиться эффекта снежного кома.
Этап 2: Начните с малого
Продолжая аналогию со снежным комом, мы строим снеговика. Разумеется, мы начинаем с малого и постепенно наращиваем объемы. Мы хотим добиться "быстрых побед" в нашей первой итерации, чтобы потом закрепить успех, привлекая все больше и больше людей.
Этап 3: Процесс сборки
Правда, подобные "быстрые победы" чреваты созданием беспорядочных архитектур… Именно поэтому мы сразу же устанавливаем стандарты управления данными, которые позволяют нам сосредоточиться на предоставлении качественных, точных и надежных продуктов данных. В данном контексте важно задействовать такие инструменты, как Github.
Этап 4: Демократизация
Data governance позволит нам безопаснее внедрять продукты данных. Демократизируя наши данные, мы должны:
- Ликвидировать "силосы данных", контролируемые одним отделом, как правило, техническим, и изолированные от более широкой аудитории;
- Повысить уровень грамотности в области работы с данными — мы не можем ожидать того, что бизнес-пользователи сразу же поймут, что именно им предоставляет ИТ-отдел. Каталоги данных могут быть очень полезны в данном случае, но и это не панацея. Очень часто мы формируем словари данных в электронных таблицах, которые устаревают и превращаются в пыль. Поэтому необходимо создавать более динамичные и активные каталоги данных, позволяющие бизнес-пользователям выполнять определенные действия, а также предоставлять обратную связь для постоянного совершенствования;
- Установить доверие — Для того, чтобы демократизировать данные, ИТ-отдел должен искренне верить в то, что бизнес будет использовать их должным образом. А бизнес, в свою очередь, должен быть на все 100 % уверенным в том, что ИТ-отдел будет предоставлять точные, надежные и своевременные данные. На каждом этапе очень важно устанавливать и поддерживать доверительные отношения.
Этап 5: Сотрудничество
Теперь, когда мы предприняли шаги по демократизации данных, нам нужно убедиться в том, что мы трудимся над выработкой решений совместно с другими сотрудниками и в любой момент можем получить драгоценную обратную связь. Важно создать своего рода группу DART (Data Analytics and Reporting Team), в которую должны войти представители из самых разных сфер - от технологий до бизнеса, собирающиеся на регулярной основе для выработки решений возникающих проблем.
Этап 6: Оценка
В конце мы должны отметить победу и обязательно обсудить то, что не сработало или требует доработки. Не придумывая KPI, мы должны найти способ измерить успех. Довольны ли люди результатами первой итерации? Создали ли мы полезный продукт данных сразу? Затем необходимо повторять итерации и постоянно улучшать то, что получилось, и то, что не получилось…
Затем возвращаемся к этапу 1 и заручаемся поддержкой больше количества сотрудников.
Заключение
Итак, мы рассмотрели три ключевые области, на которых необходимо сосредоточить свое внимание и усилия для того, чтобы создать организацию, управляемую данными, обеспечив при этом возможность самообслуживания. Важно отметить, что мы не идем от нулевого уровня самообслуживания к полностью демократизированной организации, основанной на данных, а пытаемся понемногу продвигаться вперед и постоянно совершенствоваться для того, чтобы все больше людей в организации могли эффективно работать с данными.
Три ключевые области, о которых идет речь в данной статье:
1. Фреймворк — иерархия потребностей, на базе которой можно определить, что именно нужно создать для организации, управляемой данными;
2. Компоненты — компоненты организации, управляемой данными, а именно: люди, процессы и инструменты;
3.«Строительные» этапы - шестишаговый подход к построению организации, управляемой данными.
