Майкл Л. Гонсалес
Президент консалтинговой компании The Focus Group, специализирующейся на хранилищах данных. Написал несколько книг, среди которых "IBM Data Warehousing" (Wiley, 2003).

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

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

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

Цель BI-инициатив состоит в превращении неуправляемой и постоянно изменяющейся лавины корпоративных данных в предсказуемый поток информации для принятия решений в подразделениях.

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

Смещение центра тяжести в сторону хранилищ данных

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

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

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

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

Чего не хватает

Приложения хранилищ данных являются важным источником стратегических данных, необходимых для прогнозирования и анализа тенденций. BI также предусматривает стратегический анализ, но это никак не означает, что эта методика ограничивается только таким типом приложений - к BI-сфере также относятся решения для "моментального" анализа, мониторинга бизнес-активности (Business Activity Monitoring, BAM), создания бизнес-правил, ключевых показателей деятельности предприятия (Key Performance Indicators, KPI) и даже некоторой низкоуровневой, тактической отчетности.

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

Уровни бизнес-интеллекта

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

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

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

Сегодня многие пользователи занимаются аналитикой, используя и комбинируя информацию нескольких заданных объектов лишь одного-двух выделенных уровней. Например, сотруднику, занимающемуся составлением бюджета и прогнозов, подчас достаточно лишь OLAP-инструмента, выполняющего анализ по методу "что, если" (прикладной уровень), и куба с анализируемыми данными (уровень данных). И все. Результаты работы этого сотрудника могут быть неоценимы для предприятия, но факт остается фактом: создание бюджета и прогноза основывается на довольно простом требовании к BI - необходимости наличия двух объектов, один из которых находится на уровне данных, а второй - на прикладном уровне.

Однако очевидно, что не все требования так просты. Например, вице-президенту по маркетингу приходится контролировать рекламные Интернет-кампании. Для этого приходится собирать статистику посещения страниц корпоративного Web-сайта, отделять пользователей, которые "пришли" по щелчку баннера и в конечном счете что-то купили на сайте. Далее можно сопоставить данные об этих посетителях с приобретенными у сторонних поставщиков демографическими данными, чтобы получить совокупную картину уровня доходов и предпочтений покупателей. Наконец, можно связать хронологию продаж с полученной информацией об Интернет-покупателях, привлеченных баннерной рекламой. Цель всего вышесказанного - проиллюстрировать сложность качественного BI-анализа. При сборе и анализе статистики посещений страниц может потребоваться пересекать границы приложений, узлов и географических точек, а также разных уровней данных и технической архитектуры. И это на предварительном этапе - что уж говорить о данных сторонних поставщиков, хронологии продаж и data mining!

Таблица. Уровни BI

Уровень BI Описание Примеры объектов
Техническая архитектура Определяет аппаратные компоненты общекорпоративной системы, к которым относятся устройства обеспечения сетевой связи, компьютерное оборудование и дисковые хранилища Сервер
Коммутатор
Маршрутизатор
Ленточный дисковод
Сетевой адаптер
Рабочая станция
Архитектура данных Этот уровень определяет постоянные структуры данных в компании, в том числе структуры оперативных данных, хранилищ данных и специализированных баз данных сторонних поставщиков БД отдела продаж (Siebel)
БД отдела управления персоналом (PeopleSoft)
БД информации о звонках в call-центр
OLAP-куб отдела продаж, организованный по схеме "звезда"
Прикладной Современные компании переполнены самыми разнообразными приложениями - текущими и унаследованными. Все они создают "сырые" данные IBM DB2
Oracle Financials
BEA WebLogic
Lotus Domino
Заказные приложения
Узлы Корпоративные сообщества пользователей и аналитиков представляют важную часть узлов в BI-среде. Необходимые им формы отчетности и анализа сильно разнятся, как и сами сообщества. Узлы также включают точки взаимодействия с клиентами Банкоматы
Кассовые аппараты
Баннерная реклама
Сервисный центр
Служба технической поддержки
Порталы
Географический Важная часть BI-сети. Здесь отображается географическое распределение систем и приложений предприятия. В крупных компаниях понимание этого уровня жизненно важно для разработки BI-решений Отделы продаж
Адреса клиентов
Центральный офис
Производственные мощности
ИТ-отделы

Устранение нестыковок

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

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

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

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

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