Представим, что бизнес-аналитику еще не изобрели, а отчеты делать надо. Чем воспользуется сотрудник компании, не имеющий глубоких знаний в ИТ? Excel и PowerPoint. Первая система повсеместно проникла в корпоративную среду, а гибкость и возможности второй почти безграничны, предоставляя максимальную свободу для бизнес-пользователя. Однако и минусы связки этих инструментов хорошо известны: отсутствие прозрачности итоговых показателей — сложно понять, правильно ли все посчитано, когда часть чисел загружена неизвестно откуда и потом вручную скорректирована, а другая — введена вручную прямо в таблице; расхождение результатов в разных отчетах — любой сотрудник может что-то посчитать «на коленке» или скорректировать присланные ему сведения; практически нерешаемые проблемы производительности — если требуется обрабатывать сотни тысяч и миллионы строк данных, то время расчета может быть непредсказуемым, а возможно, и бесконечным. Удобство восприятия информации в таблицах Excel — также вопрос спорный, и зачастую сложно быстро ухватить суть и выявить бизнес-проблему, закопавшись в массиве чисел, выстроившихся в колонках и строках таблицы.

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

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

Идеальный инструмент самообслуживания в бизнес-аналитике — продукт множества компромиссов, и далеко не все подобные системы подходят для работы в таком режиме. Наиболее известны Power BI, Tableau и Qlik Sense, а многие другие популярные инструменты, хотя и обладающие достаточно мощным функционалом, не стали реальным инструментом самообслуживания.

Помимо пользователей, работающих с Excel и Power Point, во многих компаниях есть и бизнес-аналитики, настоящие «зубры», которые сами копаются в данных, пишут код на SQL или Python. Но спрос с их стороны на self-service BI достаточно ограничен — научившись хорошо писать запросы и понимая данные, они обычно не готовы бросить код и перейти на режим drag&drop.

BI не всегда self-service

