Hi-tech блог

Bi приложения. Что такое Business Intelligence? Тенденции на рынке BI-платформ

Что такое BI-система, и как она работает

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

Этап №2. Организация данных

Тут тоже можно пойти двумя путями: от общих бизнес-требований или от нужд каждого подразделения. В первом случае нужно сначала проанализировать все бизнес-требования, затем проработать нужды каждого департамента. Второй подход итеративный – мы разбиваем весь объем работ на отдельные области, и в деталях описываем, как будут выглядеть аналитика и отчеты для отдела маркетинга, затем для финансов, HR и дальше идем итерациями по всем отделам.

Если хотите быстрее получить результат в виде первых отчетов, то второй вариант подойдет больше – при работе итерациями, пока следующая модель проектируется, первая уже работает. При общем подходе вы быстрее получите конечный результат, то есть общую аналитику по всем отделам.

Этап №3. Выбор стека технологий

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

Этап №4. Проектирование интерфейсов

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

Этап №5. Тестирование системы

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

В этом случае нужно разработать сценарии тестирования. Возьмите выгрузки по одному из направлений за заданный период и точность сведений на этом же срезе данных из той же учетной системы. Например, вы взяли из системы отчет по остаткам с 1 по 15 февраля, и он был равен 1000 единиц. На этом же срезе данных в учетной системе остаток тоже 1000 единиц. Значит, системе можно верить – данные корректные. По-другому найти эту точку сходимости, на мой взгляд, невозможно.

Отдельная тема – внедрение системы на динамически меняющийся источник данных, или когда мы внедряем решение на данных Excel, но этап загрузки данных необходимо перенести на вновь внедренный источник, в котором могло поменяться все от структуры хранилища до самих сведений. Здесь внедрение и тестирование будет идти по иным правилам.

Этап №6. Обучение команды

На проектах мы стараемся обеспечить максимальный результат от использования системы. Для этого проводим обучение финансистов, маркетологов, IT-специалистов и управленцев: знакомим с платформой, возможностями доработки и управления нашим решением, учим менеджеров максимально использовать все возможности программы. В помощь администраторам и пользователям разрабатывается сопроводительная документация: классические «Руководство администратора» и «Руководство пользователя», а часто и обучающие видеоролики. Самый детальный и сложный, но полезный материал – тот, что обычно называется «Техпроект» или «Спецификация отчетов». Он описывает весь процесс движения данных от источников до конечных отчетных форм. Не пренебрегайте этим документом. С его помощью любой новичок в команде сможет разобраться, как данные попадают в первый слой загрузки, и где они находятся в выходных отчетных формах. С помощью этого материала любое изменение или просьба по доработке системы займут минимальное количество времени.

Частые ошибки при внедрении

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

  • Не разбираться в типах платформ. Существуют системы класса in-memory, которым не нужны системные хранилища данных; и платформы, которые требуют двухкомпонентную архитектуру, то есть отдельное хранилище и отдельный BI-инструмент для визуализации.
  • Работать крупными мазками. Этапы загрузки, трансформации и последующей загрузки данных в приложение всегда стоит максимально детализировать и разбивать на более короткие отрезки. Многие в одном скрипте загружают, трансформируют данные, и делают последующую выгрузку. С гигантскими кусками кода не справится ни подрядчик, ни клиент. Но если код разбит на маленькие кусочки, определить, что вышло из строя, будет легко. Это сэкономит время и деньги на последующую поддержку.
  • Сразу автоматизировать . Нельзя сразу отдавать в разработку отчеты от бизнес-пользователей. Возможно, они не видели других, более удобных форматов. Может быть, раньше они сталкивались с техническими ограничениями и не могли представить анализ по-другому. Простая разработка не решает задач бизнеса – нужно глубже погружаться в отрасль и процессы в компании, выяснять, в чем заключаются проблемы и целенаправленно с ними работать.

Сколько это стоит и от чего зависит

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

Чем помогут консультанты

Часто консультанты самостоятельно выполняют весь объем работ и минимально привлекают сотрудников клиента. Но случается, что объем работ собственных сотрудников соизмерим с объемом работ интегратора. В зависимости от задач и финансовых возможностей клиента, компания-консультант может участвовать в проекте в нескольких форматах.

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

Недостаток ресурсов. Чтобы проворно систематизировать требования и не менее стремительно построить на их основе систему, могут потребоваться дополнительные ресурсы, поскольку новые запросы появляются постоянно. Часто для анализа в компании используют один инструмент, для финансовой аналитики – другой, а маркетинговую эффективность считает третий. Целый штат IT-специалистов содержать бессмысленно и неэкономно. Здесь поможет подрядчик, который уже вырастил квалифицированные кадры и умеет оптимизировать затраты на подобные задачи.

