«Спасение утопающих — дело рук самих утопающих». Иногда это звучит не так уж и плохо.

Меня зовут Юлий Гольдберг, работаю в GlowByte (занимаюсь платформами данных, BI, аналитическими решениями больше 20 лет). Сегодня хочу поделиться некоторыми наблюдениями о том, про что нужно не забывать, чтобы Self‑Service BI стал реальным драйвером развития корпоративной культуры работы с данными, а не остался благим пожеланием.

Self-Service BI, не просто красивая идея, но объективная потребность
Представим, что BI еще не изобрели. Или что он есть, но где‑то далеко, и нам совсем недоступен, но отчеты делать надо. Чем тогда воспользуется любой сотрудник компании, чтобы сделать отчет или презентовать его заинтересованной аудитории. В первую очередь, всем на ум приходит Excel и PowerPoint. И так оно и есть на самом деле. Excel проник повсеместно. Гибкость и возможности этих инструментов почти безграничны: что хочет пользователь, то и насчитает, что вообразил себе, то и нарисует. Максимальная свобода для любого пользователя, не имеющего серьезной ИТ‑подготовки. Можно и данные собрать из разных источников, и преобразовать их нужным образом, и при необходимости сделать сложные многоэтапные расчеты. Вывести и визуализировать с условным форматированием, графиками, диаграммами.

Минусы Excel+PowerPoint хорошо известны: непрозрачность итоговых цифр (как понять, правильно ли все посчитано, когда часть цифр загружена неизвестно откуда и потом вручную скорректирована, а другая — вбита вручную прямо в таблице), расхождение результатов в разных отчетах (ведь каждый может посчитать что‑то «на коленке» или скорректировать то, что ему прислали), ну и наконец практически нерешаемые проблемы производительности, когда требуется обрабатывать сотни тысяч и даже миллионы строк информации. Удобство восприятия информации в таблицах Excel — тоже спорный вопрос. Кто‑то, конечно, настолько привык к таблицам, что другого взгляда на цифры просто не приемлет. Но все же зачастую сложно быстро ухватить суть и выявить проблему, когда смотришь на массив цифр из тысяч строк и десятков колонок.

Несмотря на все известные минусы Excel и PowerPoint, они воспринимаются повсеместно как почти идеальные средства для самостоятельной подготовки отчетности пользователями без привлечения ИТ. Но наступает момент, когда организация решает, что она переросла Excel, берет курс на датацентричность, то есть хочет принимать решения на основании актуальной и прозрачной информации, проводя анализ за длительный период времени, по всем продуктам, клиентам. Тогда она вынуждена пересаживать пользователей с упомянутых привычных инструментов на BI‑решение.

Пользователям такой переход далеко не всегда нравится, особенно если он не совсем добровольный. С другой стороны, кому понравится, когда вместо того, чтобы спокойно, ни к кому не обращаясь, собирать нужные данные и формировать отчет, приходится с трудом, в пять итераций, втолковывать BI‑разработчику что от него требуется, а зачастую еще и писать для него ТЗ по придуманному им чисто ИТ‑шному шаблону. Вполне естественно, что идея разработать такой BI‑инструмент, чтобы он был для пользователя не хуже связки Excel и PowerPoint, является очень привлекательной. Хочется сделать его таким, чтобы он обладал широким набором инструментов визуализации, удобными средствами загрузки и преобразования данных, был максимально гибким в адаптации к процессам подготовки отчетов и запросам пользователей. Но при этом ведь он должен быть защищенным, высокопроизводительным, надежным и одновременно простым для пользователя.

К сожалению, идеальный Self‑Service BI‑инструмент — это продукт множества компромиссов. Зачастую основанных на анализе опыта использования сотнями тысяч пользователей. Поэтому на практике получается, что далеко не все BI‑инструменты подходят для Self‑Service. Среди самых известных платформ такого рода, конечно, ведущая мировая троица — Power BI, Tableau, Qlik. Хотя эти продукты изначально создавались так, чтобы с ними могли работать именно пользователи, а не ИТ‑разработчики, свой нынешний сбалансированный вид они обрели далеко не сразу. Они по‑настоящему раскрыли свои возможности Self‑Service спустя годы пребывания на рынке после того, как в них были вложены тысячи человеко‑лет. А вот ряд популярных инструментов, обладающих достаточно мощным функционалом, несмотря на все свои преимущества, не смогли стать по‑настоящему пригодными для самостоятельной разработки отчетов пользователями.

