На пути к Просвещению

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

Использование технологии прямой настройки средств BI на базы данных (Direct BI) может избавить вас от проблем, неизбежно возникающих при эксплуатации Хранилища данных. Однако, не обдумав как следует то, как вы собираетесь применять инструменты Direct BI, вы рискуете нажить себе не меньшую "головную боль".

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

Затраты на полное внедрение Хранилища данных могут смутить кого угодно - вот почему некоторые небольшие и средние компании (и даже некоторые крупные) предпочли аналитические средства Direct BI, позволяющие напрямую обращать к OLTP (On-Line Transaction Processing, оперативная обработка транзакций) или ERP-системам (Enterprise Resource Planning, планирование ресурсов предприятия).

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

Зачем нужны средства Direct BI?

Если спросить у специалиста IT-отдела или опытного пользователя, работающего с инструментами Direct BI, чтобы он предпочел: установить Хранилище данных или же продолжить использовать указанные средства, вы, скорее всего, услышите следующий ответ: "Хранилище". И все же в текущие планы ни одного из них не входит развертывание Хранилища данных. И вот почему:

• Вопрос времени. Хранилище данных может относиться к долгосрочным задачам, но большинство компаний испытывает потребность в немедленном получении прибыли и не располагает временем или ресурсами для развития IT-стратегии в рамках всего предприятия. Более того, некоторые компании обращаются к средствам Direct BI, полагая, что они развертывают решение операционного репортинга для новой ERP-системы. А когда они начинают использовать стандартные инструменты BI, которые все чаще и чаще поставляются с ERP-системами, работники компании получают расширенные возможности бизнес-аналитики и репортинга.
• Нехватка поддержки в масштабах всего предприятия. Реализация Хранилища данных требует определенной согласованности в целях и работе подразделений организации, а также одобрения проекта развертывания Хранилища в рамках всей компании. Внедрение же средств Direct BI, как правило, ограничено масштабом одного отдела, и поэтому может быть выполнено только его силами. Таким образом, планы относительно Хранилища данных могут быть отложенны. Главная опасность в подобной ситуации заключается в том, что используемое средство превратится в "собственность только одной епархии", и на волне всеобщего недовольства руководство компания непроизвольно примет решение построить Хранилище данных. Кто бы ни финансировал внедрение инструментов Direct BI, должен уметь контролировать требования: Direct BI - это точечное решение, а не стратегия в рамках всего предприятия.
• Стоимость и сложность. Стоимость реализации Хранилища данных колеблется в пределе от 50.000 до нескольких миллионов долларов. Если проект по внедрению составлен неудачно, уйдут годы, прежде чем Хранилище начнет приносить прибыль. В лучшем случае придется ждать месяцы, пока Хранилище данных начнет "себя оправдывать". Небольшие и средние компании не могут позволить себе такую роскошь, ожидая, что инвестиции в Хранилище начнут окупаться. У них нет ни ресурсов, ни достаточного опыта, чтобы взяться за такой проект. С другой стороны, нужно всего несколько недель, чтобы средства Direct BI начали "работать" на компанию. Однако, в этом случае возврат инвестиций (ROI) может достигнуть только ограниченной величины или будет даже отрицательным, если процесс развертывания Direct BI не был тщательно продуман. (Неужели запросы-"убийцы" могут помешать обработке заказов? Еще как могут.)

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

Функциональные особенности средств Direct BI

Когда инструменты BI впервые появились в начале 90-х годов, они предназначались именно для Хранилищ данных, а не нормализованных OLTP-систем. Однако, их функциональность постепенно была расширена - как для более эффективного использования Хранилищ данных предприятия, так и для снятия ограничений, присущих SQL-запросам; эти же функциональные возможности определили появление средств Direct BI (см. таблицу 1).

