Привет, Хабр! Сегодня я хочу продолжить разговор про методологии внедрения BI. В этом посте речь пойдет о тех методах, которые предлагают специалисты Qlik, PowerBI и Tableau. В этом посте вы узнаете, почему дашборды рекомендуют рисовать на бумаге, зачем в суровой корпоративной среде цветастые иконки-ачивки и многие другие интересные моменты из методологий международных компаний. Кроме этого, мы поговорим о том, какие наработки в сфере внедрения BI уже есть на российском рынке в локализованном виде. А если у вас есть свой опыт или идеи, присоединяйтесь, и давайте обсуждать их в комментариях!
В прошлый раз мы говорили про методику Anaplan, которая подходит не только для внедрения BI, но и достаточно простых финансовых аналитических инструментов (в частности, того же Anaplan). Но сегодня хочется остановиться на тех принципах, которых предлагают придерживаться более традиционные BI-системы с широкими возможностями. Не стоит удивляться, что они во многом повторяют Anaplan Way, и мы не будем подробно останавливаться на уже рассмотренных принципах и методах. Поэтому перед прочтением этого поста лучше хотя бы пролистать предыдущий.
Обращаясь к рекомендациям Power BI и Tableau, которые, очевидно, входят в число лидеров рынка BI, мы в основном узнаем о том, как происходит adoption системы — то есть о формировании культуры управления организацией на основе данных, естественно, на базе конкретного ПО. В отличие от методологии Anaplan, которая четко расписывает процессы внедрения, Power BI и Tableau больше делают упор на том, чтобы все в организации пользовались новым инструментом. Qlik в этом отношении находится где-то посередине. Методики компании также достаточно жёсткие, четко регламентируют как внедрение, так и практику использования BI.
Методология Qlik
Разработчики одной из самых известных на рынке систем предлагают сразу 2 методологии — это QPM (QlikView Project Methodology) и QDF (Qlik Deployment Framework). На момент подготовки поста для первой из них была доступна редакция от 2011 года, а для второй — от 2016-го.
Qlik выделяет 10 критических факторов успеха: поддержка бизнеса, движение от бизнес-кейсов (а не от данных), чёткая связь между бизнесом и IT, достижение быстрых побед (специфическая рекомендация Qlik), наличие стратегического roadmap и модели вовлечения, наличие поддержки QlikView и максимальное использование функциональности, которая доступна “из коробки”, то есть минимизация кастомизации.
Тут сразу можно сделать пару полезных выводов. Например, когда речь идет о ключевых задачах, которые реализуются один раз и надолго, иногда можно и нужно действительно глубоко залезть в код и сделать с помощью API что-то кастомное, так чтобы система работала очень красиво или делала что-то специфическое. Но на больших распределенных проектах, в которых участвует много людей и аналитика постоянно дорабатывается и улучшается, «живёт», бизнес-эффективность достигается за счёт максимального использования коробочной функциональности. Таким образом вы гарантируете себе автоматические обновления, более простую поддержку, и так далее.
Из рекомендации “быстрых побед” также можно вытащить парочку интересных мыслей. Глядя в будущее, когда всё больше и больше сотрудников должны начинать пользоваться системой, полезно бывает оценить, какие задачи мы можем реализовать самым простым и быстрым способом, затрачивая минимум ресурсов. Такие «победы» можно использовать для того, чтобы убедить оппонентов в том, что проект эффективен, система действительно работает и приносит пользу.
Scrum - всему голова!
Как и коллеги из Anaplan, в Qlik предлагают запускать внедрение согласно принципам Scrum. Для самой системы QlikView имеется конкретный список how-to, которого мы сейчас не будем касаться, ведь он относится только к этой системе. Скажу только, что речь идет о небольших изменениях методологии. И если вы разобрались в ванильном Scrum, который используется по умолчанию на проектах разработки ПО, то дальше вы можете просто заглянуть в методологию Qlik и посмотреть, какие изменения разумно в него внести. Как пример, спецы из Qlik предлагают выбирать другое описание критериев качества работы.
Схема проекта внедрения Qlik тоже очень похожа на подход Anaplan. Можно сказать, они вообще идут один-в-один. Мы начинаем с фазы инициации, формируем цели и план проекта, создаем команду, а дальше работаем итеративно. Но есть и отличие. Окончание проекта внедрения Qlik — это не завершение, а переход к модели self-service, когда система развивается уже не в рамках жёсткого проекта, а благодаря использованию и адаптации инструментов BI пользователями из различных подразделений. И, соответственно, подведение итогов проекта происходит несколько по другой схеме.
Идеологи Qlik повторяют то, что мы уже видели в Anaplan Way: в методологии много говорится о важности проектирования и архитектурного подхода. В маркетинговых материалах всех BI-систем красиво рассказывают, как просто с ними работать, как много пользователь может без разработчика и так далее. Но в реальности, конечно, без архитектурного проектирования редко удается обойтись. Если не позаботиться об архитектуре, в какой-то момент может оказаться, что система упадет, не выдержит нагрузки или окажется очень сложной в поддержке. В Qlik подчеркивают, что нельзя просто купить софт и, не имея опытных специалистов, внедрить его. На первом этапе обязательно нужен эксперт — возможно, из консалтинговой компании.
Вторая интересная мысль — это создание прототипов на бумаге. Некоторые недоумевают “Мы же говорим про BigData, machine learning и цифровую трансформацию! Какая бумага?!” Но при этом Qlik предлагает рисовать сами прототипы и дашборды на бумаге или на маркерной доске, потому что это улучшает коммуникацию, повышает вовлечённость…а главное, это просто намного дешевле для заказчика, чем делать что-то в системе, а потом переделывать.
Да, не во всех организациях принято что-то обсуждать, делая зарисовки на маркерной доске. Но я и на своем опыте убедился, насколько много пользы приносит такой подход. И потратив какое-то время на убеждение бизнес-заказчика: «Давайте мы, все-таки, вместе порисуем», вы однозначно окупите его на фоне тех затрат, которые уйдут на реализацию первой версии системы…а окажется, что это совершенно не то, что люди хотели, и в таком виде она никому не нужна.
Развивая эту бумажно-маркерную мысль из методологии Qlik, специалисты часто приходят к выводу, что не надо полировать визуализацию на слишком раннем этапе. Пока дашборд полностью не устоялся, не стоит делать его красивым, подбирать шрифты, цвета и так далее. В 99% случаев это оказывается бесполезно, потому что дашборд, вероятнее всего, еще поменяется. Тут, конечно, могут возникнуть возражения. Я сам встречался с несколькими заказчиками, которые, в принципе, не хотели воспринимать дашборд, пока он не становился красивым. Но это нормальная реакция человека, которому ничего не объяснили. Он думает, что мы халтурим. Но если лицу, принимающему решения, дать понять, что мы хотим сначала обсудить дашборды на бумаге не потому, что нам лень их визуализировать, а потому что так он сэкономит своё время и деньги, большинство людей поменяют мнение и будут готовы двигаться именно по такой схеме. Конечно, будут и товарищи, которые “лучше заплачу за тысячу визуализаций”. В таком случае остается просто увеличивать смету проекта.
С организационной точки зрения у Qlik также есть общие рекомендации. Например, они советуют начинать с малого, а потом быстро расширять проект. То есть не стоит пытаться за один шаг охватить всю организацию, особенно если она большая. Вместо этого нужно запустить пилотный проект, причем такой, чтобы завершить его быстро, и в минимальные сроки расширить практику на другие отделы компании. Мысль, казалось бы, очевидная. Но на практике про нее почему-то часто забывают.
Наконец, модель Qlik содержит достаточно много предложений по тем или иным организационным вопросам. Например, специалисты дают рекомендацию, как должна выглядеть команда, какие роли в ней должны быть, и как стоит их распределить. Также Qlik описывает бизнес-процесс развертывания системы, бизнес-процесс уже работающей аналитики, схема выхода нового аналитического функционала в продакшен. Схема выглядит следующим образом:
● Запрос передается команде
● Идет разработка
● Внутреннее тестирование
● Встреча по утверждению,
● Тестирование
● Доступ для части пользователей
● Сбор обратной связи
● Выход на продакшен
Естественно, в каждой организации схема бизнес-процесса будет своей. Но наличие готового шаблона упрощает задачу — ведь вы можете модифицировать опробованный процесс под себя. К тому же в методологии Qlik есть описания конкретных встреч.
Например, certification meeting — это встреча по утверждению приложения перед тем, как оно попадает на препродакшн. Методология содержит план встречи, описывает, кто должен на нее прийти, о чем вам стоит поговорить (и о чем не стоит забывать), сколько времени это обычно занимает и так далее. Понимание структуры и плана таких встреч — хорошая стартовая точка для планирования своих процессов, характерных для вашей компании.
Методология Tableau
Документы от компании Tableau, как и любые руководства от вендора, содержат достаточно много специфической информации под Tableau. Например, там есть сайзинг серверов, принципы выбора, настройка, развертывание и так далее. Но если оставить эти вопросы за рамками, в методологии Tableau можно найти много интересного про трансформацию культуры организации. Идеологи вендора говорят о том, что культура + технология = Data-driven Organization.
Она как раз формирует их Tableau Blueprint, который рассказывает, как стоит вести подобный проект. По методологии вендора нужно сначала разработать стратегию, привлечь бизнес и создать проектную команду. Об этом мы уже говорили выше. Но дальше начинается самое интересное: внедрение BI методом Tableau делится на 3 стрима:
● Технический (они почему-то называют его Agility. Если вы знаете почему — напишите в комментариях). В него входят развёртывание, мониторинг и поддержка.
● Стрим компетенций или профессионализма. В него входят обучение, образование, измерение уровня компетенций и распространение лучших практик.
● Комьюнити, то есть создание сообщества.
В методологии Tableau также есть хорошие опросники. Просто заполняя их, можно быть уверенным, что ты ничего не забыл в процессе подготовки проекта как с технической, так и с организационной точек зрения. Такой чек-лист, который можно заполнять сначала вместе с IT-шниками, а потом вместе с бизнесом. Как и любой артефакт вендорской методологии, фирменный опросник имеет некоторые привязки к конкретному продукту, но кто помешает нам провести небольшие модификации вопросов, где это требуется?
Но что самое интересное, для комплексной оценки профессионализма Tableau предлагает конкретную модель компетенций.
По горизонтали расположены роли: потребитель аналитики, автор, дизайнер, аналитик, data-scientist, разработчик. А по вертикали выделены конкретные области знаний, которые необходимо освоить и пройти сертификацию. Согласно модели Tableau дальше каждый сотрудник получает бейджики, или “ачивки”, как подтверждение соответствия навыков его уровню компетенции. Интересно, что тут присутствует элемент геймификации.
Ачивки, по задумке Tableau — это не какие-то грустные сертификаты или грамоты, это не какая-то строчка в e-mail — тут у нас красивые значки, которые являются частью подхода Tableau к вовлечению людей. Когда речь заходит о создании внутреннего комьюнити пользователей BI, Tableau, пожалуй, предлагает максимум идей по его развитию. Например, выбор data-чемпионов — это отличная практика, при которой мы поддерживаем людей, у которых лучше всего получается работать с BI, которым нравится аналитика данных. Правильно организованное продвижение таких чемпионов внутри организации позволяет сделать их визионерами новых идей.
Также Tableau предлагает создавать внутренние пользовательские группы — типа telegram-каналов или форумов. Это хороший базис для проведения игр по построению визуализации. Они нужны, чтобы обеспечить вовлечение даже для сильно скептически настроенных пользователей. Многие люди не верят в новые возможности, пока они руками что-то не сделают. А деловые игры как раз позволяют организовать работу над простой задачей для каждого человека, чтобы все осознали возможности новой системы и могли потом использовать ее в рабочих задачах.
Наконец, последнее, что я хотел отметить из методологии Tableau — это практика регулярных собраний Data-doctor, на которых более опытные пользователи помогают менее опытным. Подобные программы, кстати, встречаются у многих вендоров. Так что при внедрении BI можно смело брать любую из практик и адаптировать под свою организацию. На сайте Tableau вы можете найти анонимизированные презентации, в которых собраны фрагменты описаний таких программ от реальных пользователей Tableau.
Power BI
Про Power BI сегодня мы будем говорить меньше всего, но не потому что у них самая маленькая методология. Просто лучшие практики разных вендоров очень похожи. А раз мы уже познакомились с документами от Anaplan, Qlik и Tableau, от Power BI остается взять только изюминки.
Power BI, как и другие вендоры, предлагают инструменты для выхода на новый уровень аналитики. Но в отличие от остальных, в методологии компании можно найти не только текстовые материалы и примеры, но еще и серию роликов на YouTube (на английском языке), в которых все шаги разбираются очень подробно — на каждый раздел предусмотрен свой ролик. Это отличное подспорье для тех людей, кто лучше воспринимает информацию в формате видео.
Российские методологии
Все мы работаем на российском рынке, и поэтому прекрасно знаем, что отечественных методологий очень мало, а можно сказать, что в законченном виде их пока вообще нет. Но в последние пару лет в этом направлении наблюдается активное движение. И уже сейчас есть несколько достойных проектов, на мой взгляд.
Во-первых, стоит обратить внимание на локализацию методик Qlik — Data Literacy.Project. Тут как раз накапливаются материалы, связанные с развитием аналитической культуры в компании. Кроме этого инициаторы перевели свод знаний по управлению данными DMBOK и сделали простые для восприятия дайджесты, которые представляют собой копилку знаний и how-to по управлению данными. В материалах речь идет про качество данных, Data Governance и так далее. Исходный учебник, честно признаться, очень сложный, даже на русском его непросто читать. А благодаря дайджестам Data Literacy.Project, разобраться с ним становится намного проще.
Во-вторых, больших успехов добился Алексей Колоколов из Института бизнес-аналитики. Он является создателем самого крупного комьюнити BI в России — Клуба Анонимных аналитиков. Относительно недавно Алексей выпустил свой фреймворк под названием Agile BI Framework, который предназначен для решения одной конкретной задачи — быстрой разработке дашбордов. И если вам нужны инструменты не для супер-масштабного проекта, а речь идет не про развитие культуры управления на основе данных, а про визуализацию, Agile BI Framework поможет научиться делать короткие итерации и добиваться результатов очень быстро.
Также интересный гайд по разработке стратегии в области BI предлагает признанный в России эксперт Александр Бараков. Он отличается глубиной проработки и систематизирует обширный опыт успешного внедрения практик бизнес-анализа в крупных компаниях.
Единая методология?
Как разработчик BI-инструментов, Visiology тоже работает над методологией внедрения. Сейчас мы хотим создать открытое руководство, объединив полезные подходы и инструменты из нашего опыта и опыта коллег. Учитывая последние тенденции, основным принципом такого руководства является новый подход: мы внедряем не BI, а управление на основе данных. Ведь в конечном счете выгоду приносит именно data-driven управление. А чтобы оно заработало, нужен не только BI. Необходимо и работать с источниками данных, с качеством данных, использовать Data Governance и так далее. В любом случае придется внедрять новые управленческие практики, потому что даже при наличии супер-качественных данных, самых классных дашбордов и лучшей аналитики, руководители, привыкшие опираться на интуицию, а не на данные для принятия решений, не смогут пользоваться новым решением.
Не обязательно эти практики сложны в применении – например, как первый простой шаг мы сейчас рекомендуем всем заказчикам и партнерам пользоваться холстом (канвасом) BI инициативы на этапе обсуждения требований с бизнес-заказчиком. Идею канваса (холста) дашборда как адаптацию модели Остервальдера под задачи BI предложил изначально руководитель команды визуализации Яндекс Go Роман Бунин, а мы ее адаптировали под более широкую задачу. Фактически это простая табличка, которую вы заполняете совместно с бизнес-заказчиком, чтобы аналитические инициативы внутри компании действительно оказались полезными и востребованными.
На этом я заканчиваю обзор основных методологий по внедрению BI, но, конечно, на этом тема, как быстро и эффективно внедрить BI даже выше ожиданий бизнес-заказчика, далеко не исчерпана. Поэтому давайте обменяемся опытом - если у вас есть идеи, какие еще полезные практики можно использовать,— оставляйте комментарии или пишите личные сообщения.