Новая задача. Если внедрением IT-решений раньше вы не занимались и не очень четко понимаете, с какого конца начать, стоит хотя бы проконсультироваться со специалистом. Риск потери возможной прибыли и времени абсолютно точно окупит затраты на эту консультацию.

Выводы

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

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

Примечание

Я являюсь техническим специалистом, соответственно статья имеет более технический уклон. Если есть желание почитать информацию по продукту, ориентированную на бизнес пользователей, то вам на офсайт IBM.

Основная цель этой статьи, показать вам как сделать свой первый «Hello World» (по аналогии с программированием) в IBM Cognos BI.

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

Что такое BI?

Итак, что же такое BI система? Если в трех словах, то это продвинутая система отчетности. Что-бы было более понятно, ниже перечислю список основных функций, которыми располагают современные системы класса BI:
  • возможность подключения к различным источникам данных (от файла Excel до универсального ODBC подключения)
  • возможность построения как простых отчетов (типа график или таблица), так и сложных параметризированных отчетов с комбинированной структурой и ссылочными связями (Drill-Trough, Drill-Up/Drill-Down)
  • возможность прозрачной работы с разными источниками данных (например, Excel и SQL Server) с полноценной обработкой связей между ними
  • возможность интерактивной работы с данными (формирование отчетов «на лету»)
  • возможность представления реляционных данных как многомерные
  • возможность распределения прав доступа используя как внутренние источники аутентификации, так и внешние (NTLM, LDAP и т. д.)
  • возможность запуска формирования отчетов как вручную, так и автоматически по расписанию
  • возможность автоматической рассылки сформированных отчетов
  • возможность построения отчетов в различных форматах (Excel, HTML, PDF и т. д.)
Говоря простым русским языком, BI система – это такая программа, которая предоставляет пользователю удобные инструменты анализа фактически любых данных (будь то файл Excel либо промышленное хранилище данных).

Возможность применения BI системы в качестве персонального инструмента

Сразу становится вопрос, как можно использовать эту систему в качестве персонального инструмента? Отвечу по личному примеру, я использую IBM Cognos BI в качестве инструмента по анализу статистики в своих проектах и инструмента по анализу статистики домашней бухгалтерии.

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

Опять-таки, все написанное это лично мое мнение, с которым вы не обязаны соглашаться.

Архитектура IBM Cognos BI

Архитектура системы относительно несложная (как для системы корпоративного класса). Итак, ключевым элементом системы является IBM Cognos BI сервер (см. схему ниже), который работает с источниками данных, используя созданное пользователем описание (именуемое метаданными). Далее, посредством Web доступа, IBM Cognos BI сервер предоставляет доступ ко всем основным функциям системы.

Концептуальная архитектура комплекса IBM Cognos BI (схема получилась весьма громоздкой)


Этапы работы с системой

Чтобы сделать свой первый отчет необходимо выполнить несколько основных этапов:
  1. Создать подключение к источнику данных
  2. Сформировать описание источника данных, т. е. создать метаданные
  3. Создать и опубликовать пакет метаданных на IBM Cognos BI сервере
  4. Создать отчет

Структура тестового источника данных

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

Как видно на схеме выше, в тестовой базе данных содержится 3 иерархических измерения: «Группа товара -> Товар», «Континент -> Страна -> Город -> Торговая точка», «Год -> Полугодие -> Квартал -> Месяц -> Дата»; 2 плоских (одномерных) измерения: «Кассир», «Региональный руководитель»; и 2 таблицы фактов: «Продажи», «План продаж».
Причем измерение «Кассир» расположено в одной из таблиц фактов в денормализованном виде, а измерение «Региональный руководитель» привязано к уровню «Страна» измерения «Торговая точка» связью «многие ко многим» (подразумевается, что один руководитель может управлять разными странами).

Подключение к источнику данных

В IBM Cognos BI все необходимые параметры для подключения к источникам данных хранятся в специальных объектах системы, которые так и называются «Data Source Connections». Чтобы создать новое подключение, необходимо выполнить несколько простых шагов: зайти на портал IBM Cognos BI, перейти в раздел «Администрирование» («Administration»), открыть вкладку «Конфигурация» («Configuration»), выбрать подраздел «Подключения источника данных» («Data Source Connections») и нажать кнопку «Новый источник данных» («New Data Source») в панели инструментов. Далее появится серия диалоговых окон, в которых будет необходимо задать несколько параметров, таких как название подключения, тип соединения, сервер, логин, пароль и т. д.

Разработка метаданных

