Интеллект для бизнеса

Значительный сдвиг в развитии ВІ-систем произошел в 2003 году. Взаимопоглощения некоторых вендоров, а также новаторские решения, воплощенные в очередных релизах продуктов, придали новый импульс процессу созревания рынка. Business Objects объявила о выпуске шестой версии Enterprise 6, а затем и о покупке компании Cristal. Hyperion приобрела другого игрока на рынке BI — компанию Brio. Cognos выпустила новый генератор отчетов ReportNet (CRN) 1.0. Увидела свет новая версия (7.5) продукта с долгожданным модулем для построения отчетов от еще одного участника рынка — компании MicroStrategy. Ну а появление генератора отчетов Reporting Services от такого гиганта ИТ-индустрии, как Microsoft, и вовсе заставило многих участников ВІ-ралли серьезно задуматься, а тот ли продукт выбран для дальнейших инвестиций.

Но несмотря на все инновации и происходящие изменения, отсутствие стандартов явно мешает конечному пользователю разобраться, в чем состоит отличие тех или иных возможностей, предлагаемых различными поставщиками продуктов, и как определить именно ту функциональность, которая окажется практичной, управляемой, оправданной по своей стоимости и в конечном итоге отразится на успешности предприятия. Исключением являются разве что хранилища данных (ХД). Еще 25 сентября 2000 года организации MDC (Meta Data Coalition) и OMG (Object Management Group, www.omg.org), разрабатывавшие в то время два конкурирующих стандарта в области интеллектуальных технологий для бизнеса — OIM (Open Information Model) и CWM (Common Warehouse Metamodel) соответственно, приняли решение объединить усилия под управлением OMG.

На украинском рынке среди поставщиков ВІ-решений представлена компания Cognos. Компании Robertson&Blums, «БМС-консалтинг» и Zept Group являются равноправными партнерами этого разработчика и совсем недавно начали реализацию его продуктов в Украине. Поэтому полностью завершенных проектов пока нет. Разве что Robertson&Blums предельно близка к окончанию внедрения решения Cognos BI в компании «Альянс-Украина», где оно будет применяться для анализа сбыта нефтепродуктов через сети АЗС. Стоит также упомянуть о компании Sun InterBrew Ukraine, которая использует модуль Cognos PowerPlay для анализа данных. Некоторые разработки в этой области представляет также и Microsoft. Собственную технологию контент-мониторинга InfoStream разработал Информационный центр ElVisti. Она выступает одним из звеньев для решения задачи агрегирования информации, полученной из разнородных источников.

Правильные акценты

Лучшие ВІ-решения формируются годами, разрастаясь со временем в ширину (используется все в большем количестве подразделений) и глубину (приобретает все больше функциональных возможностей). Однако не все BI-проекты оказываются успешными. Одна из самых серьезных и очень распространенных ошибок, совершаемых при выборе ВІ-инструментов, — утрата в процессе сравнения функциональности общей целостной картины бизнеса, а также основных целей и выгод, которые заказчик собирается достичь от их внедрения. Похожая проблема остается и после внедрения системы, когда не всегда есть четкое понимание, для решения каких вопросов добываются данные. Еще до начала внедрения можно выделить основные признаки, которые указывают, будет ли оно успешным и что может ему помешать. Тогда организации удастся преодолеть проблемы, которые связаны с реализацией любого ВІ-проекта. Анализируя накопленный опыт, специалисты выделили несколько ключевых факторов, характеризующих ВI-проект как успешный:

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

ВІ-архитектура

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

Большинство современных ВІ-инструментов имеют так называемую сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA). Она является развитием серверов приложений и корпоративных порталов. Эта новация связана также с технологиями J2EE и .NET. Применимы также такие технологии, как компонентная объектная модель (Component Object Model, СОМ), разработанная корпорацией Microsoft, и общая архитектура брокеров объектных запросов (Common Object Request Broker Architecture, CORBA) от консорциума OMG. BI вэб-сервисы делают инструменты открытыми компонентами с известными интерфейсами, доступными в сетях разных конфигураций. На рисунке 1 изображена одна из реализации SOA с тремя возможными ВІ-сервисами — запросы, презентации, расписание задач. Безусловно, каждый инструмент может включать и другие наборы сервисов.