На первый взгляд, BI-инструмент для self-service ориентирован на обычного пользователя, не специалиста в ИТ. Такой инструмент должен быть простым в освоении и удобным в использовании, но позволять проводить сложную обработку данных, выполнять расчеты, создавать разнообразные визуализации и комбинировать их в наглядные дашборды. И все это без глубокого понимания архитектуры данных и без программирования. Если пойти чуть глубже, то, чтобы BI-продукт претендовал на звание ”self-service ready”, он должен удовлетворять ряду требований.

  • Удобный и понятный интерфейс разработки дашбордов. Это самое очевидное, но и самое сложное в реализации требование — если сделать все очень просто для пользователя, то и функционал будет минимальным, а вот разработать одновременно и мощную, и простую систему — серьезная задача. Обычно вендоры приходят к идеальному балансу простоты и функциональности после многочисленных многолетних итераций в ходе выпуска и доработки нескольких версий своего продукта. При отсутствии большой пользовательской базы и времени на доведение системы до ума единственный способ построить действительно сбалансированный продукт self-service BI — это «скопировать» популярный продукт ведущего поставщика. Этим, собственно, и занимается большинство из присутствующих на отечественном рынке разработчиков, иногда честно указывая: «российский PowerBI», «китайский Tableau», «наш Qlik Sense». Этот путь лучше, чем «изобретение велосипеда».
  • Развитый встроенный язык формул. Формулы Excel стали эталоном — практически любой сотрудник может разобраться не только с SUMPRODUCT, но и с VLOOKUP и более сложными конструкциями. Однако во многих BI-решениях с языком формул часто проблема — имеется лишь десяток простых формул, не покрывающих даже минимально необходимых требований пользователей. Поэтому приходится выносить предварительные расчеты показателей на уровень витрин данных, формированием которых занимается подразделение ИТ. Выносится также и то, что необходимо часто менять и что требует полного контроля со стороны пользователя. Это приводит к потере гибкости и прозрачности расчета показателей, а также к существенному снижению удобства самостоятельного использования данного инструмента. В некоторых инструментах предлагается вместо формул писать код на Python или на SQL, что тоже не добавляет простоты и удобства для непрограммистов, делегирование которым написания даже не очень сложного кода однозначно означает потерю лояльности и мотивации. Эталонные Power BI, Tableau и Qlik обладают развитыми возможностями работы с формулами, и российские поставщики также постепенно идут по этому пути. Хороший пример — система Visiology [1] с встроенным языком DAX, хорошо знакомым многим пользователям PowerBI. Но одного лишь DAX недостаточно, поэтому в каждой очередной версии Visiology увеличивается число формул, чтобы приблизиться к достойному для продукта self-service уровню. В системе FineBI, одном из наиболее продвинутом на отечественном рынке решении self-service BI, набор формул был богат уже в момент, когда продукт появился на отечественном рынке.
  • Встроенные инструменты подключения новых источников, проектирования модели данных, загрузки и преобразования. Большинство BI-проектов строится над хранилищами данных и подобными компонентами ИТ-инфраструктуры (озерами данных, lakehouse или простыми витринами). Но чтобы загрузить даже простую таблицу в хранилище, зачастую потребуется несколько дней — грузить придется посредством трансформации данных через множество слоев, с соблюдением большого числа правил и ограничений, а порядок тестирования и передачи задач загрузки из контура разработки в промышленный контур может оказаться серьезной проблемой даже для профессионального разработчика. Для бизнес-пользователя такой вариант даже не рассматривается. В self-service BI должна быть предусмотрена простая возможность быстро и без кодирования загрузить несколько нужных таблиц, визуально увязать их между собой и получить нужный для анализа срез требуемой глубины с подходящим набором атрибутов. Частично данные могут быть просто выгрузками в Excel или собранными вручную документами, а другая часть — данные, загруженные из хранилища данных или построенных над ним витрин. Инструменты загрузки и преобразования данных для разработчиков, даже имеющие развитый визуальный интерфейс, такие как «ФормИТ» и Modus ETL, не очень подходят для бизнес-пользователей в силу избыточной функциональности и сложности настройки. Просто предоставить неискушенному в ИТ пользователю окно для ввода ETL-кода на Python также неправильно. Поэтому вендорам систем BI приходится делать что-то более простое, но тем не менее позволяющее решать стоящие перед аналитиками и сотрудниками бизнес-подразделений задачи. Хороший пример — Power Query в Power BI, но аналогичного функционала и уровня удобства пока отечественные производители не предлагают.
  • Развитые средства распространения контента. Сделать красивый дашборд — это только полдела, нужно обеспечить, чтобы возможности, которые он предоставляет для принятия решений, были доступны для тех, кому он предназначен. Конечно, в ряде случаев пользователи-аналитики делают их для самостоятельного анализа данных, а потом включают в презентацию выводы со скриншотами и таким образом делятся результатами своей работы. Однако если для публикации дашборда нужно обращаться к ИТ, а комментарии отдельно писать в почте, то ценность инструмента снижается. Хорошие инструменты self-service должны предоставлять простые возможности для публикации, рассылки и комментирования разработанных дашбордов, позволяя четко определить целевую аудиторию и проинформировать ее о том, что это не валидированный всеми инстанциями отчет, а именно самостоятельно подготовленный конкретным автором и основанный на соответствующих источниках.
  • Наличие собственного высокопроизводительного движка обработки данных. Excel — достаточно мощный инструмент, но тем не менее его часто ругают за деградацию производительности, возникающую при избытке данных или росте сложности расчетных алгоритмов. Уходя от Excel к BI, бизнес-пользователи во многом стремятся решить именно проблему скорости и надежности расчетов. Если при открытии дашборда, фильтрации или выполнении любой другой аналитической операции им приходится ждать даже несколько минут, то это кардинально подрывает мотивацию работать с таким инструментом. Для self-service BI критически важно наличие встроенного мощного вычислительного движка, способного быстро прокручивать сложные алгоритмы над миллионами строк и при этом не требующего от пользователя усилий по оптимизации запросов и глубоких познаний в архитектуре баз данных. У некоторых систем, например Fine BI, имеется встроенный in-memory вычислительный движок. У других — доработанная с учетом потребностей BI-инструмента высокопроизводительная СУБД, например ClickHouse (Visiology, PIX BI и Analytical Workspace [2]). Продукты, не имеющие подобного встроенного и адаптированного движка, являются, по сути, «рисовалками» красивых картинок, делегирующими внешней базе все запросы к данным. Управлять производительностью обработки запросов в такой архитектуре крайне сложно и нельзя гарантировать пользователям приемлемое время отклика без постоянного шаманства с участием ИТ-специалистов.