Разработка метаданных, это один из самых сложных и ответственных моментов. От качества метаданных зависит, как работоспособность системы (скорость формирования отчетов, корректность сформированных результатов и т. д.) так и удобство разработки отчетов. Но несмотря на вышесказанное, сложность разработки метаданных прямо пропорциональна сложности источника данных. Например, чтобы построить реляционное описание нашего тестового источника данных, достаточно запустить мастер построения метаданных, несколько раз кликнуть кнопку «Next», и метаданные готовы.

Итак, как я уже писал ранее, метаданные – это описание источника данных. В IBM Cognos BI. Фундаментом метаданных являются объекты «Query Subject» и связи между ними. Объект «Query Subject» это синоним «View» из реляционных СУБД. Т. е. в основе «Query Subject» стоит запрос к СУБД, определяющий структуру объекта источника, а связи между «Query Subject» это описание логического взаимодействия между этими запросами.

Для создания метаданных в IBM Cognos BI используется отдельное приложение IBM Cognos Framework Manager (единственное не Web приложение в комплексе IBM Cognos BI). После запуска Framework Manager будет предложено создать новый проект (необходимо будет ввести наименование проекта и его расположение в локальной файловой системе).

Следует понимать, что проект Framework Manager (также именуемый как модель Framework Manager) это набор локальных файлов, с которыми работает локальная программа, а пакет метаданных это результат, который располагается на IBM Cognos BI сервере (если проводить аналогию с программированием, то проект – это исходный код, а пакет – это скомпилированное приложение). На базе одного проекта Framework Manager можно создать несколько наборов пакетов.

После того как проект Framework Manager создан, лучше всего начать работу с запуска мастера импорта метаданных (Action -> Run Metadata Wizard …). Мастер импорта предложит выбрать существующий источник данных или создать новый и позволит выбрать необходимые объекты для импорта. В простейшем случае (например, когда источником данных является файл Excel, который в 99,9% случаев содержит данные в денормализованном виде) нужно будет полям объекта «Query Subject» задать правильный тип использования (атрибут «Usage») и на этом работу с моделью Framework Manager можно заканчивать и приступать к формированию и публикации пакета метаданных. В более сложном варианте (как в нашем тестовом примере), необходимо будет проверить правильность импортированных связей между объектами «Query Subject», исправить некорректные и добавить недостающие. В более профессиональных вариантах есть возможность создавать вычисляемые поля, менять структуру «Query Subject», сформировать многомерное (multidimensional) представление, определить алгоритмы безопасности и т.д.

Создание и публикация пакета метаданных

После того как метаданные созданы, необходимо сформировать метапакет и опубликовать его на IBM Cognos BI сервере. Как я упоминал ранее, метапакет – это некоторое подмножество метаданных, которое публикуется на сервере и с которым работают все Web приложения комплекса IBM Cognos BI. Настройки метапакета позволяют скрыть или не публиковать некоторые объекты метаданных. Например, в тестовых метаданных есть некоторый «Query Subject» , который влияет на логику обработки данных источника (является связующим звеном между страной и региональным директором), но не представляет ценности при разработке отчетов, вот такой объект метаданных имеет смысл скрыть на уровне пакета. Или, например, поля с идентификаторами, их тоже имеет смысл скрыть от пользователей метапакетов.

Чтобы создать метапакет необходимо в Framework Manager, в разделе «Packages» вызвать контекстное меню и выбрать пункт «Create -> Package», после чего появится мастер создания метапакета. После того как метапакет будет создан, система сразу предложит его опубликовать на сервере. Начинающему пользователю можно сильно не вникать опции мастера публикации пакетов (просто нажимать кнопку Next и Publish). Единственно что, на последней вкладке (где будет не кнопка Next, а кнопка Publish) будет птичка «Verify package before publish», она определяет проверять ли метапакет на наличие логических неоднозначностей перед публикацией и отображает список этих неоднозначностей, если они буду найдены. Настоятельно рекомендую никогда не пропускать этот шаг и исправлять все найденные неоднозначности перед публикацией.

Создание отчетов (анализ данных)

Вот мы потихоньку и подобрались к самому интересному и регулярному процессу – это создание отчетов. Так сложилось что инструменты для создания регулярных отчетов и инструменты для быстрого анализа данных в IBM Cognos BI одни и те же (несмотря на то что в одних удобнее проводить быстрый анализ, а в других удобнее формировать регулярные отчеты, все они позволяют сохранять свои результаты в виде отчетов).

Лично я предпочитаю для всех BI задач использовать инструмент IBM Cognos Report Studio. Это наиболее универсальный инструмент, позволяющий строить отчеты фактически любой сложности и в тоже время предоставляет относительно удобные инструменты для быстрого анализа данных.