Самое надежное решение: фиксированные отчеты (fixed reports). Большинство пользователей будет выбирать одного из двух возможных вариантов доступа к информации: либо фиксированные отчеты, снабженные окном ввода параметров, с помощью которых пользователи, хотя и смогут видеть только одни и те же информационные столбцы, будут способны изменить критерии отбора. Во втором случае им будут предложены "нерегламентированные" отчеты, запрашиваемая информация в которых уникальна. Чем жестче будут ограничения, которые накладываются на фиксированные отчеты, используемые в средах Direct BI, тем легче вам будет управлять временем отклика на запрос, и тем меньше будет воздействие на исходную систему. Следующие решения могут улучшить технологию фиксированных отчетов:

• Параметризованные отчеты (customizable prompt) (см. пункт 1 - 3 в таблицы 1). Все ведущие поставщики обеспечивают эту мощную функциональность, включенную в фиксированные отчеты в видеокна ввода параметров, например, к вводу ID продукта. Список для выбора допустимых ID продуктов может сопровождаться их описанием, а также допускает сортировку различными способами. Кроме того, особый интерес представляет многоуровневые окна ввода параметров, например, для региона необходимо сначала выбрать страну, и, если выбранная страна - США, показываются города и штаты США.
• Отчеты, выпускаемые по расписанию (report scheduling) (см. пункт 4, 5 таблицы 1). Как бы вы не "ужимали" фиксированные отчеты, некоторые запросы все равно будут обрабатываться медленно и потребуют много ресурсов. Такие отчеты лучше всего выполнять в те часы, когда загрузка системы минимальна, и результат обработки кэшировать на сервере промежуточного уровня (midtier server). За исключением Windows-клиента Cognos Impromptu и Crystal Decisions все поставщики, приведенные в таблице 1, поддерживают эту функциональность. Готовые отчеты могут отсылаться на email или в корпоративную локальную сеть, кроме того, наблюдается растущий спрос на устройства мобильной поддержки, такие как персональные цифровые секретари (PDA) и мобильные телефоны.
• Пакетный выпуск отчетов (report bursting) (см. пункт 6 таблицы 1). Поскольку исходная система оптимизирована на операции ввода (а не репортинг), возможна ситуация, при которой в результате пользовательских запросов будет выполняться поиск по всей таблице и полный обход по индексам. Например, в вашей компании трудятся два менеджера по поставкам, ответственные за различные регионы. Одному менеджеру необходимо посмотреть отправку товаров на Восточном побережье, а другому - на Западном. Штат назначения не является индексируемым полем. Если оба менеджера начнут выполнять отчет, поставив фильтр на область назначения, сканирование по всей таблице просто "нокаутируют" исходную систему - они будут часами жать результатов поиска.

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

Нерегламентированные запросы: рискованное дело

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

Если вы все-таки решились допустить нерегламентированный репортинг, убедите пользователей использовать для фильтрации проиндексированные поля (см. пункт 7 таблицы 1) - так вы сможете минимизировать воздействие на исходную систему и улучшить время ответа на запрос. Из продуктов, приведенных в таблице 1, только Web-инструменты Brio Software, Business Objects и Cognos Impromptu позволяют определять, какие поля могут быть фильтрами в запросах. Кроме того, в качестве альтернативы, некоторые компания для информирования пользователя о том, какие поля являются индексными, предлагают использовать соглашения по присваиванию имен или прибегать к именам в верхнем регистре.

Возможность агрегирования (aggregate awareness) (см. пункт 8 таблицы 1) также может ограничить влияние на исходную систему. Предположим, что сумма в долларах содержится в заголовочной таблице заказа (order header table). Ваша система нормализована таким образом, что в ней хранится еще и детальная таблица заказа (order detail table), в которой присутствуют отдельные элементы строк, ID продуктов и суммы. Если пользователю необходимо иметь только информацию о клиенте и соответствующую сумму в долларах, для выполнения его запроса достаточно заголовочной таблицы заказа - а запрос к небольшой таблице будет исполняться быстрее.