Зачем расходовать ресурсы на внедрение self-service BI?

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

Таким образом, self-service BI оказывается не только ответом на потребность пользователей, переехавших с Excel, но и способом решения организационных и технологических проблем, возникающих в компаниях, вставших на путь data-driven.

Назовем основные факторы «окупаемости» self-service BI.

  • Снижение нагрузки на ИТ. Если разработкой и поддержкой дашбордов занимается только подразделение ИТ, то приходится либо увеличивать его численность, что во многих случаях просто невозможно, либо складывать большинство задач пользователей в огромный бэклог. Делегирование задач разработки аналитикам и бизнес-пользователям сводит роль ИТ к обучению, консалтингу, решению возникающих сложных проблем, требующих гораздо меньше ресурсов, чем для полномасштабной разработки и поддержки всех дашбордов компании.
  • Упрощение работы с взыскательными пользователями. Часто проблемы цифровизации вызваны отсутствием общего языка между ИТ и бизнесом — даже при наличии хорошо выстроенных процессов коммуникации много сил уходит на взаимодействие. Внедрение self-service BI позволяет органически устранить напряжение между ИТ и бизнесом, как минимум в части подготовки отчетов, делая их союзниками, поскольку теперь бизнес не требует результата от ИТ, а получает его самостоятельно, ожидая от ИТ только качественной поддержки.
  • Ускорение получения результата. Исключение многочисленных итераций взаимодействия ИТ и бизнеса при разработке дашборда значительно сокращает время получения результата в виде готового отчета или результатов анализа. Это позитивно влияет не только на скорость разработки, но и на скорость принятия управленческих решений в организации.
  • Сокращение числа ошибок при разработке дашборда. Когда пользователь сам делает для себя дашборд, существенно сокращается риск возникновения ошибок, связанных с неправильной передачей или интерпретацией информации, — пользователь хорошо понимает, какие показатели и в каких разрезах он хочет видеть, какие данные для этого нужны и каким источникам можно доверять. Сокращение задействованной в разработке и тестировании структуры, условно, до одного человека помогает минимизировать число ошибок, выявляемых на поздних этапах, когда, например, выясняется, что какие-то важные сценарии и требования разработчиком учтены не были, а пользователь счел их само собой разумеющимися.
  • Упрощение и ускорение процесса миграции на новую систему BI. Одним из преимуществ использования self-service BI является то, что многократно увеличивается ресурс компании в части разработки дашбордов, способствуя развитию подхода data-driven, отказа от анализа в Excel и перехода к бизнес-аналитике. Также это позитивно влияет на общую культуру работы с данными. Помимо этого внедрение self-service облегчает процесс возможной миграции дашбордов на новые инструменты бизнес-аналитики, например в рамках программ импортозамещения. По сути, этот процесс передается от ИТ к самим пользователям-разработчикам дашбордов.

Подводные камни