Предположим, что нам необходимо создать быстрый отчет, содержащий факт продаж в разрезе страны, товарной группы и периодичностью в квартал. Этот достаточно простой отчет можно сделать, выполнив следующие шаги:

  1. запустить веб приложение IBM Cognos Report Studio
  2. в окне приветствия нажать кнопку «создать» («create»)
  3. в списке базовых шаблонов выбрать «перекрестная таблица» («corsstab»)
  4. разместить элементы данных согласно схеме, представленной ниже
  5. запустить отчет на выполнение

После запуска отчета на выполнение, получится примерно такой результат.

Глядя на получившийся отчет можно смело сказать, что оформлен он откровенно плохо, числа не отформатированы, экономический смысл откровенно сомнителен и т. д. Но все эти недостатки оформления можно убрать путем задания свойств соответствующих элементов настроек, а чтобы экономический смысл был более интересен, можно, например, сделать план/факт анализ.

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

А чтобы его полностью переоформить в темную цветовую схему, я потратил где-то еще 10 минут.

Заключение

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

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

Немного о лицензиях

Если вы решите купить отдельно систему IBM Cognos BI для персонального пользования или для небольшой фирмы, то наверняка цены вас неприятно удивят, но у IBM есть специальная комплексная система IBM Cognos Express, которая рассчитана на небольшие организации, содержит в себе несколько продуктов (включая BI) и стоит значительно дешевле.

Существует огромное количество терминов: аналитика, data mining, анализ данных, business intelligence и разница между ними не всегда столь очевидна даже для людей, которые с этим связаны. Сегодня мы расскажем о том, что же такое Business Intelligence (BI) доступным и понятным языком. Тема безусловна огромна и её не покрыть лишь одной короткой статьей, но наша задача - помочь сделать первый шаг и заинтересовать читателя темой. Заинтересованный же читатель также найдет исчерпывающий список для дальнейших шагов.

Структура статьи

Зачем всё это нужно: из жизни аналитика

(кликабельно)

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

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

Минусы такого подхода:

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

Если мы поднимемся на уровень целой организации, то увидим, что проблем даже больше.

В чем задача: проблема на уровне компании

(кликабельно)

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

Принципиально, задача выглядит схожим образом: пусть у нас есть N магазинов и K дистрибьюторов, можем ли агрегировать данные магазинов и сравнить их с результатами дистрибьюторов? (У всех данные имеют разную структуру и формат.)

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

Рассмотрим несколько вариантов решения на уровне компании:

  • самописное решение: компании производителю будет необходимо нанять специалиста не по профилю компании и критичное ПО будет зависеть от данного специалиста. Если он уйдет, то компания будет вынуждена срочно искать замену, которая сможет поддерживать ПО и качество будет напрямую зависеть от нанятого специалиста;
  • закупить ПО у третьей стороны, тут три ключевых фактора: цена, качество и время интеграции. Как правило цена и время интеграции слишком высоки для среднего производителя, и в том числе требует существенных временных затрат сотрудников. Выбор поставщика также не тривиален;
  • SaaS решения: методология еще нова для рынка и многие компании скептически относятся к подобным сервисам.

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

Сам процесс на уровне компании выглядит схожим образом: консолидируется данные, определенным образом трансформируются (агрегируются) и загружаются в систему для анализа.
(кликабельно)

Обобщаем задачу: всё это звенья одной цепи

(кликабельно)

В чём же разница между аналитикой, data mining и business intelligence (BI)? Первые включают в себя комплекс методов для анализа уже чистых данных, а на практике очистка и преобразование данных в удобный для анализа формат - важный и неотъемлемый процесс. Так же помимо работы с преобразованием и консолидацией данных, основная задача BI - это принятие решений для бизнеса.

В 2007 году на рынке BI-платформ произошли серьезные изменения, связанные с его существенной консолидацией. Крупные вендоры совершили стратегические приобретения: Oracle завершила сделку по присоединению Hyperion, SAP объявила о присоединении Business Objects, Cognos закончила присоединение Applix и согласилась на слияние с IBM.

Как же данные события повлияли на рынок BI-платформ? Наиболее наглядный ответ на этот вопрос можно получить, взглянув на «магический квадрат» Gartner (рис. 1), где показано распределение ведущих производителей BI-платформ на начало 2007 и 2008 годов.

Рис. 1. Положение ведущих вендоров на рынке BI-платформ (источник: Gartner)

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

Что такое BI-платформа в толковании Gartner

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

Интеграция

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

Управление метаданными - все инструменты приложения должны не только опираться на одни и те же метаданные, но также должны обеспечиваться быстрый поиск, хранение, использование и публикация таких объектов метаданных, как размерности, иерархии, параметры оценки производительности и параметры оформления отчетов.

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

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