Про пересаживание пользователей с Excel понятно. А как же продвинутые бизнес‑аналитики, настоящие «зубры», которые сами копаются в данных, пишут код на SQL или Python? На мой взгляд, спрос на BI и на Self‑Service BI со стороны таких аналитиков вторичен и ограничен. Если специалист привык писать код и делает это хорошо, то никакие drag&drop‑возможности, красоты интерфейса не сподвигнут его на переход. Понятно, что в силу необходимости такие аналитики тоже становятся разработчиками BI, но для них, как правило, даже не сильно заточенный на Self‑Service инструмент оказывается вполне приемлем.

Почему BI не всегда Self‑Service

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

• Удобный и понятный интерфейс разработки дашбордов.

С одной стороны, это самый понятный пункт требований, а с другой — один из самых сложно реализуемых. Ведь если сделать все очень просто для пользователя, то и функционал будет минимальным. А вот сделать одновременно и мощную, и простую систему — это уже высший пилотаж. Обычно вендоры приходят к такому идеальному балансу простоты и функциональности путем многочисленных итераций в ходе выпуска и доработки нескольких версий продукта. Это требует многих лет работы и большого числа пользователей, которые дают вендору в качестве обратной связи свои юзкейсы. При отсутствии большой пользовательской базы и долгих лет на доведение до ума единственным вариантом построить действительно сбалансированный интерфейс для Self‑Service будет скопировать кого‑то из мировых грандов. Этим большинство из присутствующих в РФ вендоров и занимается с той или иной степенью успешности. Даже в заявлениях о позиционировании продукта зачастую можно услышать: «российский PowerBI», «китайский Tableau», «наш Qlik Sense». Но, на мой взляд, очевидно, что этот путь гораздо лучше, чем «изобретать велосипед». При наличии лидеров, на которых все равняются, и укоренившейся привычки к конкретным возможностям и интерфейсам у большей части рынка быть похожим на них полезно и для кошелька вендора, и для удобства клиента.

• Развитый встроенный язык формул.

Формулы Excel в большинстве случаев являются эталоном. Практически каждый может разобраться не только с SUMPRODUCT, но и с VLOOKUP и более сложными конструкциями. Не нужно быть программистом, чтобы их использовать, но посчитать можно почти все. А вот в BI‑решениях с формульным языком зачастую большая проблема: есть всего десяток простых формул, которые не покрывают даже минимально необходимых требований пользователей. Тогда приходится выносить в предварительные расчеты показателей на уровень витрины данных, формированием которых занимается ИТ. Выносится даже то, что необходимо часто менять и что требует полного контроля со стороны пользователя. Вынос из BI‑инструмента расчетов приводит к потере гибкости и прозрачности расчета показателей — и к существенному снижению удобства использования данного инструмента как Self‑Service BI. В некоторых инструментах предлагается вместо ввода формул писать код на Python или на SQL. Что тоже не добавляет простоты и удобства для пользователей‑непрограммистов. Факт в том, что обычно пользователи Self‑Service BI — это не программисты. Возлагая на них написание кода, даже не очень сложного, мы однозначно теряем их лояльность и лишаем их мотивации. Эталонные Power BI, Tableau, Qlik обладают очень развитыми формульными возможностями. Российские вендоры, стремящиеся сделать Self‑Service‑инструменты, тоже постепенно идут по этому пути. Хороший пример — Visiology, который в третьей версии предложил использовать внутри своего продукта майкрософтовский DAX, так хорошо знакомый многим по PowerBI. Но одной идеи DAX в продукте мало, поэтому, начав с небольшого числа, Visiology в каждой версии наращивает число формул, чтобы приблизиться к достойному для Self‑Service‑продукта уровню. В FineBI, одном из наиболее продвинутых Self‑Service‑решении на нашем рынке, формульный язык изначально был очень богат, уже в тот момент, когда этот продукт появился здесь.

• Встроенные инструменты проектирования модели данных, подключения новых источников данных и загрузки и преобразования информации.