Self-service BI не только открывает большие возможности, но и создает для компании определенные проблемы, в значительной степени связанные с резким ростом количества разработчиков без ИТ-квалификации.

  • Неверифицированные данные для принятия решений. Внедрение self-service BI только тогда можно назвать полноценным, когда пользователи имеют из системы бизнес-аналитики доступ к своим данным и могут самостоятельно использовать различные источники для расчета нужных показателей и создания собственных дашбордов. Соответственно, пользователи должны иметь возможность подгружать и использовать данные из Excel, Google Sheets и пр., однако это приводит к тому, что данные, которые используются в отчетах, могут оказаться не актуальными, некорректными, противоречивыми. Чтобы минимизировать риски принятия решений на основе неверных данных, нужно в первую очередь определить уровень доверительности для всех дашбордов, попадающих к руководителям. В ряде компаний пользователям, самостоятельно создающим свои дашборды, запрещено их публиковать для широкого круга сотрудников. При этом решения, которые находятся в зоне ответственности самого сотрудника, он может свободно принимать на основании своего анализа. Хорошая практика, когда дашборд строится на верифицированной промышленной витрине, используемые алгоритмы соответствуют утвержденным методикам (тут полезен бизнес-глоссарий). Такой дашборд маркируется как «промышленный». Если же дашборд сделан пользователем и в нем использованы непроверенные данные или алгоритмы, то это четко помечается, чтобы все сразу видели, что это лишь мнение конкретного автора. В некоторых компаниях валидированные дашборды и дашборды self-service просто лежат в разных папках. С одной стороны, такой подход не усложняет работу и не ограничивает свободу пользователей, а с другой — не позволяет потенциальному хаосу вырваться наружу.
  • Хаос визуальных представлений. Еще одна проблема внедрения self-service BI — различное понимание наглядности разными людьми. Если вопросам единого подхода к визуализации не уделяется должного внимания, то с переходом на self-service проблема многократно усложняется — участниками процесса разработки становится множество людей с разным жизненным и профессиональным опытом, разными представлениями об идеальном дашборде. В итоге обычно получается так, что один и тот же показатель, например, прибыль по годам, выводится в одном дашборде в виде столбчатой диаграммы, в другом в виде линейного графика, а в третьем в форме сегментной диаграммы. То же можно сказать и о принципиально разных подходах к цветовой палитре. Проблема решается путем «учебника по визуализации», включающего типовые шаблоны дашбордов и рекомендации по их разработке, привязанные к BI-инфраструктуре и особенностям процессов конкретной организации.
  • Программно-аппаратная инфраструктура. Проблема создания и поддержки адекватной инфраструктуры характерна для многих ИТ-решений общекорпоративного уровня. Но при действительно масштабном внедрении self-service BI ее не избежать, ведь ресурсы, требуемые для работы системы BI, сильно зависят от количества активных пользователей. Как только сотрудники становятся не просто потребителями готовых отчетов, а сами начинают создавать запросы, формировать алгоритмы обработки данных и расчетов показателей, то нагрузка на инфраструктуру значительно возрастет. Помимо чисто количественного расширения, есть еще проблема запросов к данным пользовательских дашбордов и их расчетных алгоритмов, которые обычно оказываются далеко не такими оптимальными, как те, которые создают и отлаживают дата-инженеры. Решение лежит в организационной и технологической плоскостях. В ряде случаев для пользователей self-service BI создают отдельный контур бизнес-аналитики со своим сервером или кластером, выделяют отдельные квоты на сервере баз данных. Однако при этом сама идея продвижения self-service BI подвергается опасности — ресурсы для пользователей выделяют по остаточному принципу и они станут постоянно сталкиваться с проблемами производительности дашбордов. Более современный и технологичный способ — использование средств управления приложениями, таких как Kubernetes (рис. 1). Если архитектура позволяет гибко управлять выделяемой мощностью в зависимости от приоритета и сложности запросов, то проблему выделения нужных ресурсов пользователям self-service BI и производительности их отчетов можно решить без излишних затрат. Также надо отметить важность встроенного высокопроизводительного движка обработки данных, который благодаря своим возможностям может нивелировать ошибки пользователей и позволяет даже непрофессионалам в области управления данных получить приемлемые показатели по скорости отклика дашбордов.
Self-service BI — время пришло?
Рис. 1. Масштабируемая отказоустойчивая архитектура BI

Self-service BI — не только функционал и технологии

Когда говорят о self-service BI, в первую очередь речь заходит о собственно инструменте и его пригодности для самостоятельного использования широким кругом аналитиков и бизнес-пользователей. Имеются различные варианты таблиц "self-service ready" — сравнения разных продуктов по набору критериев (рис. 2). Однако успех зависит не только от свойств BI-инструмента, но и от других параметров. Есть масса примеров, когда даже с Power BI или Tableau переход на самообслуживание оказывается неудачным. Рассмотрим ряд факторов, от которых принципиально зависит успех внедрения self-service BI.

