Бизнес-интеллект (BI)

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

Происхождение и мотивация

Современный аналитический отчет появился вместе с первыми экономическими прогнозистами^{1 2}, преимущественно в США, в начале XX века. Эта ранняя версия оказалась чрезвычайно популярной, получив внимание в мейнстримной прессе и широкое распространение. Такая популярность продемонстрировала явный интерес к количественным отчетам с высокой информационной плотностью. В 1980-х годах многие крупные компании начали сохранять свои деловые транзакции в виде электронных записей, хранящихся в транзакционных базах данных, как правило, с использованием некоторых ранних ERP-решений. Эти ERP решения были в первую очередь предназначены для оптимизации существующих процессов, повышения производительности и надежности. Однако многие осознали огромный неиспользованный потенциал этих записей, и в 1983 году SAP представила язык программирования ABAP ³, предназначенный для создания отчетов на основе данных, собранных в самом ERP.

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

В начале 1990-х годов прогресс в области вычислительной техники позволил появление другого класса программных решений ⁴ – решений Бизнес-интеллекта. Стоимость оперативной памяти (RAM) неуклонно снижалась, в то время как её объем неуклонно возрастал. В результате хранение специализированной, более компактной версии бизнес-данных в памяти (RAM) для мгновенного доступа стало жизнеспособным решением с технологической и экономической точки зрения. Эти достижения устранили два основных ограничения систем создания отчетов, реализованных десятилетие назад: новые программные интерфейсы стали гораздо более доступны неспециалистам, а современные серверные решения – с использованием технологий OLAP (рассмотренных ниже) – устранили некоторые из самых серьезных IT-ограничений. Благодаря этим достижениям к концу десятилетия решения BI стали мейнстримом среди крупных компаний.

По мере дальнейшего прогресса компьютерного оборудования в конце 2000-х годов появилось новое поколение BI-инструментов ⁵. Реляционные системы баз данных 1980-х годов, неспособные удобно создавать отчеты, стали в 2000-х годах все более способными хранить всю транзакционную историю бизнеса в оперативной памяти. В результате сложные аналитические запросы могли выполняться за считанные секунды без специализированной OLAP-системы. Таким образом, фокус решений BI сместился на фронтенд, предоставляя еще более доступные веб-интерфейсы – преимущественно в формате SaaS (программное обеспечение как услуга) – и сопровождаясь все более интерактивными панелями управления, использующими универсальность реляционного бэкенда.

OLAP и многомерные кубы

OLAP расшифровывается как онлайн аналитическая обработка. OLAP связан с проектированием бэкенда BI-решения. Термин, введенный в 1993 году Эдгаром Коддом, объединяет ряд идей проектирования программного обеспечения ⁶, большинство из которых возникли до 1990-х годов, а некоторые восходят к 1960-м годам. Эти идеи сыграли ключевую роль в появлении BI как отдельного класса программных продуктов в 1990-х. OLAP решал задачу создания свежих аналитических отчетов своевременно, даже когда объем данных, участвующих в формировании отчета, был слишком велик для быстрой обработки.

Самый простой метод создания свежего аналитического отчета предполагает прочтение данных хотя бы один раз. Однако, если набор данных настолько велик ⁷, что его полное прочтение занимает часы (а то и дни), то создание обновленного отчета также будет занимать часы или дни. Таким образом, чтобы сформировать обновленный отчет за считанные секунды, метод не может предполагать повторного полного чтения набора данных каждый раз при запросе обновления отчета.

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

Рассмотрим следующий пример: представьте сеть розничной торговли с 100 гипермаркетами. Финансовый директор хочет получить отчет с общими продажами в евро по каждому магазину за каждый день за последние 3 года. Исходные исторические данные о продажах за этот период составляют более 1 миллиарда строк (каждый отсканированный штрихкод во всех магазинах за этот период) и занимают более 50 ГБ в своем исходном табличном формате. Однако таблица с 100 столбцами (по одному для каждого гипермаркета) и 1095 строками (3 года * 365 дней) в сумме занимает менее 0.5 МБ (при размере 4 байта на число). Более того, при каждой транзакции соответствующие ячейки в таблице могут обновляться. Создание и поддержка такой таблицы иллюстрирует, как выглядит система OLAP под капотом.

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

Интерактивная отчетность и визуализация данных

