Этапы проекта Qlik Sense. Краткий обзор состава работ по проекту

Введение Qlik Project Steps

Qlik Sense – очень гибкая платформа создания отчетности. В ней нет ограничений на количество приложений, на количество отчетов, количество данных. Вы можете создать 1 большое приложение с множеством различных отчетов, либо создать много приложений, в каждом из которых будет 1-2 сложных по структуре или логике отчета. Все зависит от Ваших потребностей. Единственно что нужно учитывать – это затраты на поддержку решений.

Также можно создать приложение Qlik Sense, в котором в библиотеке задать нужные измерения и показатели, а пользователи будут сами создавать простые отчеты, графики, дашборды, аналитические панели.

Этапы создания модели Qlik Sense

Рассмотрим основные этапы создания модели Qlik Sense:

Краткая схема создания приложения выглядит следующим образом:

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

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

Иногда заказчик хочет получить отчет, который можно получить из учетной системы. Он уже там есть, только заказчик про это не знает.

Еще 1 совет – всегда стремитесь избегать в своей работе с данными, которые пользователи ведут в Excel! На этапе выявления требований стремитесь заставить заказчика отказаться от excel, Хотя бы в сторону MS Access. Ну или обязать заказчика разработать жесткую форму для ведения данных с проверками.

2. Дальше начинается работа с источниками данных. В идеале сначала проводится краткий аудит учетных систем на предмет того, как вводятся данные.

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

На этом этапе необходимо проверить наличие в справочниках нужных атрибутов (согласно требованиям), наличие фактов, смоделировать (например в Excel) расчеты, которые нужно получить в рамках аналитической модели.
Для снижения риска проекта по Qlik Sense рекомендую делать на предварительной стадии прототип модели на очень ограниченном объеме данных, проверить структуру модели, те или иные гипотезы. Внимание: самое важное на первом и втором этапах не уйти глубоко в детали и не выдумать из небольшого, быстрого и полезного проекта ОГРОМНОГО МОНСТРА.

В ходе второго этапа (при аудите учетных систем) уточняется ТЗ и разрабатывается план проекта.

3.Выстраиваем структуру окружения QS Проекта на Windows Сервере. Если в рамках проекта планируется использовать Qlik Sense Desktop – то требуется одна архитектура организации окружения (с привлечением QlikView Desktop), если Qlik Sense Enterprice – то другая архитектура.

Здесь необходимо создать каталог папок, в которых будут храниться приложения/скрипты .qvs для выгрузки данных (Extractor),  приложения/скрипты .qvs для трансформации данных (Transform), приложения/скрипты .qvs для сборки QVD для конечных аналитических приложений.

Возможная структура папок для хранения QVD-файлов:

• DataSource
  
  • RawQVD – по каждой системе создается отдельная папка в директории RawQVD и в нее выгружаются таблицы.
  • RawFiles – В этой директории хранятся файлы, которыми управляет отдел Qlik Sense. Это могут быть файлы с настройками, временные справочники Excel, специфические меппинги.
  • DataTier1 – в этой директории находятся файлы QVD, которые прошли первичную обработку в процессах обработки данных. На этом этапе в документы добавляются товары, в справочники добавляются различные атрибуты, флаги. Производится расшифровка перечислений (например, для 1С Предприятия) и т.д. Обычно в DataTier1 данные хранятся также по папкам с названиями систем учета.
  • DataTier2 – Агрегированные данные на основе данных DataTier1 из нескольких источников данных. Здесь QVD файлы группируются по тематике, например, продажи, остатки и т.д.
  • DataTier3 – 

4. На четвертом этапе идет основная работа с данными. Строится процесс выгрузки данных из источников. Это может быть одна база данных или несколько баз данных. При этом в качестве источника данных может выступать облачный сервис (bitrix24, amocrm, мойсклад и т.п.).

4.1. Разработка Extractor на Qlik

Виды Extractor (выгрузки)

