Содержание
Миграция с зарубежной платформы Power BI на отечественные решения
Условия до старта проекта миграции
Характеристика клиента
Заказчик – группа компаний с достаточно разветвленной внутренней структурой. Сотрудничество с компанией-интегратором «Первый Бит» офис Спортивная началось осенью 2022-го года с постановки задачи миграции и доработки аналитической системы.
В группе компаний много организаций, часть из них – разветвленные, и в каждой компании была развернута своя платформа 1С и своя учетная система. Эти системы либо похожи, но имеют определенные нюансы в каждой компании, либо принципиально разные. Это создавало свои сложности для построения единой аналитической системы.
Этапы проекта
Проект был разбит на 4 этапа:- Установочный этап– 2 недели.
В рамках установочного этапа эксперты интегратора осуществили экспресс-обследование компании, провели интервью с ключевыми специалистами, выявили особенности, проверили источники данных, составили техническое задание и план-график. - Разворачивание платформы – 2 недели.
Параллельно с установочным этапом шло развертывание платформы, подготовка к старту работ, активация лицензий, настройка и т.п. - Миграция отчетов Power BI – 2,5 месяца.
Первоначальная задача заключалась в полном переносе отчетов один в один, но затем заказчик согласился на предложение интегратора улучшить визуализацию, оптимизировать модель данных и немного поменять несколько деталей. На платформу PIX BI было мигрировано 4 дашборда и модель данных. - Разработка нового функционала – 2 месяца.
Это этап развития, в рамках которого было разработано 12 дашбордов нового приложения. Ранее они не были автоматизированы и формировались в Excel, теперь же они генерируются на платформе PIX BI.
- Отсутствие единого хранилища данных;
- Основной источник данных – 1С, часть данных поступает из Excel;
- У каждой компании своя 1С и разная учетная политика;
- Нет фиксированной структуры группы компаний;
- Решение о внесении и исключении данных принимаются в ручном режиме.
Этот этап был важен для проекта, потому что на весь проект повлияли именно результаты, выявленные в рамках экспресс-обследования, и на данном этапе были приняты основные решения.
Основные показатели, которые анализировались в рамках финансовых дашбордов:
- Операционная выручка.
- EBIDTA.
- Чистая прибыль.
- Операционная ликвидность.
- Кредитный портфель.
- Денежные средства.
- Активы.
- Ключевые клиенты.
В рамках аналитики персонала использовались показатели:
- Динамика численности персонала группы компаний.
- Динамика численности персонала по компаниям группы.
- Количество открытых вакансий.
- Текучесть кадров.
- Оргструктура и штатное расписание.
Техническая архитектура проекта
Рассмотрим архитектуру проекта с двух сторон: как было на платформе Microsoft Power BI и как стало на PIX BI.Исходная реализация на Power BI
Архитектура первоначального BI-решения, которое было развернуто у заказчика, предполагала, что данные забираются из разных 1С каждой из компаний, входящих в группу. Также данные собирались из небольших Excel-объектов – из некоторых выгрузок, справочников, в которых постоянно менялась информация.
За сбор и трансформацию данных отвечал ETL-инструмент для продвинутого бизнес-анализа Power Query, предназначенный для подключения к источникам данных и их преобразования. Построение аналитических отчетов и дашбордов обеспечивал инструмент Power BI.
Реализация на PIX BI
В ходе внедрения кейса была разработана первая, промежуточная версия интегрированного BI-решения. Проект стартовал на ранних этапах развития системы PIX BI, поэтому использовался – сторонний ETL-компонент - Apache Airflow.
При этой миграции получилось легко интегрировать Python-скрипты, которые уже были в Power Query, и ETL-компонент Apache Airflow – учитывая, что он работает на Python и отлично понимает этот язык.
Системой хранения выступила PostgreSQL, которая позволила накапливать исторические данные и расширить возможности для анализа.
Финальную архитектуру интегрировали спустя два месяца после первого промежуточного решения. Часть, относящаяся к базе данных, веб-серверу, ручной выгрузке и общедоступной директории, не изменилась. Основные изменения произошли в части хранилища и ETL-компонента Apache Airflow. Команда PIX разработала собственный ETL-инструмент, который позволил полностью нивелировать сторонний софт и бесшовно перенести все эти процессы с Apache Airflow в собственный PIX BI ETL. Что немаловажно, было реализовано регламентное обновление данных по расписанию – это очень полезная функциях, востребованная на всех проектах. В PIX BI можно задавать правила обновления по группам данных, указав периодичность, с которой система будет актуализировать информацию.
СУБД PostgreSQL заменили на проприетарное хранилище ClickHouse. У него есть следующие ключевые преимущества:
- Собственный DWH.
- Скорость загрузки данных и построения отчетов выросла минимум в 6-8 раз согласно замерам.
- Возможность пользователям не владеть сторонними языками программирования, такими как Python и т.д., поскольку если данные предподготовлены на уровне БД, нет необходимости знать языки программирования. Нативного интерфейса вполне хватает для того, чтобы загрузить таблицы, построить модель и сформировать свой отчет. Если нужно осуществить минимальные преобразования или добавить функции, есть окно с SQL, где можно прописать все необходимые скрипты. Интерфейс выполнен максимально дружелюбным.
Обучение сотрудников
В рамках внедрения или миграции на новый для сотрудников софт, одним из важнейших этапов является обучение ключевых пользователей на старте проекта. В рамках текущего кейса основные пользователи системы прошли обучение и получили инструкцию на начальном этапе, когда появились первые дашборды, мигрированные из Power BI.Такой подход дает возможность провести более качественное пользовательское тестирование, получить эффективную и быструю обратную связь по интерфейсу и функциям. Также это способствует привыканию сотрудников использовать систему в обычной жизни.
Обучение – это неотъемлемая часть проекта. На финальной демонстрации было заметно, что ключевые пользователи уже были качественно погружены в работу с системой, у них не осталось вопросов. Обучение технических специалистов в данном проекте было сокращенным, поскольку не стояла задача поддерживать решение самостоятельно – достаточно было обучить IT-специалистов заказчика минимальной поддержке и работе с лицензиями.
Особенности миграции на PIX BI
В процессе миграции возникли следующие трудности:- Оптимизация скриптов. Доработка скриптов для того, чтобы они работали более оптимально и загрузка происходила быстрее.
- DAX. Часть функционала, который был реализован в Power BI, пришлось интерпретировать с формульного языка DAX на язык Python и интегрировать в Apache Airflow. DAX позволяет создавать запросы к исходной модели данных, брать из нее необходимые отфильтрованные данные и производить с ними вычисления, на основе которых появляется возможность создавать интерактивные BI-отчеты. Остальная часть этих формул была реализована на формульном мета-языке самого PIX BI. Язык формул PIX Meta позволяет гибко управлять фильтрацией на уровне функций агрегаций (sum, count, max, min и проч.), выполнять сброс фильтров, расчет итогов и подитогов.
Транзит с Excel в общедоступную директорию был осуществлен таким образом: на сервере заказчика была создана специальная папка, к которой был настроен общий доступ для всех компаний. В эту папку как в облачное решение можно было загружать все Excel-файлы. Единственным ограничением было то, что они должны называться по определенному шаблону-маске, и структура этих файлов достаточно статична: количество и наименование полей должно соответствовать шаблону. Если возникали какие-то изменения в структуре, после их согласования с заказчиком, интегратор вносил их на уровне кода.
На этом этапе формы ввода не применялись, они понадобились на более поздних этапах, когда был разработан новый функционал. На этапе миграции формы ввода были не нужны, за исключением одного справочника, где вводилась динамичная структура группы компаний. Это актуально в случаях, когда, например, одну компанию купили, другую продали, либо поменялось наименование компании, ИНН и т.д. Основные формы ввода появились уже на этапе внедрения нового функционала.
На этапе развития платформы был добавлен функционал форм ввода. Они являются не итоговой версией, а временным ограничением, потому что у заказчика еще не вся информация консолидирована, структурирована и собрана в базу данных и 1С. Поэтому, как только заказчик решит эти задачи, будет осуществлена полная автоматизация решения. Ручная выгрузка в общедоступную директорию перестанет быть актуальной, останется только база данных 1С, веб-сервер и непосредственно PIX BI.
Результаты проекта и факторы успеха
По итогу проекта удалось выполнить все задачи: функционал зарубежной BI-платформы был замещен PIX BI и расширен дополнительными отчетами, с помощью которых топ-менеджмент анализирует показатели группы компаний.Также можно отметить следующие результаты:
- Оптимизация модели данных при миграции позволила увеличить скорость формирования отчетов в 6 раз.
- Хранение исторических данных. Первоначально в Power BI не было возможности собирать и хранить данные, и заказчик мог смотреть данные только на текущий день. Анализировать прошедшие периоды было невозможно. Сейчас накапливаются новые данные, загружены исторические файлы, которые были у заказчика. Исторические данные хранятся 5 лет, что позволяет их анализировать и строить прогнозные модели.
- Освобождение от ручной подготовки – это стандартная функция внедрения любой BI-системы. 5 сотрудников было освобождено от ручной подготовки и консолидации данных.
- Погружение и вовлечение сотрудников заказчика в BI за счет функционала self-service – это преимущество именно PIX BI, потому что это решение предоставляет возможность самостоятельного редактирования дашбордов, настройки персональных дашбордов. Пока что аналитики заказчика не дошли до уровня создания своих дашбордов, но, как минимум, настроить фильтры или персонализировать дашборды, разработанные интегратором, они на данном этапе способны самостоятельно. В итоге по сравнению с прежним периодом в 3 раза больше сотрудников вовлечено в работу с BI за счет нового функционала и self-service. Интегратор продолжает оказывать техническую и консультационную поддержку.
Рекомендации по миграции BI-системы
- Вовлечение всех заинтересованных сотрудников сразу в начале проекта. Чем больше потенциальных пользователей системы будет вовлечено на старте, тем больше команда разработки приблизится к решению именно их задач, и тем четче и быстрее она будет идти к достижению целей. Не будет ситуаций, когда разработчикам нужно будет откатываться назад.
- Формализация всех требований и критериев успешности до начала разработки. Это применимо ко всем проектам. Если на старте знать, к чему нужно прийти, это дает понимание, как двигаться к финалу. Минимизируются риски не попасть в сроки. В частном случае миграции есть риск лишиться текущей системы – как минимум, потому что есть большие проблемы с получением лицензий к зарубежным платформам. В том числе из-за этого данный этап крайне важен.
- Проведение внутреннего аудита текущей системы до миграции. Перенос BI-системы – это сугубо технический процесс, но, в то же время, нельзя допустить переноса в новую BI-систему всех ошибок и недочетов, которые годами накапливались в предыдущей системе. Проведение ревизии своего аналитического инструмента позволит перенести все данные без ошибок и, соответственно, сразу перейти к развитию. Избавившись от чего-то лишнего, можно даже сократить сроки и трудозатраты.
- Разработка спринтами. Вовлечение, аудит и ориентация PIX BI на self-service позволяет аналитику разрабатывать проект спринтами. Этот подход эффективно работает при вовлечении заказчика. Интегратор практически ежедневно предоставлял заказчику результаты проделанной работы, их можно было протестировать, понять, что они соответствуют ожиданиям или дать какие-то комментарии и рекомендации, которые интегратор мог быстро применить. В противовес можно поставить пример, когда спустя два месяца после разработки пришли пользователи – непосредственно функциональные заказчики – и сказали, что полученная система представляет собой совсем не то, что они хотели. Для нивелирования таких ситуаций подход спринтов оптимален.
- Обучение пользователей работе с системой до начала внедрения и тестирования. Это дает возможность вовлечь людей и дать им возможность разобраться, в чем их задачи в процессе миграции. Они начинают понимать, зачем им нужна новая система и в ходе проекта даже предлагают какой-то новый функционал. Это в итоге приводит к тому, что система и аналитика действительно приносят бизнес-пользу, а не просто внедрены для галочки.