Большинство BI‑проектов строится над хранилищами данных и подобными им компонентам инфраструктуры данных («озерами данных», набирающими популярность в последнее время Lakehouse или даже над простыми витринами). Но чтобы загрузить хотя бы одну таблицу в ХД, нужно зачастую потратить несколько дней. Ведь грузить придется посредством трансформации данных через множество слоев, с соблюдением большого числа регламентных правил и ограничений, а порядок тестирования и передачи пайплайнов загрузки из контура разработки на промышленный контур может заставить вспотеть и профессионального разработчика. Для бизнес‑пользователя такой вариант работы с данными можно вообще не рассматривать как реалистичный. Поэтому в Self‑Service BI должна быть предусмотрена простая возможность быстро и без всякого кодирования загрузить несколько нужных табличек, визуально увязать их между собой и получить нужный для анализа срез требуемой глубины с подходящим набором атрибутов. Частично данные могут быть просто выгрузками в Excel или построенными в этом инструменте вручную документами, а другая часть — данные, загруженные из того же ХД, или построенных над хранилищем витрин. Инструменты загрузки и преобразования данных для разработчиков, даже имеющие развитый визуальный интерфейс (типа ФормИТ или Modus ETL) не очень подходят для бизнес‑пользователей в силу избыточной функциональности и сложности понимания процессов для неспециалистов. Поэтому BI‑вендорам приходится делать что‑то более простое, но тем не менее позволяющее решать стоящие перед аналитиками и сотрудниками бизнес‑подразделений задачи. Отличный пример — Power Query в Power BI. Хотя до функционала и удобства такого масштаба пока никто из отечественных продуктов не развился, но претендующие на звание Self‑Service BI‑инструменты уже реализуют подобный функционал. Все понимают, что просто дать окошко для ввода ETL‑кода на Python для неискушенного в ИТ пользователя явно неадекватно и неправильно.

• Развитые средства распространения контента внутри организации.

Сделать красивый дашборд — это только полдела. Нужно обеспечить, чтобы этот дашборд, возможности, которые он предоставляет для принятия решений были доступны для тех, кому он предназначен. Конечно, в ряде случаев пользователи‑аналитики делают их сами для себя, для самостоятельного анализа данных, а потом уже выводы со скринами вставляют в презентацию и таким образом делятся результатами своей работы с коллегами. Но это лишь один из юзкейсов, и не факт, что самый распространенный. Пользователю, который сделал дашборд, нужно иметь возможность поделиться им с другими, опубликовать результаты, написать комментарии и т. п. Если для публикации нужно обращаться в ИТ, а комментарии придется писать в почте или «Телеграме», то ценность инструмента для пользователей снижается. Хорошие Self‑Service‑инструменты предоставляют простые возможности для публикации, рассылки, комментирования разработанных дашбордов пользователями, причем позволяют как четко определить целевую аудиторию, так и проинформировать ее о том, что это не валидированный всеми инстанциями в горниле ИТ отчет, а именно подготовленный в рамках Self‑Service, имеющий соответствующего автора и основанный на соответствующих источниках.

• Наличие собственного высокопроизводительного движка обработки данных.

Excel — мощная штука, многие справедливо восхищаются его возможностями. За что его часто ругают, так это за то, что он начинает «тормозить» и даже «падать», как только данных становится по‑настоящему много, а сложность расчетных алгоритмов превышает простую арифметику. Уходя от Excel к BI, бизнес‑пользователи во многом стремятся решить именно проблему скорости и надежности расчетов. Если при открытии дашборда, фильтрации или любой другой аналитической операции им приходится ждать хотя бы минуты, не говоря уже о десятках минут, то это кардинально подрывает мотивацию работать с таким BI‑инструментом, а там уже и до возвращения обратно в Excel и итальянской забастовки в переходе на BI не далеко. Поэтому для Self‑Service BI оказывается критически важным наличие встроенного мощного вычислительного движка, который бы быстро обсчитывал сложные алгоритмы на миллионах строк и при этом не требовал бы от пользователя глубоких познаний в архитектуре баз данных и оптимизации запросов. У некоторых систем, как, например, Fine BI, это встроенный, разработанный вендором этого BI in‑memory вычислительный модуль. У других — какая‑то доработанная с учетом потребностей BI‑инструмента производительная СУБД, часто — ClickHouse, как в Visiology, PIXBI, Analytical Workspace. Не так важно. Но те BI‑продукты, которые такого движка не имеют, являются, по сути, «рисовалками» красивых картинок, а все запросы спускают во внешнюю БД. Управлять производительностью обработки запросов в такой архитектуре крайне сложно. Поэтому таким инструментам сложно по‑настоящему претендовать на звание Self‑Service BI.