Self-service BI — время пришло?
Рис. 2. Фрагмент таблицы сравнения "self-service Ready"
  • Наличие и доступность данных. Для бизнес-аналитики данные критичны, но если профессиональные BI-разработчики способны подключиться и выкачать данные, при необходимости даже с помощью сложных интеграционных интерфейсов, то обычные бизнес-пользователи к этому, как правило, не готовы. Если не обеспечить их достаточно простыми способами получения требуемых сведений, то их интерес к self-service BI быстро угаснет. Старт проектов self-service до того, как организация разберется в своих данных и построит полноценное хранилище или «озеро данных», обречен на провал независимо от размеров компании, даже если она пользуется лишь «1С: Бухгалтерией» и «Битрикс24», а не сотней разных систем-источников. Если от бизнес-пользователя потребуется постоянно выгружать данные, приводить их к общему знаменателю, очищать от дублей, пропусков и пр., то это либо сразу окажется для них невыполнимой задачей, либо резко охладит их энтузиазм.
  • Сложность взаимодействия со службой информационной безопасности. Различные компании практикуют разные подходы к получению доступа к данным. В некоторых нужно потратить несколько месяцев, чтобы согласовать обращение к одной табличке, а в других жесткие ограничения установлены только на самые конфиденциальные данные (персональные данные, коммерческая тайна и т. п.). Любые препятствия охлаждают интерес пользователей к самостоятельной работе с данными, и хуже всего действует прямое столкновение с бюрократией компании в лице службы информационной безопасности. Один из ключевых моментов при организации self-service BI — сразу определить данные, которые доступны максимально просто, а затем сформировать четкий регламент, как быстро получить доступ к более закрытым сведениям. Очевидно, что для этого нужны правильная организация процессов доступа к данным и BI-система, поддерживающая гибкое разграничение доступа к данным и предоставляющая развитые инструменты аутентификации.
  • Предоставление лицензий. Подавляющее большинство BI-решений лицензируется по числу пользователей, обычно предусматривая две их категории: разработчики, создающие и меняющие дашборды; рядовые пользователи, работающие в интерактивном режиме с готовыми дашбордами (просмотр, фильтрация, детализация, переход к смежным показателям и т. п.). Стоимость лицензии для разработчика обычно в несколько раз выше, чем для простого пользователя, поэтому предоставлять всем подряд лицензию разработчика экономически не выгодно и часто не оправдано. С другой стороны, неправильно сдерживать инициативу пользователей, готовых к полноценной самостоятельной работе. Запуская проект перехода к self-service BI, нужно сразу согласовать бюджет и закупить нужное для старта проекта число лицензий, организовав процесс оперативного предоставления пользователям лицензий на разработку так, чтобы это не вызывало дискомфорта из-за бюрократии и долгого ожидания, а также излишних затрат. Лучше, если в компании выстроен автоматизированный процесс управления лицензиями BI — текучку кадров никто не отменял, и если в компании 20% или более дорогостоящих лицензий просто «лежат на полке», то это не самый эффективный способ внедрить self-service BI, также как и очередь на лицензии на несколько месяцев вперед.
  • Гибкое управление ресурсами. Одно дело, когда несколько разработчиков строят и отлаживают дашборды в среде разработки, и совсем другое, когда сотни пользователей создают для себя новые отчеты, в режиме ad-hoc исследуя огромные массивы данных с помощью BI-инструмента. При переходе к self-service BI приходится не только выделять дополнительные мощности на создаваемую вновь прибывшими разработчиками дополнительную нагрузку, но и заботиться о внедрении бизнес-аналитики в гибкой кластерной архитектуре. Такая архитектура должна позволять быстро перераспределять ресурсы, не допускать отказа в случае «падения» одного процесса из-за некорректного запроса. Проблема гибкого управления ресурсами не нова и хорошо решается в облаках, главное, не забывать, что переход к self-service BI, особенно если он масштабный, вряд ли возможен на старом оборудовании и при сохранении привычных подходов к управлению аппаратными ресурсами.
  • Обучение. Почему-то принято считать, что если компания приобрела хороший BI-инструмент с интуитивно понятным интерфейсом и бизнес-пользователи начинают практически без подготовки использовать дашборды, то, значит, и разрабатывать свои дашборды эти пользователи смогут также легко, достаточно лишь предоставить лицензию и доступ к данным. На практике это не так — большинство пользователей, хорошо освоивших Excel и глубоко разбирающихся в своих профессиональных темах, далеки от тонкостей разработки. Помимо «учебника по визуализации», пользователям нужен как минимум базовый курс по разработке дашбордов, причем не абстрактный курс от вендора, а привязанный к инфраструктуре и процессам конкретной организации. Не обязательно, а зачастую и неправильно отправлять всех, кто сам создает дашборды, на курсы к вендору — их лучше обучать на местах, сформировав и предварительно обучив специальную внутреннюю команду преподавателей в составе центра компетенции BI, обычно из числа профессиональных разработчиков. Важно, чтобы такие курсы читались регулярно, что позволит быстрее решать вопросы погружения новых пользователей в среду self-service BI.
  • Data Governance. Работающая в компании система Data Governance — это во многих случаях принципиальный фактор, определяющий успех внедрения self-service BI. Конечно, Data Governance требуется не только для BI, но и для всех без исключения процессов и задач, связанных с использованием данных в организации. Но без наличия удобного доступа к бизнес-глоссарию и дата-каталогу пользователям сложно разобраться, как правильно посчитать те или иные показатели либо обнаружить их в уже реализованных дашбордах. Трудно понять, в каких источниках лежат нужные данные для отчета, в какие витрины эти данные загружены и как их оттуда правильно взять. Также без Data Governance сложно определить, каким данным и в какой степени можно доверять. Без Data Governance на вопросы, что уже есть в витринах данных и какие витрины для чего лучше использовать, придется бесконечно отвечать специалистам ИТ. Безусловно, все нужные сведения могут содержаться в каких-либо документах, регламентах, методиках, но с такой разрозненной информацией работать сложно, особенно неподготовленному пользователю. Кроме этого, любая документация быстро устаревает. В итоге, столкнувшись с трудностями поиска, пользователь просто сделает новый алгоритм, который будет отличаться от ранее согласованного и будет использовать набор атрибутов, показавшихся пользователю подходящими для его задачи здесь и сейчас, а это чревато ростом числа ошибок. Чем больше пользователей self-service BI, шире набор данных и количество дашбордов, тем больше в компании потребность в Data Governance. Подумать о внедрении Data Governance стоит уже в момент принятия решения о внедрении самообслуживания в BI.
  • Развитое сообщество BI. Десятки активных пользователей self-service BI могут загрузить своими вопросами и проблемами центр компетенции BI даже больше, чем если бы этот центр сам разрабатывал все дашборды. Особенно в условиях текучки кадров, когда каждый месяц появляется новая группа пользователей, с энтузиазмом приступающих к освоению BI-инструмента и принципов работы с данными. Снизить нагрузку на центр компетенции помогает организованное внутри компании BI-сообщество, в котором сами пользователи поддерживают друг друга, делятся знаниями и находками, и пр. Главное — правильно организовать работу такого сообщества и не относиться к этому как к самодостаточному процессу, надеясь, что комьюнити само себя создаст и разовьет. Обычно в успешных организациях BI-сообщество — это активная структура со своим энергичным модератором, вероятность успешного внедрения self-service BI в таких компании многократно возрастает.

