До весны 2022 года для глубокой бизнес-аналитики мы применяли традиционные зарубежные решения. После ухода с отечественного рынка западных вендоров у нас встал вопрос о полной их замене. Меня зовут Андрей Первушин, архитектор BI-решений в «Северсталь-инфокоме». Сегодня я хочу поделиться методикой подбора отечественной BI-системы. 

Для SAP-центричных задач в live-режиме, где все данные собираются в хранилище SAP BW4/HANA, мы использовали SAP Analytics Cloud. Для производственного и прочих хранилищ, а также для ценителей PBI Self-service использовали Power BI. После ухода вендоров мы сначала приземлили облачное решение SAP Analytics Cloud на платформу SAP Business Objects. Но вскоре начали поиски замены. 

У нас уже был опыт исследования множества продуктов под задачу, а также эксплуатации этих продуктов по итогам. Был и опыт использования популярных отраслевых решений, в которых вендор сильно переоценил возможности своей системы. Мы изучили исследования BI-интеграторов и таких консалтинговых компаний, как PWC, Glowbyte, BI Consult, Cnews. А ещё заметили, что крупные компании практикуют использование Open Source, и ознакомились с аналитикой этого опыта.

В итоге мы пришли к выводу, что понимание сути и сложности задач у вендора, исследователей и эксплуатирующих команд могут кардинально различаться. Те, кто постоянно нас читают, знают о нашей дотошности и поэтому не удивятся, прочитав, что мы приняли решение самостоятельно и тщательно изучить предлагаемые отечественным BI-рынком продукты. Кстати, мы были приятно удивлены — их оказалось достаточно много: более дюжины. При этом явных лидеров не было. Что ж, где наша любимая большая лупа?

Исследование отечественного BI-рынка

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

Для удобства мы разделили исследование на этапы:

1. Подготовка кандидатов, команды, демосреды и данных.

2. Сбор данных от поставщика.

3. Развёртывание демостенда.

4. Тестирование на демосреде.

5. Обратная связь поставщику и участникам.

Вот что мы делали на каждом из этапов.

Этап 0. Подготовка кандидатов, команды, демосреды и данных

Это подготовительный этап, который не включает в себя привлечение вендоров. Он довольно длинный и состоит из нескольких подпунктов, но, пройдя его, вы будете готовы к «конвейеру» по тестированию множества однотипных систем. Не благодарите. 

Вначале на основе имеющихся материалов чужих исследований мы составили список BI-систем, ранжированный по важным для нас критериям. У каждого критерия был выставлен свой вес. Например, важным условием была хорошая совместимость с текущим ландшафтом, поэтому системы, удовлетворяющие ему, мы отнесли к первой волне «испытуемых». В неё вошли 5 систем, в следующую волну — ещё 9.

Формируем команду

Минимальные компетенции для команды:

• Специалист по архитектуре BI-систем. Надо прописать компетенции. В нашем случае были ценны компетенции по аналитическим хранилищам, серверам приложений, аутентификации, авторизации, технологиям визуализации и анализа данных.

• Специалист по функциональности BI-систем. Здесь хорошо бы понимать конкретику. Нам нужен был умелец по построению визуализаций в BI-системах и изготовлению аналитических приложений. 

Готовим опросник для производителей и поставщиков

У нас получился Excel-файл из более чем сотни пунктов, поделённый на ключевые блоки: 

• функциональность;

• безопасность;

• стоимости лицензий и поддержки;

• сайзинг системы под продуктивное количество пользователей и разработчиков.

 Нужно обязательно точно указать количество пользователей для расчёта лицензий, а также требования к Disaster Recovery и High Availability для расчёта железа.

Договариваемся со специалистами информационной безопасности

Очень важно привлечь службу информационной безопасности (ИБ) к ключевым этапам исследования, погрузить коллег в тему. Это поможет избежать многих проблем в будущем.

 Ключевые моменты к обсуждению:

• организация процесса исследования в целом, спектр задач;

• процедуры проверки дистрибутивов;

• допустимые системы-источники, доступы к ним и информация, какие данные можно вовлекать. 

Договариваемся с администраторами базовых сервисов

Нам (вам) потребуются специалисты по базовым сервисам. Это 1–2 сотрудника, с которыми будет постоянный контакт для решения вопросов по развёртыванию виртуальных машин, установке ПО и открытию доступов. Эти же задачи можно решать и через обычные заявки, но тогда процесс может затянуться. 

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

Готовим песочницы систем-источников

Заказываем копии систем или находим такие системы, которые сможем подключить к тестовым стендам в качестве источников. Необходимо вовлечь наиболее критичные типы систем, которые вы используете продуктивно. 