Зачем тратят деньги на внедрение Self-Service BI

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

Тем не менее при всех плюсах централизованное BI‑подразделение часто становится узким горлышком в процессе обеспечения пользователей нужными им отчетами. Ведь в крупной компании дашбордов могут быть сотни и даже тысячи, чтобы развивать и поддерживать их, нужны десятки специалистов, а собрать и содержать такую команду BI‑профессионалов непросто и ОЧЕНЬ дорого. Кроме того, такой подход увеличивает time‑to‑market, поскольку пока соберешь требования, разработаешь, реализуешь, протестируешь, передашь пользователю, проходит несколько недель. Неизбежны ошибки и недопонимания, ведь пользователь разговаривает на своем языке, и максимальная бизнес‑экспертиза есть лишь у него в голове, а BI‑разработчик понимает требования как может, даже если они четко описаны, что уж говорить про вариант, когда дашборд делается на основании лишь короткого письма по е‑mail или вообще устной просьбы. Таким образом, Self‑Service BI оказывается не только ответом на вполне осознанную потребность пользователей переехавших в BI с Excel, но и способом решения организационных и технологических проблем, которые возникают при таком внедрении.

Кстати, про то, за что компании платят, внедряя BI, команда и клиенты GlowByte (Альфа‑Лизинг, Газпромбанк, СИБУР и t2) рассказывали на конференции FineDay 2025.

Чуть подробнее о драйверах окупаемости проекта Self‑Service BI:

• Снижение нагрузки на ИТ.

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

• Упрощение работы со «сложными» (требовательными) пользователями.

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

• Ускорение получения готовых дашбордов (time‑to‑market).

На практике за счет отсутствия необходимости многочисленных итераций взаимодействия ИТ и бизнеса в процессе разработки дашборда удается значительно сократить время получения результата. Есть примеры, когда на реализацию задачи, на которую ранее уходило 5–6 недель с вовлечением 4–5 человек (бизнес‑заказчик, аналитик, архитектор, разработчик, тестировщик), после внедрения Self‑Service подхода требуется лишь 2–3 дня работы самого пользователя. Главное, что переход позитивно влияет не только на скорость самой разработки, но и непосредственно на скорость принятия управленческих решений в организации.

• Снижение числа ошибок при разработке дашборда.

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

• Упрощение и ускорение процесса миграции на новый BI (в том числе для целей импортозамещения).

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

Подводные камни, или О чем не забыть, чтобы корабль Self-Service BI не дал течь прямо рядом с берегом

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

• Неверифицированные данные для принятия решений.

Внедрение Self‑Service BI только тогда можно назвать полноценным, когда пользователи имеют доступ к данным и могут самостоятельно использовать источники информации для расчета нужных им показателей, построения своих дашбордов. Если дать им только возможность рисовать красивые графики и диаграммы и ограничить работу с данными только имеющейся в модели данных BI информацией, то в большинстве случаев этого будет недостаточно. Соответственно, аналитики и пользователи должны иметь возможность считать свои показатели, формировать свои таблицы, подгружать и использовать в дашбордах данные из Excel, Google Sheets. Все это приводит к тому, что данные, которые они используют в отчетах и которые предоставляют руководителям для принятия решений, могут оказаться некорректными, не актуальными, противоречивыми. Чтобы минимизировать проблему принятия неверных решений на основе неверных данных, нужно в первую очередь определить уровень доверительности для всех дашбордов, которые попадают на «стол» к руководителям. В ряде компаний, пользователи, которые создают свои дашборды в рамках Self‑Service, жестко лишены возможности публиковать их для широкого круга сотрудников или использовать их на совещаниях, где принимаются важные для компании решения. При этом те решения, которые находятся в зоне ответственности самого сотрудника, создающего дашборд, он может свободно принимать на основании своего анализа. Хорошая практика: если дашборд строится на верифицированной промышленной витрине и используемые алгоритмы соответствуют утвержденным методикам (тут не помешает иметь внедренный бизнес‑глоссарий), этот дашборд помечается соответствующим визуальным или цветовым указателем. Если же использованы непроверенные данные или алгоритмы, то опять же правильно это четко указывать в самом дашборде во избежание недоразумений. В некоторых компаниях валидированные дашборды и дашборды Self‑Service лежат в разных папках, и когда руководитель их открывает, он видит, чем он пользуется в данный момент. Хотя такая практика может дать сбой в случае, когда дашборд открывается на основании присланной прямой ссылки.
В целом, если понимать, что проблема уровня доверительности данных в отчетах существует, то она вполне решаема. С использованием конкретных организационных и технологических методов. С одной стороны, они не сильно напрягают пользователей, ограничивая их свободу получать и анализировать информацию. С другой — не позволяют потенциальному хаосу вырваться наружу и возвратить компанию во времена «до создания единой версии правды».