Средства предоставления информации

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

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

Рис. 2. Пример информационной панели (Dashboard)

Руководитель или аналитик, подобно пилоту самолета, видит перед собой «доску приборов» и управляет системой, ориентируясь на значения индикаторов. При этом ключевые факторы, необходимые для управления предприятием, должны быть так или иначе измерены и представлены в виде показателей. Девиз концепции: «Если вы не можете это измерить, значит вы не можете этим управлять» (“If you can’t measure it, you can’t manage it”).

Генератор нерегламентированных запросов (Ad hoc query) - данная функция, известная также как создание отчетов в режиме самообслуживания, дает пользователям возможность получать ответы на возникающие вопросы. Система предоставляет средства навигации по доступным ресурсам данных.

Интеграция с Microsoft Office - в ряде случаев BI-платформы используются как промежуточное звено в цепочке анализа информации, а Microsoft Office (в частности Excel) выступает как BI-клиент. В этих случаях очень важно, чтобы BI-вендор обеспечивал интеграцию с Microsoft Office, включая поддержку форматов документов, формул и сводных таблиц.

Средства анализа информации

OLAP (Online Analytical Processing - аналитическая обработка в реальном времени) - технология обработки информации, включающая составление и динамическую публикацию отчетов и документов. Используется для быстрой обработки сложных запросов к базе данных. Технология OLAP обеспечивает высокую скорость обработки запросов. Она делает мгновенный снимок реляционной БД и структурирует ее в пространственную модель для запросов. Дело в том, что реляционные БД хранят сущности в отдельных таблицах и сложные многотабличные запросы выполняются в них относительно медленно, в то время как пространственная БД является более удачной моделью для запросов. Заявленное время обработки запросов в OLAP составляет около 0,1% от аналогичных запросов в реляционную БД.

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

Рис. 3. Пример использования визуализации в предоставлении данных
на дэшборде Cognos

Предиктивное моделирование и дейта майнинг. Предиктивное моделирование (Predictive Modelling) - это процесс создания (или выбора) модели для предсказания вероятности наступления некоторого события. Дейта майнинг (Data Mining) - это процесс обнаружения в «сырых» данных ранее неизвестных, нетривиальных полезных и доступных интерпретации знаний, необходимых для принятия решений. Информация, найденная в процессе использования методов Data Mining, должна описывать новые связи между свойствами, предсказывать значения одних признаков на основе других и т.д. Найденные знания должны быть применимы и по отношению к новым данным с некоторой степенью достоверности. Когда извлеченные знания непрозрачны для пользователя, должны существовать методы постобработки, позволяющие привести их к интерпретируемому виду. Задачи, решаемые методами Data Mining, включают:

  • классификацию - отнесение объектов (наблюдений, событий) к одному из заранее известных классов;
  • регрессию, в том числе задачи прогнозирования; установление зависимости непрерывных выходных от входных переменных;
  • кластеризацию - группировку объектов (наблюдений, событий) на основе данных (свойств), описывающих сущность этих объектов. Объекты внутри кластера должны быть похожими друг на друга и отличаться от объектов, входящих в другие кластеры. Чем больше похожи объекты внутри кластера и чем больше различий между кластерами, тем точнее кластеризация;
  • ассоциацию - выявление закономерностей между связанными событиями. Примером такой закономерности служит правило, указывающее на то, что из события X следует событие Y . Такие правила называются ассоциативными. Впервые эта задача была предложена для нахождения типичных шаблонов покупок, совершаемых в супермаркетах, поэтому иногда ее еще называют анализом рыночной корзины (market basket analysis);
  • последовательные шаблоны - установление закономерностей между связанными во времени событиями, то есть обнаружение зависимости, согласно которой если произойдет событие X , то спустя заданное время произойдет событие Y ;
  • анализ отклонений - выявление наиболее нехарактерных шаблонов.

Карты показателей (Scorecards) используют контрольные показатели, отображаемые на информационной панели, для более глубокого анализа путем наложения их на некоторую стратегическую карту, которая увязывает ключевые параметры производительности со стратегическими задачами. Данную концепцию поясняет рис. 4. Технология предполагает дальнейший анализ на базе применения методологии управления производительностью, например Six Sigma.

Рис. 4. Сравнение ключевых параметров производительности
со стратегическими задачами

После того как мы пояснили термин BI-платформа, вернемся к анализу «магического квадрата» на рис. 1.

Критерии отбора и оценки компаний

В исследовании Gartner (см. рис. 1) участвовали компании, отобранные по следующим принципам:

  • предоставляющие как минимум 8 из 12 функций, свойственных BI-платформе;
  • занимающие заметную долю рынка BI-платформ, что подтверждается объемами продаж не менее 20 млн долл.;
  • решения на платформах которых работают на уровне предприятия, а не только на уровне отделов.

