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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организационное влияние инструментов бизнес-аналитики

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

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

Технические ограничения инструментов бизнес-аналитики

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

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

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

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

Бизнес-ограничения инструментов бизнес-аналитики

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

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

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

Взгляд Lokad

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

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

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

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

Примечания