• Хаос визуальных представлений.

Еще одной проблемой внедрения Self‑Service BI обычно становится проблема различного понимания прекрасного разными людьми, вовлеченными в процесс создания дашбордов. Эта проблема частенько всплывает, даже если ведется централизованная разработка дашбордов силами BI‑команды. В том случае, когда вопросам единых подходов к дизайну не уделяется должного внимания. С переходом на Self‑Service проблема многократно усложняется, поскольку участниками процесса разработки становится намного больше людей с разным жизненным и профессиональным опытом. В итоге получается, что один и тот же тип показателя, например, прибыль по годам, кто‑то выводит в виде столбчатой диаграммы, кто‑то показывает линейным графиком. А кто‑то даже решает так, что сегментная диаграмма тут подойдет лучше всего. Пусть она тут совсем не подходит, но творческая личность зачастую решает, что если нравится, то почему бы нет). То же можно сказать и о цветовой гамме, и о принципах размещения информации на дашборде. Когда в итоге все эти совершенно разные дашборды, но про одни и те же показатели и разрезы попадают «на стол» к одному человеку, принимающему решения руководителю, то вместо того, чтобы быстро понять ситуацию и решить что делать, он тратит много времени и сил на техническую работу, на то, чтобы разобраться со всем этим хаосом и понять, что каждый из авторов имел в виду. Эта проблема, как и первая, описанная выше, может быть решена вполне конкретным набором действий — созданием и внедрением так называемого «учебника по визуализации», включающего шаблоны типовых дашбордов, где цветовая палитра основана на брендбуке и лучших практиках, а рекомендации носят сугубо практический характер, привязанный к потребностям и особенностям конкретной организации. Этот учебник не может быть очень большим, наоборот, должен быть очень конкретным, так, что даже сильно занятой бизнес‑эксперт сможет быстро просмотреть его и найти нужную информацию тогда, когда ему потребуется сделать нужный виз. Кроме того, есть хорошая практика:так же, как при изначальном внедрении BI‑подходов топ‑менеджеры зачастую сознательно отказываются принимать на совещаниях аргументацию, подкрепленную отчетами в Excel, так и при внедрении Self‑Service BI нужно будет как минимум какое‑то время сознательно и жестко ограничить использование дашбордов, построенных не в соответствии с утвержденным гайдом по визуализации. Довольно быстро все привыкнут, и проблема останется только на уровне онбординга новых сотрудников.

• Обеспечение нужной программно‑аппаратной инфраструктуры для работы BI.