На рис. 1 использован ряд терминов, в соответствии с которыми вендоры расположены на плоскости квадрата. Поясним их значение:

  • возможность реализации - определяется следующими факторами:
    • насколько конкурентными и успешными являются продукты,
    • какова вероятность того, что вендор будет продолжать инвестировать в продукт/сервис,
    • насколько успешную ценовую политику проводит вендор,
    • насколько вендор устойчив к изменениям на рынке,
    • насколько клиенты информированы в области предложений вендора,
    • насколько вендоры имеют возможность выполнять маркетинговые обещания,
    • насколько клиенты довольны сервисной поддержкой вендора;
  • полнота видения - это умение вендора эксплуатировать тенденции на рынке для создания дополнительных сервисов для клиентов и соответствующих выгод для себя. Полнота видения может быть оценена исходя из качества:
    • прогнозов потребностей покупателей,
    • маркетинговой стратегии,
    • стратегии продаж,
    • стратегии развития на вертикальных сегментах рынка,
    • стратегии выхода на удаленные рынки;
  • лидеры - это вендоры, обеспечивающие широкую функциональность своих продуктов, их успешное внедрение и предоставляющие качественную поддержку на глобальном уровне;
  • претенденты - обладают ограничениями, которые могут быть связаны не только с широтой спектра технологических решений, но и с рыночными показателями, такими как качество сбытовой сети и т.п.;
  • провидцы - это вендоры, обладающие мощной стратегией продвижения BI-платформ, что проявляется в открытости стандартов, гибкости архитектуры решений и глубине функциональности создаваемых приложений. Это лидеры в области инновационной деятельности;
  • нишевые игроки - занимают лидирующие позиции в некоторой ограниченной продуктовой или технологической области.

Тенденции на рынке BI-платформ

Как видно из рис. 1, мегавендоры начинают доминировать на BI-рынке. Действительно, менее чем за год Microsoft, Oracle, SAP и IBM прошли путь от владения четвертью рынка до владения его двумя третями.

При сравнении квадратов за 2007-й и 2008 годы видно, что Microsoft поднялась и занимает первое место по возможностям реализации. SAP пока не попадает в лидеры, по всей видимости потому, что объединение с Business Objects еще не закончено. Oracle переместилась на второе место после SAS по полноте видения.

Таким образом, «магический квадрат» BI-платформ за 2008 год отражает тот факт, что лидерство переходит от независимых BI-вендоров, таких как Business Objects и Cognos, к мегавендорам.

В июле 2007 года Oracle завершила сделку по приобретению Hyperion. Это привело к тому, что две конкурирующие платформы - Hyperion System 9 и Oracle Business Intelligence Enterprise Edition - объединились под руководством Oracle и соответственно расширили BI-ресурсы Oracle как в технологическом плане, так и в отношении людских ресурсов.

В октябре 2007 года SAP объявила о присоединении Business Objects с целью расширения своего присутствия на рынке. Данное присоединение (оно было закончено в январе 2008 года) закрывает существенный пробел SAP в части генераторов запросов и отчетов.

Cognos закончила присоединение Applix, обладающего мощной OLAP-технологией, и, в свою очередь, согласилась на свое поглощение корпорацией IBM.

За тот же период такие факторы, как взросление BI-портфеля Microsoft, развитие технологий Web 2.0, развитие продуктов BI с открытым кодом, развитие предложений ПО как услуги (SaaS), привели к тому, что BI-функциональность стала более доступной, чем ранее.

OpenSource BI-решения существенно продвинулись в своем развитии, однако оборот от их внедрения пока незначителен. Один из крупнейших вендоров в этой области JasperSoft утверждает, что у него имеется более 7 тыс. коммерческих клиентов и более 70 тыс. активных внедрений.

Наблюдается также растущий интерес к предоставлению BI-решений в форме SaaS. В частности, компания Business Objects является лидером в бизнесе по предоставлению BI-приложений по запросу (OnDemand), но существуют и более мелкие фирмы, такие как Seatab, Oco и LucidEra, предоставляющие BI-решения как услугу. Использование BI-решений в виде OnDemand-сервиса подходит не всем организациям, оно малоприменимо для организаций, которые работают с секретными данными. Тем не менее с каждым годом все больше компаний выбирают SaaS-модель как более экономичную и достаточно надежную.

Анализ положения ведущих вендоров

Business Objects

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

Около 90% организаций, внедривших данное решение, отмечают, что оно является стандартным для их организации.

