Вопрос о замене «умирающего» западного BI решения в своей организации на отечественную платформу становится с каждым месяцем все более актуальным. Мы уже писали раннее, что 2024 год будет бумом больших проектов по переходу на софт из реестра. Сейчас гонка вендоров по наращиванию количества фичей в самом разгаре. Такой бурный рост обязательно скажется на качестве самих продуктов и весь 2024 год еще придется лечить «детские» и «подростковые» болезни, поскольку багов будет много. Видимо в цене будут хорошие тестировщики и качественная оперативная техническая поддержка, которая должна будет взять весь этот гнев избалованных западными решениями пользователей на себя. Конечно ко всему этому нужно добавить задачи повышения производительности самих платформ, особенно интересно это будет увидеть на отечественных серверах и процессорах. Пока что много красивых картинок в презентациях и не понятно на чем основанных рекомендациях по сайзингу. Публичный документ с данными о нагрузке выкладывают единицы, как правило это тесты на своих серверах. Исходя из нашего понимания (конечно же это субъективное мнение группы людей, оно может не совпадать с Вашим), как будет развиваться рынок в следующем году, мы подготовили рекомендации. На что нужно обратить внимание при выборе платформы и подрядчика:

1. Есть общепринятые индикаторы зрелости подходов вендора к развитию своей платформы. Среди них конечно же дорожная карта платформы, рост числа сотрудников и проектов год от года, выход на международные рынки, активность маркетинга, партнерская сеть и наличие партнерской программы, выделенная служба технической поддержки, наличие отдельной пресейл службы и консалтингового подразделения, опыт самой команды и т. д. На все это конечно же нужно обращать внимание при выборе. Например, наличие собственного консалтинга, как правило говорит о том, что вендор ориентируется на крупные проекты и топовых клиентов в отрасли. Потому что, не всегда партнер в состоянии реализовать сложный проект самостоятельно и очень часто команду вендора берут на подряд. Это происходило всегда и со всеми игроками на рынке. При этом сам вендор все таки должен зарабатывать на продаже лицензий, а не идти в рынок интеграторов и забирать проекты топовых заказчиков себе. Такой подход, когда вендор идет в проекты сам, говорит о том, что он размывает свой фокус и пытается максимизировать свою прибыль здесь и сейчас. Это могут быть индикаторы финансовой нестабильности и неуверенности в качестве своей платформы. Как правило такой подход довольно быстро приводит к росту негатива внутри заказчиков и в партнерской сети. У первых постоянно переносятся сроки, поскольку вендор набрал портфель проектов, а команда нерезиновая. У вторых пропадает интерес, и они уходят к тем производителям, которые дают возможность им развиваться и зарабатывать на рынке. Это немассовый бизнес для вендора, который убивает свою партнерскую сеть и не дает ей возможности роста в конкурентной среде, а значит лишает клиентов возможности выбирать лучших специалистов на рынке. И в будущем такой продукт может стать решением для одного клиента!

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

3. Рекомендуем посмотреть на архитектуру решений, что лежит под капотом. Есть три типовых случая. Когда вендор берет опенсорс платформу и переносит на нее свой опыт. Делает вокруг обвязку из других компонент, например ETL добавляет. Фокусируется на визуализации, поскольку клиентам продают картинку в первую очередь. По сути появляется такая поделка BI, а иногда это прям Франкенштейн из опенсорс коробки. Рисков здесь очень много, особенно в безопасности таких решений. Касперский об этом кстати много писал и пишет, иногда уязвимости не закрывают годами. Про техническую поддержку таких решений дискуссий много, но еще раз повторим дыры в безопасности висят годами! Во втором случае, вендор добавляет в свою платформу элементы опенсорса, закрывая недостающие компоненты и упаковывают это в свой написанный контур. Наиболее частый случай это какой нибудь ClickHouse в качестве хранилища и библиотеки визуализации. Все они бесплатные и здесь нужно в первую очередь убедиться, что настройка и поддержка такой платформы проходит без погружения в эти компоненты, незаметно для конечного пользователя и администратора. Если же нужно каждую компоненту настраивать еще самостоятельно, то это существенный риск в наращивании специалистов с разными компетенциями, а значит рост затрат. Третий случай — это эталон, когда весь продукт написан и создан собственноручно. Не сценарий, когда взяли опенсорс, докрутили немного напильником и назвали его красивым словом с приставкой «Ai», а именно сделали, например свой движок. Большой респект от нашей команды тем, кто будет это развивать или уже начал делать. Будем следить за Вами!