Это многогранная проблема, которая характерна для многих ИТ‑решений. Но при внедрении Self‑Service BI, если это по‑настоящему массовое внедрение, столкновение с ней почти неизбежно. Ведь ресурсы, требуемые для работы BI‑решения, сильно зависят от количества пользователей. А когда пользователи становятся не просто потребителями готовых отчетов, а начинают сами создавать запросы, формировать алгоритмы обработки данных и расчетов показателей, то нагрузка значительно возрастает, и управлять ей становится сложнее. При этом важно понимать, что запросы к данным и расчетные алгоритмы пользователей могут быть далеко не такими оптимальными как те, которые создают и отлаживают профессиональные дата‑инженеры. Такими запросами и сервер «повесить» недолго. Решение проблемы опять же находится и в организационной, и в технологической плоскости. Во многих случаях для пользователей Self‑Service BI создают отдельный BI‑контур со своим сервером или кластером, выделяют определенные квоты на сервере СУБД, чтобы самостоятельная активность не привела к недоступности BI в целом для всей организации. Способ хороший, но стоит учесть, что сама идея продвижения Self‑Service BI в организации может потерпеть крах, если ресурсы для пользователей будут выделены по остаточному принципу и если они будут постоянно сталкиваться с проблемами производительности. Подождут ответа на свои запросы по полчаса несколько раз и бросят красивую идею Self‑Service, возвратившись опять к анализу на локальных компьютерах в своем любимом Excel. Поэтому более технологичный способ решения проблем производительности — это использование в BI современных возможностей управления приложениями, таких как Kubernetes. Если архитектура BI‑системы достаточно современна и позволяет гибко управлять выделяемой мощностью в зависимости от приоритета запросов и их сложности, то проблему производительности можно решить без излишних затрат и ко всеобщему удовольствию. Также стоит отметить тут важность встроенного высокопроизводительного движка обработки данных, который уже был упомянут выше. Если такой движок есть, то он зачастую прощает многие ошибки пользователей и позволяет даже не имея высокой квалификации в области управления данных получить приемлемые показатели по скорости отклика дашбордов. Не зря все лучшие мировые BI‑продукты обладают собственными качественными движками и не перекладывают эти задачи на внешние СУБД. Понятно, что для продвижения BI‑культуры в компании хорошо бы максимально снизить требования к квалификации пользователей, уменьшить так называемый порог входа. Но, с другой стороны, и без обучения пользователей тоже не обойтись. Каждый, кому разрешается самостоятельно готовить дашборд, по‑хорошему должен иметь хотя бы базовое представление, как правильно работать с данными и чего с ними делать точно не нужно.

Self-Service BI – не только про функционал и технологии

Когда говорят про внедрение Self‑Service BI, то обычно, в первую очередь, речь заходит о самом BI‑инструменте и том, насколько он подходит для таких задач. Есть даже целые таблицы сравнения разных продуктов по набору критериев — так называемые Self‑Service Ready. У GlowByte тоже есть такая таблица, и мы готовы поделиться ею со всеми заинтересованными.
Можно написать запрос на contact@glowbyteconsulting.com.

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

• Наличие и доступность данных для построения дашбордов.

Для внедрения BI данные критичны, все это понимают. Но если профессиональные BI‑разработчики способны продираться через тернии и выкачивать информацию, при необходимости, даже через сложные интеграционные интерфейсы, то обычные бизнес‑пользователи к такому героизму, как правило, не готовы. Если не обеспечить их достаточно простыми механизмами получения требуемой информации, их интерес к самостоятельной разработке быстро перегорит. Что‑то они и из Excel‑файлов могут получить, но все основные данные должны лежать в красивых витринах и быть достаточно качественными и актуальными, чтобы вызывать доверие со стороны их потребителей. Поэтому заход в Self‑Service до того, как организация разберется в своих данных и построит полноценное ХД или как минимум «озеро данных», чреват большими проблемами. И это не очень зависит от масштаба компании. Даже если у небольшой компании есть только 1С Бухгалтерия и Битрикс, а не 100 разных систем‑источников, выгрузить из них данные, привести к общему знаменателю и очистить от дублей, пропусков и прочих проблем может оказаться невыполнимой задачей для бизнес‑пользователей. И даже не столько невыполнимой, а такой задачей, которой они не захотят заниматься регулярно, что равносильно краху идеи Self‑Service. Ведь без нормальных данных и никаких дашбордов, конечно, не будет.

• Сложность взаимодействия со службой ИБ для получения доступа к данным.

В различных компаниях есть разные подходы к получению доступа к данным. Есть такие, где нужно потратить несколько месяцев, чтобы согласовать доступ к одной табличке. А есть такие, где ограничения установлены только на самые конфиденциальные данные (персональные данные, коммерческая тайна и т. п.), а остальное может быть легко получено в рамках стандартного запроса за один день. Безусловно, второй подход к организации доступа имеет максимальные преимущества с точки зрения перспектив развития Self‑Service BI. Любые препятствия охлаждают интерес пользователей к самостоятельной работе с данными, но чуть ли не хуже всего действует прямое столкновение с бюрократией компании в лице службы ИБ. На практике мало кто готов упорно бороться за свои права и через месяц баталий получить заветное разрешение. Поэтому при организации Self‑Service BI один из ключевых моментов — это сразу определить данные, которые доступны максимально просто, и далее сформировать четкий регламент, как быстро получить доступ к более закрытой информации. Очевидно, что для того, чтобы дружить с ИБ, нужна BI‑система, которая поддерживает гибкое разграничение доступа к данным и имеет развитые инструменты логирования. Далеко не каждый из BI‑продуктов обладает такими возможностями, поэтому уже на этапе выбора стоит вовлечь ИБ и заручиться их поддержкой в стремлении внедрить Self‑Service BI.