Business Objects расширила спектр BI-предложений в 2007 году после присоединения фирмы Inxight.

Быстрый рост BI-предложений Business Objects по запросу (OnDemand), количество пользователей которых составляет уже более 70 тыс., делает ее де-факто лидером в сфере SaaS-BI.

Business Objects должна будет скорректировать свою стратегию после приобретения нового статуса в результате перехода в собственность компании SAP, то есть должна будет потратить некоторое время на изменение каналов продаж, систему поддержки и т.п.

По отзывам клиентов, OLAP является слабой стороной в решениях Business Objects.

Cognos

Cognos имеет исключительно высокий процент внедрений своей BI-платформы в качестве стандартного для предприятий решения. Более 90% опрошенных считают Cognos стандартом для своей организации.

Cognos активно инвестирует в работы по улучшению архитектуры платформы. С появлением версии 8.2 и будущей версии 8.3 Cognos 8 BI практически избавилась от проблем с недостаточной стабильностью работы и слабой технической поддержкой. В настоящее время большинство клиентов эксплуатирует последнюю версию Cognos BI.

После завершения присоединения Cognos к компании IBM платформа Cognos BI выиграет из-за возможности интеграции с технологиями IBM.

Еще одно преимущество Cognos получит по мере освоения технологии Applix TM1 OLAP.

Дейтамайнинговые технологии Cognos по-прежнему слабее, чем предложения ее конкурентов.

Microsoft

Удачная ценовая политика и интеграция с MS Office делает решения Microsoft особенно привлекательными для организаций, которые базируются на инфраструктурных решениях этой компании.

При продвижении своих BI-решений Microsoft может опереться на большую аудиторию разработчиков. По оценкам Microsoft, это 2 тыс. OEM/ISV-партнеров по внедрению ее BI-решений.

По отзывам клиентов, BI-решения от Microsoft вызывают минимальные нарекания.

BI-решения Microsoft были созданы именно ею, а не приобретены вместе с присоединенной фирмой.

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

MicroStrategy

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

MicroStrategy имеет положительные отзывы клиентов по всем 12 критериям, которые оценивает Gartner.

Развитие новых технологий может привести к ослаблению позиций MicroStrategy, которые она пока занимает в области обработки сверхбольших объемов данных.

MicroStrategy имеет репутацию компании, предлагающей дорогие решения, на которые трудно получить скидку.

MicroStrategy фокусируется исключительно на BI-платформах и уделяет недостаточно внимания смежным технологиям - CPM (Corporate Performance Management - управление производительностью корпораций) и интеграции данных.

MicroStrategy имеет малый объем продаж в Азиатско-Тихоокеанском регионе.

Oracle

Еще до присоединения Hyperion, в середине 2007 года, позиции Oracle на рынке BI были достаточно сильными: ее комбинация BI-платформы и аналитических приложений (Oracle BI Enterprise Edition (OBIEE) и Oracle Analytic Applications) представляла собой весьма успешное предложение.

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

Сильные стороны Essbase OLAP-движка и возможности интеграции Hyperion с Microsoft Office повышают потенциал Oracle на рынке BI.

Компания Oracle имеет хорошие шансы продвигать свои BI-технологии различным клиентам, а не только приверженцам платформы Oracle.

Процесс интеграции BI-решений, полученных в результате слияния, займет немало времени в 2008 году.

Есть сведения, что среди инсталяций базы Hyperion BI процент последней версии невелик, что указывает на тот факт, что клиенты не спешат переходить на последнюю версию продукта.

Oracle следует улучшить техническую поддержку.

SAP

Имея более 13 тыс. внедрений, компания SAP добилась больших успехов в продвижении решения NetWeaver BI. Более 75% клиентов SAP из опрошенных Gartner свидетельствовали, что BI-решения от SAP являются стандартными в их организациях.

После завершения интеграции SAP и Business Objects фирма SAP станет крупнейшим вендором BI-платформ, который будет вдвое больше любого другого своего конкурента.

Сильные стороны Business Objects, в первую очередь генерирование форматированных отчетов и генерирование отчетов в режиме самообслуживания (self-service report creation), удачно восполняют пробелы, имеющиеся в решениях SAP BI.

В ходе исследования Gartner клиенты SAP, использующие последнюю версию SAP BI, отметили трудности, касающиеся ее внедрения.

Присоединение Business Objects несколько снижает показатель SAP, который Gartner условно называет возможностью реализации. Это связано с неизбежной неопределенностью для клиентов, которые рассчитывали на уже существующие внутренние продукты SAP в области BI.

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

SAS

SAS лидирует в области продвинутой аналитики (Advanced Analytic Solutions).

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

SAS - это известный бренд, решения SAS имеют сервисную поддержку по всему миру.