1. Выгрузка полной таблицы из базы данных и сохранение в формате QVD. Подходит для источников данных с небольшим объемом данных (нужно учитывать скорость наполнения базы данных, при этом объем транзакций год из года приростает), справочников из ERP систем. Данные выгружаются 1 в 1 с минимальными преобразованиями форматов, без агрегирования и доп.расчетов.
2. Инкрементальная выгрузка данных из DataBase учетных систем. Здесь не всегда так просто. Во-первых, в учетной системе должны каким-то образом помечаться измененные записи, а также должна быть дата создания сущности. Для таких целей подойдут поля [Дата создания] и [Дата модификации]. Если нет полей, по которым можно было бы установить список измененных сущностей (документов, проводок), то придется делать инкрементальную загрузку по периодам (т.е. принимать, что данные в старом периоде, например, которые создавались больше года или полугода назад не изменяются). И перегружать только скользящий период год или полгода.
   Почитать про инкрементальную загрузку можно здесь https://ivan-shamaev.ru/practical-issues-in-qlikview-part-2/#___Incremental_Load
   Во-вторых, придется всегда иметь возможность выгрузить систему полностью (на случай, если все данные “испортились” по каким-то чрезвычайным причинам).
   В-третьих, инкрементальная загрузка требует больших трудозатрат в поддержке и разработке (но она дает выигрыш в скорости).

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

4.2. Итак, после того, как Вы выгрузили данные из базы данных или облачного сервиса в QVD файлы, затем необходимо эти данные обработать (очистить, рассчитать показатели, агрегировать, обогатить дополнительными атрибутами, разметить флагами и т.д.) и положить обработанные данные в отдельный слой (например, DataTier1). Эти трансформированные данные Вы загружайте непосредственно в саму модель Qlik Sense или создаете ещё один дополнительный слой данных со сложными расчетами для конкретной модели данных.

Самое главное – не дублировать одинаковые данные в слоях. При повышении уровня слоя данные должны агрегироваться (группироваться). Нижние слои являются более общими, верхние слои – конкретно для каждой модели данных (или по направлениям анализа).

5. Проектируем слои приложения. Вот пример структуры аналитического приложения Qlik Sense:

• Дашборд (KPI, тренды, сигналы)
• Слой-аналитика (графики, диаграммы, пузырьки и т.п.)
• Слой-гибкий анализ / конструктор отчетов (Ad-hoc анализ)
• Слой детальные данные (Таблицы и сводные таблицы, подсвечиваемые поля, статические отчеты)

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

Пример прототипа на Qlik Sense:

6. Успешность проекта зависит от правильности организации по нескольким направлениям -данные, скрипты (написание, комментарии и т.д.), организация ETL, методологии расчетов:

• Качество данных – качество любого аналитического приложения в первую очередь зависит от того, насколько хорошо выстроены процессы фиксирования данных в учетных системах. Если в системах много дублей, много криво заполненных справочников, есть пустые документы, не проставлены те или иные атрибуты в справочниках, то очень много усилий придется потратить на то, чтобы собрать полноценную аналитическую модель с минимальными погрешностями в расчетах.
• Качество методологий учета, расчетов – прежде чем разрабатывать сложную модель для анализа или исследования данных, необходимо (хотя бы кратко) описать методологию расчетов. Можно все расчеты спроектировать в Excel и отдать его разработчику (иногда это самый подходящий и быстрый вариант).
  Что такое методология расчета? В первую очередь под этим я понимаю описание расчета того или иного показателя. Как в процессе расчета осуществляются группировки, как обрабатываем нули, как округлять данные, как обрабатывать деление на ноль и т.п. вопросы.
  В случае расчета суммы продаж методология расчета не требуется, а вот в случае расчета сопоставимых продаж за период (Like-For-Like) – требуется, т.к. возникает очень много вопросов. Или например как посчитать ROI по мероприятию или по акции. Самым лучшим решением – это когда бизнес-пользователь проделывает в Excel расчеты руками на одном клиенте, 1 акции (т.е. берет ограниченный объем данных и на нем строит модель, корректирует методику, делает проверку, утверждает ее со своим руководством или владельцем бизнеса и только потом отдает на автоматизацию расчетов). Но этот идеальный случай встречается редко и зависит от вменяемости бизнес-пользователя.
• Качество окружения QS (скрипты, изменения, аудит изменений, анализ загрузки ресурсов и т.д.) – от того, насколько правильно структурировано пространство QS, зависят накладные расходы на поддержку решения Qlik Sense. Очень важно оставлять комментарии в скриптах, создать инструмент для отслеживания процессов загрузки данных. Если сразу придерживаться строгих правил порядка, то потом при быстром масштабировании Вам будет легче управлять всей инфраструктурой.

