Условия до старта проекта
Один из наших клиентов — крупная технологическая компания с разветвленной структурой. Ранее компания использовала систему Power BI, но после ухода Microsoft с российского рынка возникла необходимость перенести бизнес-процессы анализа данных на отечественное ПО. В качестве альтернативного решения заказчик выбрал систему PIX BI, и осенью 2022 года мы начали проект миграции и доработки аналитической системы. Ниже я по шагам расскажу, из чего состоял этот проект.
Проект включал в себя два основных этапа работ. Первый этап — это сама миграция с платформы Microsoft Power BI на новую платформу PIX BI. Второй этап — развитие системы: разработка новых отчетов и дашбордов для расширения возможностей аналитической системы внутри компании.
В первую очередь требовалось обеспечить доступ к новой системе пяти основным топ-менеджерам компании. Впоследствии количество пользователей постепенно увеличивалось. Также в ходе проекта было задействовано 12 аналитиков — это сотрудники, которые предоставляли информацию для разработки аналитической системы. С нашей стороны в проекте участвовали пять человек — основной разработчик, плюс еще один, которого привлекали в пиковые моменты, архитектор, аналитик и руководитель проекта. Основной упор в разработке аналитической системы был сделан на задачах по управлению финансами, активами и персоналом.
Детали реализации проекта
Для нас этот проект представлял интерес как один из первых опытов внедрения платформы PIX BI. На старте мы провели обследование заказчика, интервью с ключевыми специалистами компании, изучили особенности, проверили источники данных. Параллельно разворачивали платформу, настраивали и готовились к старту работ.
На этом этапе мы выявили ряд сложностей, которые были связаны со структурой компании. Группа компаний включала в себя множество организаций с разветвленной структурой, и каждое предприятие имело свою платформу 1С и свою систему учета. Кроме того, часть данных хранилась в Excel-файлах, и в компании не было единого хранилища.
![](https://vaiti.io/wp-content/uploads/2024/01/svetlyj-1_struktura-kompanii-1024x501.jpg)
На этапе обследования мы приняли решение алгоритмизировать и автоматизировать то, что возможно, и использовать 1С как основной источник данных. Для процессов, которые не подлежали описанию, источником данных оставили Excel. Хочу отметить важность этого этапа для дальнейшей работы, поскольку именно результаты, выявленные в рамках обследования, стали фундаментом для всего проекта.
На этапе миграции первоначальная задача заключалась в том, чтобы перенести данные из Power BI как есть. Однако мы немного доработали визуализацию по требованию заказчика, оптимизировали модель данных и некоторые другие детали, о которых я расскажу ниже.
Последний и основной этап заключался в разработке нового функционала. В рамках этого этапа было создано 15 новых дашбордов. Ранее они не были автоматизированы и существовали только в MS Excel.
Техническая архитектура проекта
Архитектура изначального BI-решения предполагала извлечение данных из различных 1С-систем, которых было порядка 58 штук в более чем 23 компаниях внутри одной группы.
Для того чтобы данные собирались консолидированно, был поднят специальный веб-сервис. Некоторые другие данные собирались из Excel-файлов, которые обновлялись вручную. За сбор и трансформацию всех данных отвечал ETL-инструмент Power Query, а дальше Power BI строил аналитические отчеты и дашборды.
![](https://vaiti.io/wp-content/uploads/2024/01/svetlyj_2_ishodnaya_realizacziya_na_power_bi-1024x618.jpg)
В процессе внедрения мы разработали промежуточную версию интегрированного BI-решения. Поскольку проект начался на ранних стадиях развития системы PIX BI, нам пришлось прибегнуть к использованию стороннего ETL Apache Airflow. Мы легко интегрировали Python-скрипты, которые уже использовались в Power Query, с помощью Apache Airflow, который также работает на языке Python и хорошо его понимает.
Некоторую функциональность, которая была доступна в Power BI, мы также реализовали на Python и интегрировали в Apache Airflow. Дополнительно настроили общедоступную директорию на сервере для всех выгрузок, чтобы информация была собрана в одном месте. Вся эта информация передавалась в промежуточное хранилище данных PostgreSQL, а оттуда PIX BI уже считывал информацию и строил аналитические отчеты.
![](https://vaiti.io/wp-content/uploads/2024/01/svetlyj_3_promezhutochnaya_realizacziya_na_pix_bi-1024x517.jpg)
Финальная архитектура была внедрена спустя два месяца с момента первой промежуточной версии. Часть, связанная с базой данных, веб-сервером, ручной выгрузкой и общедоступной директорией, осталась неизменной.
Основные изменения произошли в хранилище и ETL. Команда PIX разработала собственный ETL, который полностью заменил сторонний софт и позволил бесшовно перенести все процессы из Apache Airflow на решение PIX BI ETL. Кроме того, вендор реализовал функцию регламентного обновления данных по расписанию, которая сегодня востребована на многих проектах.
![](https://vaiti.io/wp-content/uploads/2024/01/svetlyj_4_finalnaya_arhitektura_resheniya_na_pix_bi-1024x497.jpg)
СУБД PostgreSQL была заменена на проприетарное хранилище ClickHouse, которое имеет встроенное решение для хранения и обработки данных (DWH), что позволяет с легкостью создавать и управлять хранилищем данных. Кроме того, производительность хранилища выросла как минимум в 6–8 раз по сравнению с предыдущим решением. Это значительно сократило время, необходимое для загрузки данных и генерации отчетов, и привело к повышению эффективности работы.
Взаимодействие с вендором
Хочется также рассказать про взаимодействие с командой PIX BI. На протяжении всего проекта мы шли с вендором нога в ногу. При каких-то малейших запросах от заказчика или от нас команда вендора максимально оперативно решала эти задачи. Если вопрос касался небольших доработок, то его решение занимало 1–2 недели. В случае критических запросов или серьезных ошибок вопрос решался за 1–2 дня. При выполнении серьезных крупных доработок срок ожидания составлял в среднем от 2 до 4 недель.
Безусловно, разработчики вендора реализовывали многие функции оперативнее, чем это планировалось в дорожной карте. Проект стал практическим подтверждением той идеи, что взаимодействие с российскими вендорами намного проще и эффективнее, чем с зарубежными. Мы, по сути, получили возможность реализовать задачи, которые с тем же Microsoft реализовать было бы невозможно.
Обучение
В наших проектах мы стараемся вовлекать пользователей в работу с новой системой как можно раньше, и этот проект не стал исключением. Ключевых пользователей мы обучили работе с платформой PIX BI на старте проекта, когда появились первые дашборды, мигрированные с Power BI.
Такой подход позволяет нам провести более качественное пользовательское тестирование и получить эффективную обратную связь по интерфейсу и функциям новой системы. Это также способствует формированию сетевого эффекта: пользователи привыкают использовать систему в своей повседневной жизни. К моменту финальной демонстрации решения заказчику ключевые пользователи уже достаточно хорошо знают платформу, и она не вызывает у них вопросов.
Результаты проекта
Первоочередной задачей, которая стояла на старте проекта, был отказ от Excel, в которой подразделения демонстрировали свои бюджеты и дашборды высшему руководству компании. Внедрение PIX BI в полной мере решило эту задачу. Помимо этого, мы оптимизировали модель данных на этапе миграции, что позволило увеличить скорость формирования отчетов в несколько раз, а также настроить хранение исторических данных. Такой функциональности изначально не было в Power BI, заказчик мог смотреть данные на текущий день, однако не мог анализировать их за прошедший период. Сейчас аналитические данные автоматически накапливаются, и мы также подгрузили исторические файлы, которые были у заказчика.
Отказ от ручной подготовки данных — стандартная функция внедрения любой BI-системы, и в данном проекте это также произошло. А вот погружение сотрудников заказчика в BI-систему за счет функционала self-service — это частное преимущество платформы PIX BI, которая предоставляет возможность самостоятельного редактирования дашбордов.
Пока аналитики заказчика еще не дошли до уровня создания собственных дашбордов, однако уже имеют такую возможность и могут как минимум настроить фильтры или персонализировать дашборды, созданные нами.
Мы продолжаем поддерживать данного заказчика, и точка в работе еще не поставлена. Хороший BI-проект не должен заканчиваться: с помощью ИТ-интегратора или внутренней команды разработки BI-система должна развиваться и быть настолько же динамичной, как и сам бизнес.
Рекомендации и выводы
Резюмируя те подходы, которые мы применяли (как организационные, так и технические), хочу дать некоторые рекомендации для подобных проектов.
Привлечение всех заинтересованных сотрудников в проект. Чем больше потенциальных пользователей будут вовлечены на старте, тем быстрее удастся подойти к решению именно их задач и к достижению поставленных целей.
Формализация требований критериев успешности. Это применимо ко всем проектам: если мы на старте знаем, к чему должны прийти, мы будем четче понимать, как к этому двигаться, и, соответственно, риски не попасть в сроки минимизируются. В случае с миграцией это особенно важно, поскольку всегда есть риск лишиться текущей системы, если лицензию к зарубежной платформе не удастся продлить.
Внутренний аудит текущей системы. Когда мы говорим, что перенос BI-системы — сугубо технический процесс, это действительно так. Однако если понимать это буквально, то можно перенести не только BI-систему, но и все ошибки и недочеты, которые накапливались в ней годами. Поэтому критично важно сначала провести ревизию имеющегося аналитического инструмента. Это позволит перенести всё без ошибок, а также сразу перейти к развитию новой системы.
Работа по Agile. Agile — в принципе тот подход, который мы пропагандируем, и при вовлечении заказчика он действительно работает. Мы практически ежедневно предоставляли заказчику результаты работы, которые позволяли понять, в правильном ли направлении мы движемся. Это позволило нам избежать ситуации, когда спустя два месяца разработки пришли функциональные заказчики и сказали, что это вообще не то, что нужно. Такие ситуации можно нивелировать Agile-подходом.
Обучение пользователей. Да, обучение нечасто проводится на старте, но именно это позволяет обеспечить всё то, что я озвучил ранее: вовлечение людей, понимание, чего мы от них хотим и для чего им самим нужна эта система, возможность предлагать какой-то новый функционал. Всё это в итоге приводит к тому, что проект живет, аналитика работает и сама система действительно приносит бизнес-пользу, а не просто является «цифровизацией».