Андрей Фетисов
Специалист поддержки пользоватлей ИТ
Приветствую вас коллеги на Хабре. Меня зовут Андрей Фетисов, за последние 10 лет успел поработать специалистом техподдержки SAP ERP, администратором СЭД, менеджером хелпдеск Landesk Ivanti, экспертом по документообороту WSS Docs, руководителем проекта 1C Битрикс 24, руководителем направления JIRA, Confluence в проектном офисе ПУД.
Я расскажу о личном опыте разработки дашборда и “граблях”, на которые наступал. Этот текст будет интересен тем, кто хочет больше узнать о Data Driven и Data Governance Dashboard. Здесь я провожу работу над ошибками и разбираю проблемы с которыми столкнулся, а именно подходы к разработке метрик и автоматизации их сбора. Надеюсь статья послужит шпаргалкой по созданию дашбордов и позволит изучить новые технологии их разработки, в том числе, благодаря вашим комментариям.
Содержание
Дашборд как приборная панель автомобиля
Обязательные требования к дашборду
Глоссарий
Полезные ссылки по теме
Дашборд как приборная панель автомобиля
Я использую такое определение дашборда, это инфопанель с показателями эффективности отдела, которые рассчитываются автоматически с необходимой периодичностью.
Мне понравилось это объяснение сути дашборда. Он должен в понятной форме показывать ключевые показатели эффективности. Например, в финансовом отделе, это бюджет и его утилизация по аналогии со спидометром и тахометром, или в отделе внутреннего сервиса количество тикетов всего и закрытых вовремя по аналогии с датчиком топлива. Если продолжить эту аналогию, то принять управленческое решение значило бы заехать на заправку.
Обязательные требования к дашборду
Заказчиком дашборда был глава ИТ департамента. Руководитель проектного офиса провёл брейншторм с главой ИТ департамента и нарисовал результат на доске MIRO. Из MIRO я взял направления деятельности и названия отделов и ответственных за предоставление данных.
Схему без персональных данных можно рассмотреть в MIRO по ссылке.
Схема показывает кто и какую информацию предоставляет главе ИТ департамента. Будущий дашборд мы назвали “Ревью ПУД”.
Я взял за основу алгоритм создания дашборда Романа Бунина (руководитель команды визуализации данных яндекс такси). Затем сформировал проектную команду по основным ролям: заказчик, аналитик, разработчик и приступил к написанию ТЗ. Из MIRO удалось получить 5 направлений с вложенной иерархической структурой по видам деятельности, которых оказалось 21 и общее количество метрик составило 51.
Файл с разбивкой метрик по направлениям деятельности можно найти в моем пространстве WiKi в Confluence.
Затем я сделал в Trello пошаговую декомпозицию со следующими требованиями к дашборду:
Разработать метрики по которым можно судить об успешности отдела.
Создать базу данных для метрик с формулами расчета и ответственными.
Сделать умную форму для внесения ручных метрик. Это метрики, которые вы только разработали и внедрили, но они еще не автоматизированы.
Система контроля внесенных метрик, которая бы показывала ответственных и сроки внесения. Чтобы быстро можно было ответить на вопрос: Кто еще не внёс значения, а также проверить актуальность внесенных данных.
Grabber данных, который бы забирал значения метрик, если они уже рассчитываются в любой существующей системе учета данного отдела.
Parser который обрабатывает полученные данные согласно правилам расчета метрик.
При этом я уже ранее задокументировал бэкэнд дашборда Data Governance Dashboard в Ростелеком. Там эти пункты уже были реализованы. Взял имеющиеся инструменты: Power BI, IBM DataStage и добавил Sharepoint. Для заполнения ручных метрик по каждому ответственному сделал веб-форму в InfoPath под SharePoint. Форма работала в браузере и показывала метрики по каждому ответственному, который открывал форму под своим логином Active Directory.
Чтобы быстрее понять куда двигаться дальше, решено было сделать рабочий прототип и показать заказчику. Я нарисовал в Confluence в аддоне gliffy (уже переделал в diagram.draw.io для своего тестового сайта) такой макет:
По ссылке ниже, вы можете просмотреть и отредактировать этот макет Flowchart Maker & Online Diagram Software
Затем создал синтетические данные в excel по каждой метрике и экспортировал в список sharepoint. Получилась готовая база с которой я уже смог прийти к разработчику PowerBI.
Это позволило за месяц создать рабочий прототип и показать стейкхолдеру - нашему руководителю ИТ департамента.
Для наглядности нарисовал такой бизнес-процесс по сбору ручных метрик:
Вы можете исправить этот макет для своих целей по ссылке: Flowchart Maker & Online Diagram Software (вообще, горячо рекомендую этот онлайн редактор диаграмм).
Пожалуйста, напишете в комментариях как вы автоматизировали сбор данных в SQL или другую БД и как там реализован Grabber и Parser?
Глоссарий
ПУД - Подразделение управления данными.
Метрика - Показатель выполненных работ, рассчитывается по формуле и выражен в разных единицах измерения и вариантах визуализации.
KPI - Key Performance Indicators или основные показатели эффективности. На хабре есть обзор программ для отслеживания KPI Обзор программ KPI-автоматизации / Хабр.
Dashboard - Дашборд это инфопанель с метриками по которым видно на сколько эффективно работает отдел.
ETL - Extract Transform Load методология извлечения данных из базы и последующая отправка в базу. Подробнее Сравнение процессов ETL и ELT.
Grabber - Грабер предназначен для извлечения данных из базы.
Parser - парсер это обработчик выгруженных данных из базы.
Data Governance - Регулирование данных (источник, кто владелец, кто модифицирует). Побывал на митапе Ростелеком Сам себе дата-инженер: открыта регистрация на митап Ростелеком х Qlik 2 сентября и поделюсь в следующей статье инструментами DG.
Data Driven - Управляемый данными, подход в управлении, основанный на данных. Подробнее встреча с Кириллом Меньшовым главой ИТ Ростелеком: Нельзя просто взять и влиться в data-driven — на что обратить внимание при внедрении такого подхода.
plotn1
Доброй ночи. Скрин с пунктом "DG (не понимаю пользы)" доставляет)
aendrous Автор
Видимо, потому, что у нас уже был один DG dashboard, а тут предлагалось переиспользовать данные из него )