У нас это были копии SAP BW4/HANA и Oracle с минимальными наборами обезличенной информации. Они использовались в качестве основных хранилищ данных. В этих системах не должно быть данных, критичных с точки зрения ИБ. Также можно дополнительно подготовить Excel-файлы с данными для простых тестов.

 Оформляем доступ к системам-источникам для команды. 

Готовим сценарий тестирования

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

Можно также разработать небольшой макет BI-приложения в инструментах типа Figma. Этот сценарий будет полезен не только вам, но и поставщикам, так как они будут вовлекаться в реализацию пилотного решения и могут захотеть самостоятельно пройти его для ускорения процесса.

Далее запускаем наш «конвейер», повторяя для каждого из испытуемых четыре последующих этапа. Вовлекать ли бизнес в этот процесс? Мы считаем, обязательно. Но учитывая, что у нас почти каждая система — это кот в мешке, а их количество зашкаливает, имеет смысл сделать это уже на более позднем этапе, когда будут выделены «финалисты».

Этап 1. Сбор данных от поставщика

Начинается работа с поставщиками и производителями. Здесь мы заводим контакты, просим демо или презентацию, отправляем наш опросник и смотрим результаты. 

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

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

 После получения информации для сайзинга запрашивайте стоимость железа в вашем отделе закупок. 

 Из интересных наблюдений:

• Поставщики в надежде зацепить клиентов часто завышают свои возможности в опроснике. Это будет заметно уже на этапе демонстрации. Многие отечественные BI-производители не в курсе базовой функциональности, которую использовали коммерческие компании.

• В части ценообразования мы тоже наблюдали странную политику. Создалось впечатление, что некоторые системы никогда не рассчитывали на компании, где больше 200 пользователей. В результате при расчёте на 4000+ сотрудников цена становится просто космической: даже такие вендоры, как SAP нервно курят в сторонке!

Если система подошла, то договаривайтесь организовать демостенд и готовьте канал оперативной коммуникации (например, чат в любом из мессенджеров).

Этап 2. Развёртывание демостенда

Здесь подписываем соглашение о неразглашении с поставщиком, так как, скорее всего, нескольким его сотрудникам придётся подключиться к вашим песочницам и демостенду, чтобы помочь в развёртывании.

Задача второго этапа — согласовать все ресурсы и процессы для демостенда. Многое из перечисленного ниже можно делать параллельно.

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

• Согласовываем с ИБ каждый процесс под конкретный стенд. Оформляем доступы для поставщика. Отдаём на проверку дистрибутивы.

• Оформляем доступы внешним сотрудникам. Приступаем к установке ПО на подготовленные виртуальные машины. Совместно с сотрудниками поставщика выполняем шаги по настройке стенда.

Этап 3. Тестирование на демосреде

Демостенд готов, можно приступать к тестированию. 

Задача третьего этапа — понять, насколько соответствует выбранное решение вашим задачам. 

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

Этап 4. Обратная связь поставщику и участникам

Здесь мы всем даём обратную связь с нашими замечаниями, обсуждаем их. 

Задача четвёртого этапа — подвести итоги и наметить план доработок системы под свои нужды.

• Подводим промежуточные итоги совместно с участниками. Привлекаем ИБ для анализа системы. Принимаем решение о продолжении.

• Ищем решения или пути для доработки системы. При предоставлении решений и готовности к дальнейшей работе повторяем третий этап.

А справится ли система с продуктивной задачей, а не только с тестами?

Мы на финишной прямой, и нам нужно убедиться, что система может выполнять и реальные продуктивные задачи. К этому пункту лучше переходить после всех «синтетических» тестов. 

В качестве испытуемого мы берём одно из текущих решений. Для мотивации можно взять такое, где есть проблемы из-за каких-то инструментов. Согласуем с ИБ подключение продуктивных систем и пробуем реализовать.

 Здесь уже нужно вовлечь бизнес-пользователей — они помогут найти то, что вы могли упустить, а также определиться с предпочтениями, если у вас к этому этапу осталось более одного кандидата.

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

Нагрузочное тестирование

Хочется отдельно подчеркнуть его важность. Мы на своём опыте сталкивались с неточным сайзингом систем при расчётах теоретическими методами, что выливалось в стрессовые ситуации. Поэтому перед стартом продуктивной системы обязательно заложите время на эту задачу. Придумайте сценарий и самостоятельно или с группой тестировщиков проведите стресс-тесты, чтобы выяснить предельные возможности и узкие места текущего ландшафта. 

Послесловие

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

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