Qlik Deployment Framework

Размышления консультанта “ВСЛУХ”

Возможно кому-то мои рассуждения покажутся “водой”, возможно кто-то сделает заметку, кто-то пройдет мимо, кто-то добавит в комментариях свои мысли. Главное – это просто мысли, мои заметки, которыми я хочу поделиться.

Об отчетах

В компании может быть все плохо, но отчеты об этом могут не говорить. Истинные проблемы начинают всплывать, когда компания начинает генерировать убытки.

В компании может быть 1-3 отчета и из них может быть многое понятно о текущих делах. А может быть десятки отчетов, из которых ничего не понятно (куда смотреть, с чем нужно работать, куда прикладывать усилия). Для работы с отчетами в таких случаях требуется штат аналитиков, которые будут сидеть и обрабатывать автоматически рассылаемые отчеты.

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

Качество приложения Qlik Sense

Качество приложения Qlik Sense зависит напрямую от качества ваших учетных данных. Очень хорошие данные (структурированные, без мусора, без дублирования, без двоякости и т.п.) = ОТЛИЧНОЕ ПРИЛОЖЕНИЕ QLIK SENSE.

Очень плохое качество данных (пропуски, дублирование, кривая инфа, несоответствия, пустоты, кривые справочники, кривые документы, 100500 способов представления одних и тех же отчетов, но с разными значениями) – ужасная аналитика, ужасный ETL, ужасное приложение, ужасный ROI от бизнес-аналитики?

Куча рассылаемых отчетов Excel – интерес руководителей, но не владельцев компании

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

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

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

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

Построить такой отчет очень сложно, т.к. нужно думать, гораздо проще придумать мудренную Excel с кучей столбцов и строк, которые зачастую между собой никак не коррелируют.

Создавайте базу знаний о бизнес-процессах в компании, делайте внутреннюю wiki

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

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

Приходит новый специалист и “исследовательская” работа повторяется снова.

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

1. При выходе на работу Вам приходит ссылка на обзорный курс про особенности бизнеса (компании), особенности рынка. Описываются основные бизнес-процессы (укрупненным планом). Описываются основные бизнес-термины. После прохождения курса можно пройти более углубленный курс, например, по расчетам тех или иных показателей бизнеса.
2. Возможность поработать 1 день на передовой бизнеса (фронт-офис) или посетить демо фронт-офис, в котором “как в жизни” можно понять что и как происходит.
3. При выходе на работу в первый день Вам приходит ссылка на страницу в wiki, где в неформальном виде описана вся движуха в компании, отделы и т.п. Неформальный стиль изложения – легкость восприятия информации.
4. Схемы, блок-схемы, потоки данных – иными словами наглядность информации, что происходит в компании.
5. Наличии системы управления требованиями, культура написания ТЗ. Когда Вам приходится искать то или иное требование в почте – это самое плохое, что только можно представить. А еще хуже, когда часть находится в почте, часть в мессенджере, часть в системе управления проектами и т.д.
6. База знаний запросов к системам. Один раз написали запрос – сохранили в базу с осмысленным заголовком и описанием, дальше другой сотрудник может этим запросом воспользоваться (если у него есть доступ к БД).

Здравый смысл

Оценивайте полученные результаты, показатели, отчеты на здравый смысл. Если Вы получили ROI = 500%, то очень вероятно стоит перепроверить (и желательно 2 раза) методику расчета показателя. Если показатель дает очень расплывчатый результат, то стоит ли этот показатель считать? Это как по популяции кроликов в южном округе оценивать спрос на мясо кроликов по стране. Проще потратить силы на отчет P&L, и понять откуда приходят деньги и куда уходят, чем заниматься пространственной аналитикой.

Методология расчета и реальная жизнь

Просите методолога/заказчика на основе его алгоритма сделать предварительный расчет в Excel. Так Вы сможете оценить жизнеспособность методологии расчета.
Разработка отчета в Qlik = 60 часов (например), предварительный расчет в Excel = 4-8 часов (со сбором данных)