• Организация предоставления лицензий.

Подавляющее большинство BI‑решений лицензируется по числу пользователей. Обычно BI‑лицензии разбиваются на две категории: разработчики, которые могут создавать и менять дашборды, и простые пользователи, которые могут только работать в интерактивном режиме с уже готовыми дашбордами — просматривать их, фильтровать, детализировать, переходить с смежным показателями и т. п. Стоимость лицензии на разработчика обычно во много раз больше, чем на простого пользователя. Поэтому дать всем желающим лицензию разработчика обычно экономически сложно и во многом не оправдано. С другой стороны, и «мурыжить» желающих приобщиться к культуре Self‑Service и обещать,что как только кого‑то уволят, то сразу тебя осчастливят, неправильно. Таким образом, запуская идею перехода к Self‑Service BI, в компании нужно сразу согласовать бюджет и закупить нужное для начала число лицензий. А также организовать процесс оперативного предоставления пользователям лицензий на разработку так, чтобы это не вызывало дискомфорта и излишних затрат. Ну и в целом выстраивание автоматизированного процесса управления BI‑лицензиями будет не лишним, поскольку текучку кадров еще никто не отменял, люди меняют профиль, идут на повышение, и если в компании 20% или более дорогостоящих лицензий «лежат на полке», то это далеко не самый эффективный способ внедрить Self‑Service BI, так же, как и очередь на лицензии, растягивающаяся на месяцы и годы.

• Гибкое управление серверными ресурсами.

Одно дело, когда несколько разработчиков занимаются построением и отладкой дашбордов на Dev‑среде, и совсем другое, когда десятки, а то и сотни пользователей создают для себя новые представления, зачастую в ad‑hoc‑режиме исследуя огромные массивы информации с помощью BI‑инструмента. Требования к обеспечению гибкости управления аппаратными ресурсами совершенно разные. Поэтому при переходе к Self‑Service BI приходится не только выделять дополнительные мощности на создаваемую новоприбывшими разработчиками дополнительную нагрузку, но и заботиться о внедрении BI в гибкой кластерной архитектуре. Она должна позволять быстро выделять и снимать необходимые ресурсы, не допускать отказа системы целиком, в случае «падения» одного процесса по причине некорректного запроса. Проблему гибкого управления ресурсами и отказоустойчивости и раньше решали, но современные облачные подходы решают такие задачи как нельзя лучше. Главное, не забывать, что переход к Self‑Service BI, особенно, если он действительно массовый, не может произойти нормально на старом железе и при старых подходах к управлению им.

• Обучение.

Вроде бы банальная вещь, но не один проект внедрения Self‑Service BI споткнулся именно на этом. Некоторые почему‑то считают, что если компанией куплен хороший BI‑инструмент с интуитивно понятным интерфейсом и простые пользователи начинают использовать дашборды в нем практически без каких‑либо вводных, то значит и разрабатывать свои дашборды эти пользователи смогут также легко, стоит лишь дать лицензию, инструкцию и доступ к данным. Но на практике это не так. Большинство пользователей, даже хорошо освоивших Excel и глубоко разбирающихся в своих профессиональных темах, все же довольно далеки от профессиональной разработки, и чтение толстой документации для них не вполне привычное времяпрепровождение. Помимо уже упомянутого выше краткого учебника по визуализации, им нужно провести как минимум базовый курс по разработке дашбордов, причем желательно не абстрактный курс вендора, а привязанный к инфраструктуре и процессам конкретной организации. Тогда и онбординг пользователей‑разработчиков пройдет гораздо быстрее и меньше ошибок будет и при разработке, и в итоговых отчетах, да и перегрузки «железа» будут случаться гораздо реже. Не обязательно, а зачастую и не желательно, отравлять всех, кто сам создает свои дашборды, на курсы к вендору. Их стоит обучать на местах. Для этого полезно сформировать специальную команду обучения в составе центра компетенции BI, обычно из числа профессиональных BI‑разработчиков ЦК. Важно, чтобы курсы читались регулярно, с учетом текучки, ежемесячно, ежеквартально, но чтобы вновь приходящие в команду Self‑Service BI‑пользователи и аналитики могли быстрее включиться в работу, а не ждать месяцами, когда им проведут нужный онбординг.