***

Внедрение self-service BI не следует воспринимать как простое развитие обычного BI-проекта, когда, например, подразделение ИТ решает, что теперь пользователи будут сами делать свои дашборды, потому что исчерпались ресурсы разработчиков или появилось множество пользователей, требующих сделать дашборд, но неспособных внятно объяснить, что им на самом деле надо. Могут быть различные причины для перехода на self-service BI, но пока не запустить эту задачу именно как полноценный проект, на успех рассчитывать не приходится. У такого проекта обязательно должен быть и куратор от топ-менеджмента, и проектный менеджер, и календарный план, и пул ресурсов, и бюджет. Если не забывать, что self-service BI — это полноценный проект, и учитывать разобранные в статье вопросы, то такой проект принесет экономический эффект организации и, что немаловажно, станет краеугольным камнем внедрения культуры data-driven.

Литература

1. Иван Вахмянин. Excel vs бизнес-аналитика // Открытые системы.СУБД. — 2020. — № 1. — С. 28–29. URL: https:/www.osp.ru/os/2020/01/13055349 (дата обращения: 21.03.2025).

2. Яков Кротов. Бизнес-аналитика self-service — быть или не быть? // Открытые системы.СУБД. — 2024. — № 4. — С. 45–47. URL: https://www.osp.ru/os/2024/04/13059029 (дата обращения: 21.03.2025).

Юлий Гольдберг (contact@glowbyteconsulting.com) — руководитель направления, GlowByte (Москва).