Приложения SAS считаются трудными в освоении. Многие приложения продвинутой аналитики требуют применения специального языка программирования SAS - это является достоинством для программистов и существенным ограничением для людей, не обладающих подобными навыками.

В заключение перечислим основные тенденции на рынке BI-платформ:

  • актуальность задачи оптимизации производительности компаний на всех уровнях стимулирует спрос на BI-решения;
  • возможности BI-платформ расширяются, и, помимо традиционных генераторов отчетов и запросов, а также OLAP-функциональности, активное развитие получили «приборные панели» (dashboards), карты показателей (scorecards) и продвинутая визуализация;
  • мегавендоры начинают доминировать на BI-рынке;
  • BI-решения в форме SaaS активно продвигаются многими производителями;
  • процесс слияний и стандартизации является двигателем рынка.

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

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

BI-системы – это единый, предельно прозрачный и полный источник всех данных о бизнесе компании для её административного ресурса, но главным образом для руководства.

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

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

  1. BI-инструменты . Данные инструменты делят на генераторы запросов и отчётов, BI-инструменты аналитической обработки, корпоративные BI-платформы и BI-наборы. Основная часть BI-инструментов состоит из корпоративных BI-наборов и BI-платформ. Средства, предусмотренные для генерации запросов и отчётов, в основном поглощаются, или же корпоративные BI-наборы заменяют их. OLAP-механизмы – оперативная аналитическая обработка данных или серверы, в том числе реляционные. OLAP-механизмы являются инфраструктурой для BI-платформ и BI-инструментов. Большинство инструментов применимы пользователями для доступа, а так же анализа, включая генерацию отчётов, которые в большинстве случаев располагаются в хранилищах, витрине данных или же оперативном складе для данных.
  2. BI-приложения . Приложения, которые не рассматриваются как инструменты. Примером является EIS – информационная система для руководителя.

Характерные особенности BI-систем

  • В системах используют портальные технологии, которые обеспечивают единую точку входа в Интернет и информационное пространство предприятий.
  • Интерфейс представлен в виде пульта управления или приборной доски с отображением нескольких основных показателей. Это даёт возможность быстро оценить положение дел. Также предоставлена возможность быстро обращаться к ключевым показателям по отделам и подразделениям, они хранятся в отдельной папке, расположенной на приборной доске.
  • Многослойность: все данные отображаются в виде нескольких слоёв, при этом каждый последующий слой представляет все более детальную информацию относительно показателей, событий или процессов.
  • Интерактивность BI-систем, позволяющая пользователю быстро осуществлять навигацию, в том числе просматривать данные в различных разрезах и сечениях, а также проводить «бурение» данных, перемещаться по разного рода измерениям. Пользователи могут непосредственно выполнять операции над данными.
  • Управляемость и актуальность. Проактивность, содержащая машину построения правил, дающая возможность пользователям определять цели и пороговые ограничения для разного рода показателей и определять, при каких значениях данных должно выдаваться предупреждение. В системе предусмотрена возможность задавать параметры или показатели: если таковые достигнут критических значений, на монитор выдаются тревожные сигналы — визуальные и/или звуковые.
  • Кастомизация BI-систем — индивидуальная настройка пульта или приборной доски под уровень управления и роль пользователя. Персонализация даёт возможность пользователю самостоятельно выбирать объекты из авторизованных списков и располагать данные на приборной доске по мере их важности.
  • Гибкий доступ позволяет пользователям интуитивно обращаться к нужным данным и отчётам из огромного набора отчётов с результатами и графиков, в том числе предоставляет удалённый доступ и мобильные приложения.
  • Коллаборативность предусматривает одновременную совместную работу большой группы сотрудников, в том числе просмотр отчётов.

Магические квадранты

Грамотно оценить состояние современного рынка, а также дать исчерпывающее объективное описание основных его игроков – задача довольно нетривиальная. На рынке присутствует множество производителей, которые отличаются друг от друга размерами бизнеса, организационными структурами, стилем управления, стратегией и другими факторами.

Такое положение дел значительно усложняет процесс их сравнения, а также направление движения и развития рынка крайне неоднозначны и труднопредсказуемы. Для решения данной проблемы был разработан «магический квадрант» BI-систем, в котором используют 2 показателя, один из них – полнота видения. Другой – способность реализации.

Понравилась статья? Поделитесь с друзьями!
Была ли эта статья полезной?
Да
Нет
Спасибо, за Ваш отзыв!
Что-то пошло не так и Ваш голос не был учтен.
Спасибо. Ваше сообщение отправлено
Нашли в тексте ошибку?
Выделите её, нажмите Ctrl + Enter и мы всё исправим!