• Наличие в компании внедренного подхода к управлению данными и решения для Data Governance.

Работающая система DG — это во многих случаях принципиальный фактор, определяющий успех внедрения Self‑Service BI. Очевидно, что DG требуется не только для BI, он полезен для всех без исключения процессов и задач, связанных с использованием данных в работе организации. Но без наличия удобного доступа к бизнес‑глоссарию и дата‑каталогу пользователям сложно разобраться, как правильно посчитать те или иные показатели, не ясно, есть ли они в уже реализованных дашбордах. Трудно понять, в каких источниках лежат нужные данные для отчета, в какие витрины эти данные загружены, как их оттуда правильно взять. Также без DG будет сложно определить, каким данным и в какой степени можно доверять. На вопросы, что уже есть в витринах данных и какие витрины для чего лучше использовать, придется отвечать ИТ, и бесконечный поток вопросов может быстро вывести из себя и спрашивающих, и отвечающих. Кто‑то скажет, что вся информация о данных может быть в каких‑то документах, регламентах, методиках, но проблема в том, что с такой разрозненной информацией сложно работать, особенно неподготовленному пользователю. Ведь пользователь занят своей профессиональной деятельностью, и у него нет времени продираться сквозь тома документации в поисках информации о каком‑то нужном ему показателе или атрибуте. А ведь любая документация еще и чрезвычайно быстро устаревает. С большой вероятностью, столкнувшись с трудностями поиска, пользователь просто сделает новый алгоритм, который будет отличаться от ранее согласованного, использует набор атрибутов, показавшихся ему подходящими для его задачи. В итоге это приведет к ошибке. В общем, чем больше пользователей Self‑Service, шире набор используемых данных и количество дашбордов, тем больше в компании потребность в DG. В связи с тем, что переход к Self‑Service кардинально увеличивает все эти цифры, подумать о внедрении Data Governance стоит в момент решения по новому подходу BI, не откладывая на потом.

• Развитое BI‑комьюнити в компании.

Большое число пользователей разработчиков могут загрузить своими вопросами и проблемами центр компетенции BI похуже, чем если бы этот ЦК сам делал все эти дашборды. Особенно если есть проблема текучки кадров, и каждый месяц появляется новая группа пользователей, которая с энтузиазмом приступает к освоению BI‑инструмента, подходов к работе с данными, корпоративной инфраструктуры данных и пр. Снизить нагрузку на ЦК (ИТ) позволяет организация и поддержка работы BI‑комьюнити в компании. При его наличии сами пользователи будут поддерживать друг друга, делиться знаниями и новыми находками, помогать с онбордингом новых коллег. Главное — правильно организовать работу сообщества, не относиться к этому как процессу, который сам себя создаст и разовьет. Обычно в успешных организациях BI‑комьюнити — это активная структура, у которой есть энергичный и компетентный модератор, причем совсем не обязательно от ИТ. Хорошо помогут налаживанию работы комьюнити регулярные встречи, выделение и поощрение локальных чемпионов в подразделениях, геймификация. Не так много найдется компаний, кто смог создать полноценное работающее BI‑комьюнити, но там, где это получилось сделать, вероятность успешного внедрения Self‑Service BI возросла многократно. При этом внешнее комьюнити, даже такое активное, как, например, FineBIChat от GlowByte, чат Tableau никогда не заменит внутреннего, потому что только внутри есть реальная возможность управлять мотивацией участников и только внутри можно безбоязненно обсуждать любую специфику внутренних процессов и делиться всеми удачными наработками с коллегами.


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

Могут быть самые веские причины, почему BI хорошо бы сделать Self‑Service, но, пока эта задача не запустится именно как полноценный проект, дело не сдвинется с мертвой точки. А у проекта должен быть и куратор от топ‑менеджмента, и ответственный проджект‑менеджер, и календарный план, и достаточные ресурсы, в том числе финансовые. Если не забывать, что Self‑Service BI — это полноценный проект, и помнить про вопросы, обозначенные выше, то такой проект принесет и экономический эффект организации, и, что немаловажно, станет краеугольным камнем внедрения культуры Data‑Driven в организации.

Статья в сокращенной и адаптированной версии размещена также в издательстве OSP