Поскольку ведущие поставщики баз данных реализовали технологию агрегирования в RDBMS (реляционных системах управления базами данных), значение этой функциональности в составе средств BI уменьшилось. Однако не все RDBMS обладают подобной возможностью, кроме того, ваша исходная система может быть не настроена на обращение к этой функции, потому что при проектировании в нее не были заложены возможности репортинга. Business Objects - единственная компания, чей инструмент способен к агрегированию, так что пользователю нужно только указать в запросе "amount" ("сумма"), а Business Objects сам разберется к какой сумме: в заголовочной или детальной таблице, обращаться. Кроме того, продолжительное и непредсказуемое время выполнения нерегламентированного репортинга может вызвать недовольство пользователя. Чтобы избежать этого, следует прибегнуть к потоковому представлению отчетов (report streaming) (см. пункт 9 таблицы 1) и оценке времени на выполнение запросов (time estimate) (см. пункт 10 таблицы 1).

При потоковом представлении отчетов после выполнения запроса пользователю предоставляется часть информации, в то время как оставшаяся может передаваться по сети. Таким образом, пользовать получает возможность быстрее познакомиться с результатами запроса. Этот подход также рационально использовать как в случае фиксированных отчетов, которые не были заявлены на выполнение по расписанию, так и нерегламентированных запросов. Эта функциональность реализована в продуктах Crystal Decisions, Impromptu и Arcplan.

Если вы хотите обратиться к системе с нерегламентированным запросом, полезно знать, сколько времени: минут или часов, потребуется на его обработку. И хотя это - задача базы данных, тем не менее, средство BI также должно позволять пользователю получить такую информацию, прежде чем он отправил запрос на выполнение. Business Objects - единственный инструмент, который имеет такую функцию, что же касается других продуктов, приведенных в таблице 1, то работая с ними, администратор может ограничить число возвращаемых строк или оценить их количество. Однако ограничение количества строк препятствует чрезмерной загрузке лишь клиентской машины (или сервера промежуточного уровня), но не OLTP-системы.

Анализ

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

Слабо масштабируемый OLAP (см. пункт 11, 12 таблицы 1). Главное достоинство средств OLAP заключается в том, что они позволяют пользователям анализировать информацию под различным ракурсом, например, продажи по продуктам, регионам и времени. Если менеджер видит, что продажи в каком-то регионе в этом месяце ниже, чем в предыдущем, он может углубиться в данные, чтобы понять причину.

Brio и Business Objects для поддержки OLAP используют технологию микрокубов. Когда результаты запроса отправляются на сервер промежуточного уровня (в случае Web-реализации Business Objects) или на настольный компьютер (в случае Windows-реализации Brio), приложение динамически создает микрокуб. А инструмент Arcplan кэширует результаты запроса сервере приложения. Эти микрокубы/кэши не такие большие, мощные или сложные как тяжелые кубы, создаваемые Hyperion Essbase, Microsoft Analysis Services или Cognos Powerplay; на самом деле, все предоставляют доступ к ведущим источникам OLAP-данных. Тем не менее, это технология микрокубов обеспечивает возможность несложного углубления в данные или обладает большей гибкостью, так как микрокубы не нужно создавать заранее точно в соответствии с требованиями к информации.

Поскольку Cognos стремится к тому, чтобы пользователи выбирали Powerplay, функция полного многомерного анализа реализована именно в этом продукте; компания не предоставляет возможность углубления в данные в Impromptu. Однако, Impromptu располагает функцией - связанные отчеты (linked reports), которая позволяет имитировать углубления в данные. В этом случае автор отчета определяет ссылку в итоговом отчете, а затем создает отдельный запрос для того, чтобы показать детали, если пользователь дважды нажмет на эту ссылку. Этот подход требует немного больше администрирования и изначально подразумевает больше времени для ответа на запрос, чем технология микрокубов, но это разумная альтернатива.