Как правило, доступ к БД осуществляется через ODBC. Для применения SQL в работе со специфическими БД часто требуется наличие родного драйвера.

Инструменты для генерации запросов и отчетов

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

Работа с несколькими источниками данных

Существует много причин, по которым пользователю может понадобиться доступ сразу к нескольким источникам данных. Как правило, на практике может оказаться, что данные о доходах берутся из ХД, а данные о сегментации — из БД MSAccess. К тому же, помимо традиционных решений по ХД Oracle9i и MS SQL Server2000, растет число применений хранилищ ERP, например, SAP BW для R/3 или PeopleSoft Enterprise Warehouse с ВІ-приложениями управления эффективностью предприятия (Enterprise (Business и Corporate — другие встречающиеся варианты) Performance Management, ЕРМ). Однако в обоих случаях функциональность привязана к конкретным системам ERP, а, следовательно, ограничена. В целом, все заметнее тенденция встраивания ВІ-инструментов как в приложения, ориентированные на конкретную функцию организации или такие задачи, как анализ и прогноз продаж, финансовое бюджетирование, прогнозирование, анализ рисков, анализ тенденций и т.п., так и в приложения ЕРМ или системы сбалансированных показателей (Balanced Scorecard).

Средства доставки

Многие компании создают интранет-сети, размещая там все возможные документы в виде HTML-файлов. Однако современные ВІ-инструменты могут сохранять созданные ими отчеты в родном формате, оставляя более гибкие возможности для оперативного обновления содержимого документов. А благодаря таким технологиям, как вэб и электронная почта, количество пользователей ВІ-инструментами может исчисляться десятками тысяч.

Отдельно стоит упомянуть о ВІ-порталах, с помощью которых пользователь также может получить доступ к стандартным или же индивидуальным отчетам. В наилучших реализациях ВІ-порталов пользователь получает возможность подогнать (Customize) портал к виду инструменатальной панели (Dashboard, по примеру My Yahoo!), где будут отображены различные отчеты, вэб-сайты, списки отчетов и т.д. Заметна тенденция размещения документов, не относящихся к BI (например, PDF-файлов и др.), в его репозитории с последующим доступом через портал.

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

BI и хранилища данных

Хранилище данных — это накопитель исторической информации о жизнедеятельности компании. Концепция, методы и средства ХД (Data Warehousing) определяют подходы и обеспечивают интеграцию, очистку, ретроспективное хранение информации, предназначенной для анализа, отвечают на вопрос: «Как подготовить информацию для анализа?». Разработаны BI-инструменты, которые имеют встроенные функции очистки и согласования и вполне могут работать с данными из разнородных источников, причем осуществлять эти операции придется на лету или же предварительно, но для обособленного информационного ресурса. (ПО, реализующее процесс извлечения данных из различных источников, их преобразования и очистки с целью помещения в различные БД, витрины (Data Marts) и ХД, именуется ETL — Extract, Transform and Load.) Кроме того, существует эффект влияния на производительность и надежность оперативной системы обработки транзакций. Вот почему хорошей корпоративной практикой является выделение транзакционной и аналитической составляющих и применение для второй различных решений по ХД.

Известны две наиболее проверенные на практике технологии создания хранилищ данных: Ральфа Кимбола (Ralph Kimball) — инструментарий жизненного цикла ХД (Data Warehouse Lifecycle Toolkit) и Билла Инмона (Bill Inmon) — корпоративная информационная фабрика (Corporate Information Factory). Однако замечено, что ни один оптимальный метод не действует одинаково для всех компаний и во всех обстоятельствах. Кроме того, подобного рода сложные технологии могут отвлечь от основной цели проекта, заостряя внимание на деталях. Поэтому проекты по созданию хранилищ должны носить индивидуальный характер.

