Всем привет, я Сергей Бондарев, Директор по управлению данными и директор по аналитическим решениям ПГК, и сегодня хочу поделиться нашим опытом по поводу построения у нас Self Service BI. При подготовке материала я специально не читал никаких книжек и статей по этой теме, чтобы поделиться исключительно своим опытом, добытым различными экспериментами, в основном удачными.

В 2022 году мы спроектировали и построили платформу данных, включающую хранилище с механизмами доставки данных, систему управления справочной информацией, BI систему, включая Self Service. В совокупности всё это должно было обеспечить наши команды набором инструментов, необходимых для разработки функционала цифровых продуктов, продуктовой, проектной и пользовательской аналитики. При этом, уже на этапе сбора требований к проектированию BI платформы сложилось понимание высокого потенциала аналитики, разрабатываемой пользователями самостоятельно.

Перевозка грузов по железной дороге – это сложный процесс, включающий в себя тщательное планирование и координацию всех этапов. В нашей компании используется порядка 150 основных показателей перевозочной, коммерческой, финансовой деятельности, обеспечения технического состояния вагонного парка.  Оперирование является довольно сложным бизнесом, и для эффективного управления необходимо постоянно учитывать изменяющиеся условия на базе своевременной аналитики.

Поэтому в нашем случае Self Service решения - это не очередная модная тенденция, а шаг эволюции в развитии ИТ, обусловленный развитием ИТ - компетенций в различных подразделениях компании. Использование языков программирования нашими экономистами, аудиторами, финансистами в своей работе является нормальной практикой. Это не констатация факта о продвинутости наших сотрудников, а про то, что уже длительное время размывается граница между ИТ и не-ИТ компетенциями. Бизнес-аналитики ИТ знают предметные области зачастую наравне с бизнес-экспертами профильных функций, в то время как бизнес-эксперты могут владеть Python или SQL на уровне ИТ-разработчика. В современной организации разделение ИТ и бизнес-подразделения происходит зачастую на не границе компетенций, а на границах процессов.

В области работы с данными это проявляется наиболее заметно и означает смену парадигмы из ранее распространенного ожидания заказанного функционала месяцами через “единое окно ИТ” в область децентрализации и возможности самостоятельно создавать нужный для работы функционал. Очевидно что крупная автоматизация, связанная с созданием новых предметных областей, доработками источников, создаётся в ходе целевых проектов. Но на уже существующих данных вполне можно собирать аналитику собственными силами, это значимо экономит ресурсы ИТ и увеличивает скорость получения эффектов.

При проектировании целевого вида нашего Self Service BI мы руководствовались принципом того, что недостаточно запустить install.exe какого-нибудь выбранного BI, написать многостраничное положение о том, что ИТ ни за что не отвечает, и предоставлять доступ к среде с условием его подписания. Так не работает. Относительно предназначения функции данных, её руководитель в любом случае будет нести ответственность за всё что бизнес разработает и будет презентовать на своих внутренних площадках, руководству, другим функциям. Self Service с самого начала своего построения не должен являться автономной системой без правил. Поэтому для нас Self Service это дополнительная среда BI, с адаптированными под бизнес-пользователей процессами и правилами разработки и доступа. В общем виде Self Service мы видим не как ИТ инструмент, а как процесс, который можно условно отобразить на диаграмме ниже: мы предоставляем всем пользователям навигатор по разработанному функционалу, желающих создавать собственный инструментарий учим разработке, предоставляя информацию о данных и методологическую поддержку. А далее, для создавших уже массовый инструментарий, предоставляем процессы и правила по опромышливанию и переезду на продуктивный контур, где приложения будут обеспечены сопровождением и гарантированной производительностью среды.

К концу 2023 все составляющие этого процесса были разработаны и паззл сложился. Как я отметил, основная концепция это предоставление разработчикам из числа бизнес-пользователей описанных данных посредством карты данных и реестра показателей, развитие их компетенций посредством регулярного обучения, обеспечение средствами разработки. При этом мы с самого начала должны предусматривать, что ряд пользовательских команд сделает инструменты, которыми будет делиться с другими пользователями, другими словами ряд функционала станет массовым. А это означает что все источники в таком функционале должны быть целевыми, показатели правильно посчитанными, а код должен быть описан и документирован так, чтобы каждый из аналитиков компании мог понять, как именно формируется конечный отчёт. Поэтому мы приходим к тому, что процессы и правила разработки, включая требования по категорированию информации, также должны быть разработаны и заявлены командам на самом раннем этапе. По сути наши требования к командам, которые вышли из уровня песочницы на уровень разработки массового инструмента, становятся такими же, какие мы предъявляем к своей ИТ-команде.

Ну и основные показатели приживаемости нашего процесса: За прошедший год мы обучили свыше 250 сотрудников на наших внутренних курсах. В разработке у нас работает порядка 30 команд бизнес-пользователей, из них шесть команд создают полноценный массовый инструментарий и снабжают всех сотрудников компании аналитикой по основным производственно-коммерческим показателям, суммарно высвобождая порядка 330 часов в день времени сотрудников, ранее затрачиваемое на поиск необходимых данных. Таким образом, можно утверждать, что процесс работает и приносит измеримые результаты. Про стек выбранного нами инструментария вы можете узнать из моей предыдущей статьи, отдельно отмечу что у нас полностью своя экспертиза в развитии и сопровождении эксплуатируемого нами инструментария. Наряду с очевидными преимуществами это даёт возможность внедрения быстрых изменений на основании запросов нашего рынка - разработчиков команд.

Для обеспечения технического базиса всего процесса BI платформа должна отвечать критериям масштабирования, стабильности и гибкости в управлении. Поэтому мы спроектировали и внедрили BI платформу со следующими особенностями:

Мы остановились на многоузловом развертывании системы, которое, благодаря набору возможностей, позволило развернуть несколько узлов, выполняющих различные функции и с различным уровнем сервиса на едином репозитории данных. Сейчас у нас развернуты среды Продуктива, Self Service, Разработки. При этом наша конфигурация позволяет добавление иных сред под конкретные задачи, например, для обработки конфиденциальных данных, персональных данных сотрудников, отдельных филиальных сред с необходимыми мощностями под конкретное назначение. Такая конструкция имеет ряд преимуществ:

• Обеспечивается существенное снижение времени и затрат на подключение новых источников данных. Единожды подключенная структура данных становится доступной для всех сред одновременно, с учётом условий разграничения доступа;

• За счёт использования единых данных для всех сред устраняются инциденты, связанные с рассинхронизацией данных, различным регламентом их обновления в различных средах;

• Обеспечивается существенная экономия ёмкости под данные;

• Модели данных, создаваемые в рамках целевых ИТ-проектов, доступны другим командам, в том числе и на других средах без дополнительной разработки;

• Достигается значимая экономия ресурсов благодаря консолидации и отсутствию нескольких независимых инсталляций, в частности обслуживание, пользовательская поддержка, поддержка процессов миграции/синхронизации.

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

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

Таким образом, с помощью Self Service как процесса, за относительно сжатый срок мы демократизировали наши данные, оптимизировали и упростили их сбор и анализ, сделали работу с данными наглядной и понятной. В планах этого года я вижу развитие кооперации с командами, производящими массовый инструментарий, по валидации используемых источников и расчётных показателей, опромышливанию массового функционала.

Делитесь в комментариях своим опытом внедрения Self Service BI.