4. Пилотные проекты и готовность вендора предоставить бесплатно свой софт для проведения тестов на стороне клиента. Здесь все зависит от наличия ресурсов у самого заказчика, не только человеческих, но и временных. В любом случае рекомендуем рассматривать несколько платформ в формате бесплатных пилотных проектов силами партнеров или пресейл командой вендора. Как правило, сам Создатель платформы в пилот идет для крупных заказчиков. Малый и средний бизнес это ареал обитания партнеров. Пилотный проект должен иметь четкие временные рамки, понятный функциональный обьем и критерии успешности. Если этого нет, то сам клиент видимо находится в состоянии неопределенности и процесс выбора сводится к формату: «покажите что нибудь на наших данных». Здесь нужно партнерам и вендорам помогать заказчикам формировать ожидания от пилотов, иногда бывают случаи запредельного полета фантазии у клиента. По результатам пилота клиент должен понимать, что данная платформа может решить эту конкретную задачу и может принести экономический эффект для его компании. Это правильный сценарий и подход при выборе платформы. Для оценки результатов пилота необходимо привлечение не только ИТ специалистов, но и бизнес пользователей. Мы видели проекты, когда ИТ все нравится, а бизнес пользователям неудобно работать или топу дизайн не угодил. Такие пилоты из‑за недоработок со стороны обеих команд часто бывают провальными. Нужно всегда оценивать конечный продукт с позиции ценности для потребителя, а не только его способности технически решать задачу.

5. Когда начинают обсуждать техническую поддержку, у всех вроде все стандартно, все есть и работает качественно. Но, есть реальная жизнь! Например, поддержка на пилотном проекте будет всегда на высоком уровне с персональным подходом к клиенту. Этот уровень на данном этапе вендор может себе позволить. Нет ни одного вендора в мире, который сохранит этот стандарт качества после перехода потенциального заказчика в статус клиента. Поскольку базовая поддержка это процесс со своей системой регистрации тикетов, временем ожидания ответа и уж точно без решения проблемы «по щелчку». Как правило, это приводит к негативу и требуется время на выравнивание ожиданий и принятие действительности. Поэтому обратите внимание на наличие открытых сообществ в телеграмм, сейчас это основная площадка, хотя за рубежом существует еще много форумов. Как правило, вендор, который понимает проблематику технической поддержки, вкладывается в развитие сообщества. Коллективная поддержка иногда в разы эффективнее базовой линии самого вендора. Но, чтобы этот процесс стал автономным нужно время. Сейчас на многих площадках роль модераторов играют сами сотрудники вендора. Но есть и живые примеры автономных организмов, тот же Qlik, Tableau, Power Bi, Superset, или сообщество Russian Bi chat. Поверьте нашему опыту, иногда там найти решение можно в разы быстрее. У отечественных коллег хорошие площадки «тысячники» видели от Yandex, Visiology, PIX. У последних по каждому продукту свое сообщество, что выглядит солидно. У других игроков пока по несколько сотен жителей, но и там жизнь кипит, вопросы задают, решениями делятся.

6. В завершении поговорим о руках, то есть о партнерах выбранной Вами платформы. Здесь точно можно минимизировать риски. Обратите внимание на количество проектов по данной конкретной платформе и по BI продуктам в целом. Если на пилоте была конкретная команда с которой Вы работали, поставьте условие о ее фиксации на проекте. Скрепя сердцем, скорее всего исполнитель пройдёт на это. Низкая ставка это не значит качественный проект, по статистике выбор самой низкой цены без учета других критериев приводит к смещению сроков проекта и последующим подписания доп соглашений. Иногда и к провалу проекта, самое главное, что виноват в итоге будет вендор. Поэтому ни один уважающий себя вендор не даст Вам рекомендацию по партнеру, чаще всего авторизационным письмом ограничиваются. Когда вендор дает гарантии качества работ своего партнера, это говорит о неопытности самой сейлз команды вендора. Серьезный уровень качества показывают те партнеры, которые умеют совместно с клиентом проводить диагностику потребностей и выходят в проект на согласованном объёме задач с понятным и принятым всеми сторонами уровнем рисков.

P. S. В завершении хотим обратить еще раз ваше внимание. Мы не оказываем услуг и не рекламируем кого то конкретного, мы не порекомендуем Вам купить какой то конкретный продукт и не будем никогда делать систему рейтингов. Наша цель это делиться опытом и знаниями, а выводы и решения принимать уже Вам. Есть идеи в будущем организовать контрольную закупку по лидерам, пока еще думаем, насколько это будет корректно и интересно аудитории. Если будут мысли, пишите нам!