OLAP и аналитические инструменты

В начале 90-х годов Essbase (еще до того как его купил Hyperion) пригласил на работу родоначальника реляционных БД Эдгара Кодда (Edgar Ted Codd), чтобы тот описал новый по тем временам механизм OLAP. Кодд определил 12 основных характеристик. Приведем лишь четыре из них, которые максимально отражают отличительные особенности OLAP от составления отчетов.

Многомерность. OLAP позволяет организовать измерения в виде иерархии. Сами данные организованы определенным образом в логические и физические модели показателей — гиперкубы (кубы) — коллективно использующие измерения, а также иерархии в этих измерениях. Некоторые данные предварительно агрегированы в БД, другие рассчитываются «на лету». Пользователи имеют возможность одновременно анализировать числовые значения по нескольким различным параметрам, например, виду продукции, времени (реализации, поставки и т. д.) и региону (географии). Тогда как в отчете допускается одновременный анализ лишь по одному параметру — например, цене продукта. Пользователи могут выбрать, какие показатели анализировать, какие измерения и как отображать в кросс-таблице, обменять строки и столбцы pivoting, делать срезы и вырезки (slice&dice), чтобы сконцентрироваться на определенной комбинации размерностей.

Изменяющийся уровень агрегированности. В отличие от отчетов, которые представляют данные на низшем уровне детализации, OLAP допускает различные уровни обобщенности. С помощью функции детализации (Drill Down) и укрупнения (Roll Up) можно изменять детальность данных, перемещаясь между уровнями. А используя кросс-детализацию (Drill Across), и между измерениями.

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

Межуровневые вычисления. Работа с многомерными данными предполагает более сложные вычисления, которые, как правило, выполняются в установленном порядке и требуют определенного набора входных данных, которые пользователь, в свою очередь, никогда и не видел. В то время как в детализированных отчетах вычисления базируются на значениях, отображенных в самом отчете (табл. 1).

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

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

При выборе OLAP-инструментов важным критерием является OLAP-архитектура. Традиционно такие инструменты делятся на MOLAP, ROLAP, HOLAP, DOLAP (многомерный, реляционный, гибридный и настольный или динамичный соответственно).

MOLAP использует структуру постоянного куба, отличную от реляционных БД. Поскольку кубы включают наборы данных, которые предварительно агрегированы, они считаются самыми производительными, хотя и существуют методы повышения производительности ROLAP, например, схема «звезда» (Star Schema).

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

Многие поставщики МБД используют комбинацию реляционных и многомерных OLAP — HOLAP. Microsoft Analysis Services и Hyperion Essbase, например, применяют ROLAP для размещения большего объема данных. Однако, как и в случае с чистым ROLAP, скорость анализа замедляется.

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

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

Каждый разработчик традиционно лидирует на том или ином участке ВІ-фронта. Каждый имеет свое представление о разнообразии наборов ВІ-инструментов и их нынешней и будущей функциональности (табл. 2). Какой из них выбирать — зависит исключительно от вас. К тому же существует много факторов, которые сложно или даже невозможно отобразить в таблицах или схемах: при разработке продуктов каждый поставщик следует своей, как правило, уникальной стратегии. Например, такие основные игроки, как Cognos, Business Objects и Hyperion придерживаются модели ЕРМ, но каждая — по-своему и с собственным пониманием места BI в этой модели. Microsoft, в то же время, даже не упоминает о ЕРМ, хотя его амбиции относительно рынка ВІ-приложений вполне однозначны. Чья стратегия окажется более успешной — определит время. К тому же многое будет зависеть не только от стратегических планов компаний, но и от успешности их реализации. Однозначно можно лишь сказать, что ценность ВІ-пакета определяется далеко не долей рынка или фактом упоминания в данном обзоре, а способностью помочь конечному пользователю ставить и реализовывать его бизнес-цели.