Сложные встроенные функции (см. пункт 13 -15 таблицы 1). Если вы работаете с исходной системой, то вы не сможете воспользоваться преимуществами схемы типа "звезда", присущей Хранилищу данных, упростив вычисления за текущий и прошлый года. Вам также не дано прибегнуть к помощи мощного OLAP-инструмента и выполнить многомерные вычисления, такие как определение валовой прибыли и доли на рынке. Таким образом, средства BI должны компенсировать ограничения SQL и отсутствие оптимизированной модели данных. Инструменты ведущих поставщиков, а также все те, что приведены в таблице 1, поддерживают такие важные функции, как перекрестные табличные данные (cross-tabs), top-N репортинг (top-N reporting), текущие суммы (running totals), доля рынка (market share). (Последняя версия Crystal Decisions также включает функции, позволяющие вычислять ключевые показатели производительности, такие как оборачиваемость запасов и движение наличности против текущей задолженности.) Но необходимо иметь в виду, что большая часть вычислений производится на клиентской машине или сервере промежуточного уровня. Таким образом, через сеть может пересылаться больше данных, чем в случае использования киоска или Хранилища данных.

Данные из различных источников (см. пункт 16 таблицы 1). Без киоска или Хранилища данных вы также не сможете позволить себе роскошь располагать постоянными справочными данными или иерархическими представлениями, такими как группировка по клиентам и продуктам. Однако с помощью Direct BI вы смогли бы определить иерархические структуры в Access, Excel и отдельной базе данных. Затем инструменты BI разрешают присоединить эти иерархии на клиента так, чтобы они появлялись в отчете как один источник.

Brio и Business Objects реализовали эту задачу в микрокубах, а Impromptu использует "горячие" ("hot") файлы. Однако согласование данных по разным источникам может быть утомительным делом и требует сложных SQL-запросов. Если эту процедуру необходимо повторять для различных приложений, в конечном счете, экономически более оправданно поддерживать ее через киоск или Хранилище данных.

Управление средствами Direct BI

Для того чтобы ограничить воздействие на исходную систему, необходимо тщательно управлять средствами Direct BI и четко представлять, как пользователи на самом деле работают с такими инструментами. Использование терминов бизнес пространства ERP-системы (см. пункт 17 таблицы 1) и мониторинг обращения к системе (см. пункт 18 таблицы 1) позволят значительно повысить эффективность эксплуатации Direct BI.

В первом случае, пользователю не нужно знать, как строятся отношения между объектами в исходной системе. Наоборот, пользователь должен оперировать терминами бизнес пространства, например, вместо непонятного для него имени поля "L33_No" следует предложить бизнес-понятие "ID клиента". Точно также необходимо оградить клиентов от необходимости определять соединения; бизнес пространства исходной системы должны скрывать сложную модель отношения объектов от глаз пользователя. (Brio и Crystal Decisions называют эти пространства словарями (dictionaries), Business Objects - универсальными множествами (universes), а Cognos - каталогами (catalogs).)

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

Business Objects и Impromptu используют бизнес пространства, поставляя для популярных ERP-систем встроенные множества/каталоги: RDT (Rapid Deployment Template, Шаблон быстрого развертывания) и Headstart ("Гандикап"), соответственно. (Они предоставляются бесплатно). Они не ожидайте слишком много от них: RDT и Headstart могут не включать всю необходимую информацию, или же могут быть некорректно отформатированы по отношению к вашей исходной системы.

Например, для того чтобы учесть нюансы реализации вашей OLTP-системы может потребоваться модифицировать RDT и Headstart. Такой сложный SQL-запрос и трансформация замедлят любой запрос и увеличат административные расходы. Когда вы не осознаете, как много времени вы затрачиваете на кодирование сложных SQL-запросов при обращении к бизнес пространству (множеству, каталогу или словарю), вы невольно задумаетесь о необходимости построения киоска или Хранилища данных, для которых такое кодирование выполняется только один раз.

Для Direct BI возможность ревизии (см. пункт 18 таблицы 1) является ключевой: вы можете определить, какие именно отчеты выполняются и когда. Это не только ослабит снижение производительности системы доступа, но и предоставит важную информацию о том, какие предметные области в Хранилище данных использовались бы больше других. Возможности мониторинга полностью отсутствовали в ранних версиях BI. За исключением, Crystal Decisions и Arcplan, которые напрямую не поддерживают эту функциональность, утверждая, что ее можно запрограммировать, большинство инструментов Direct BI в той или иной степени позволяют контролировать обращение к системе.

Соотношение риска и преимущества

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

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

Автор: Синди Хаусон (Cindi Howson)