Обеспечение доступности возможностей отчетности для конечных пользователей, не являющихся IT-специалистами, стало ключевым фактором в принятии BI-инструментов. В связи с этим технология приняла концепцию WYSIWYG (what-you-see-is-what-you-get), опираясь на насыщенные пользовательские интерфейсы. Этот подход отличается от обычного способа взаимодействия с реляционной базой данных, который заключается в составлении запросов с использованием специализированного языка (например, SQL). Обычный интерфейс для управления OLAP-кубом представляет собой матричный интерфейс, подобный сводным таблицам в программе электронных таблиц, который позволяет пользователям применять фильтры (называемые slice and dice в терминологии BI) и выполнять агрегационные операции (среднее, минимум, максимум, сумма и т.д.).

За исключением обработки особенно больших наборов данных, потребность в OLAP-кубах снизилась в конце 2000-х годов наряду с огромными достижениями в области вычислительной техники. Были представлены новые «тонкие» BI-инструменты, ориентированные исключительно на фронтенд. Тонкие BI-инструменты были в первую очередь разработаны для взаимодействия с реляционными базами данных, в отличие от их «толстых» предшественников, использовавших интегрированные серверные решения с OLAP-кубами. Эта эволюция стала возможна благодаря тому, что производительность реляционных баз данных в то время обычно позволяла выполнять сложные запросы по всему набору данных за считанные секунды – при условии, что объем данных оставался ниже определенного размера. Тонкие BI-инструменты можно рассматривать как унифицированные WYSIWYG-редакторы для различных поддерживаемых SQL-диалектов. (На самом деле, под капотом эти BI-инструменты генерируют SQL-запросы.) Основной технической проблемой была оптимизация генерируемых запросов для минимизации времени отклика соответствующей реляционной базы данных.

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

Организационное влияние BI

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

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

Технические ограничения BI

Как это часто бывает, существует компромисс между достоинствами BI-инструментов, то есть большая простота доступа достигается за счет выразительности; в данном случае преобразования данных ограничиваются достаточно узким классом фильтров и агрегаций. Это первое существенное ограничение, поскольку многие – если не большинство – бизнес-вопросов не могут быть решены с помощью этих операторов (например, каков риск оттока клиента?). Конечно, добавление расширенных операторов в интерфейс BI возможно, однако такие «расширенные» функции сводят на нет ⁸ изначальную цель сделать инструмент легко доступным для пользователей без технического образования. Таким образом, разработка сложных запросов к данным не отличается от создания программного обеспечения, что является по своей природе сложной задачей. По анекдотическим данным, большинство BI-инструментов предлагают возможность писать «сырые» запросы (обычно на SQL или похожем на SQL диалекте), прибегая к техническому подходу, который должен был быть устранен данным инструментом.

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

У толстых BI-инструментов производительность ограничивается конструкцией самих OLAP-кубов. Во-первых, объем оперативной памяти, необходимый для хранения многомерного куба, быстро растет с увеличением числа измерений куба. Даже умеренное количество измерений (например, 10) может привести к серьезным проблемам, связанным с занимаемым кубом объемом памяти. В общем, решения, основанные на хранении в памяти (OLAP-кубы являются наиболее распространенными), обычно страдают от проблем, связанных с оперативной памятью.

Более того, куб является с потерями представлением исходных транзакционных данных: никакой аналитикой, проведенной с использованием куба, нельзя восстановить информацию, утраченную изначально. Вспомним пример гипермаркета. В таком сценарии, корзины не могут быть представлены в кубе. Таким образом, информация о том, что товары покупались вместе, теряется. Общая конструкция OLAP-«куба» значительно ограничивает, какие данные могут быть представлены; однако именно это ограничение и делает возможным свойство «онлайн» в первую очередь.

Бизнес-ограничения BI

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

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

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

Точка зрения Lokad

Учитывая возможности современного вычислительного оборудования, с помощью системы отчетности легко сгенерировать 1 миллион чисел в день; создать 10 чисел в день, достойных внимания – вот что сложно. Хотя использование инструмента BI в умеренных объемах полезно для большинства компаний, в больших дозах он становится ядом.

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

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

Платформа Lokad platform features обладает обширными возможностями создания индивидуальных отчетов, подобно BI. Однако, в отличие от BI, Lokad нацелена на оптимизацию бизнес-решений, а точнее – решений, касающихся цепочки поставок. На практике мы рекомендуем назначить специалиста по цепям поставок ответственным за разработку, а затем поддержку числового рецепта, который генерирует – посредством Lokad – решения по цепочке поставок, представляющие интерес.

Примечания