Использование технологии прямой настройки средств BI на базы данных (Direct BI) может избавить вас от проблем, неизбежно возникающих при эксплуатации Хранилища данных. Однако, не обдумав как следует то, как вы собираетесь применять инструменты Direct BI, вы рискуете нажить себе не меньшую "головную боль".
Жить становится все труднее, а специалистам IT-отделов приходится и того хуже. Несмотря на урезанный бюджет, успешное функционирование компании: увеличение доходности от продаж и обслуживания клиентов, сокращение издержек хранения запасов, управление расходами - напрямую и более чем когда-либо зависит от средств анализа информации.
Затраты на полное внедрение Хранилища данных могут смутить кого угодно - вот почему некоторые небольшие и средние компании (и даже некоторые крупные) предпочли аналитические средства Direct BI, позволяющие напрямую обращать к OLTP (On-Line Transaction Processing, оперативная обработка транзакций) или ERP-системам (Enterprise Resource Planning, планирование ресурсов предприятия).
Развертывание Direct BI может помочь компании реализовывать технологию BI, не прибегая к построению Хранилища данных, однако следует помнить о том, что отсутствие необходимой подготовки чревато большими неприятностями: разочарованными клиентами, невыполненными информационными задачами и медленной OLTP-системой. В этой статье я расскажу, как избежать этих проблем.
Если спросить у специалиста IT-отдела или опытного пользователя, работающего с инструментами Direct BI, чтобы он предпочел: установить Хранилище данных или же продолжить использовать указанные средства, вы, скорее всего, услышите следующий ответ: "Хранилище". И все же в текущие планы ни одного из них не входит развертывание Хранилища данных. И вот почему:
Более того, по мере того как сложность отчетов растет, суммарные расходы на поддержание Direct BI могут скоро превысить стоимость Хранилища данных. Компании должны внимательно проанализировать эту ситуацию и осознать, что, если они не готовы построить полноценное Хранилище данных, создание киоска данных (data mart) для разведения сред репортинга и обработки транзакций, а не внедрение сложных средств Direct BI, может быть лучшим инвестиционным решением.
Когда инструменты BI впервые появились в начале 90-х годов, они предназначались именно для Хранилищ данных, а не нормализованных OLTP-систем. Однако, их функциональность постепенно была расширена - как для более эффективного использования Хранилищ данных предприятия, так и для снятия ограничений, присущих SQL-запросам; эти же функциональные возможности определили появление средств Direct BI (см. таблицу 1).
Самое надежное решение: фиксированные отчеты (fixed reports). Большинство пользователей будет выбирать одного из двух возможных вариантов доступа к информации: либо фиксированные отчеты, снабженные окном ввода параметров, с помощью которых пользователи, хотя и смогут видеть только одни и те же информационные столбцы, будут способны изменить критерии отбора. Во втором случае им будут предложены "нерегламентированные" отчеты, запрашиваемая информация в которых уникальна. Чем жестче будут ограничения, которые накладываются на фиксированные отчеты, используемые в средах Direct BI, тем легче вам будет управлять временем отклика на запрос, и тем меньше будет воздействие на исходную систему. Следующие решения могут улучшить технологию фиксированных отчетов:
Для минимизации числа поисков по всей таблице используйте возможность пакетного выпуска отчетов. В этом случае пользователь подписывается на отчет об отправке товаров. Этот отчет выполнятся один раз на сервере промежуточного уровня, а результаты анализируются на сервере отчетов (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 и четко представлять, как пользователи на самом деле работают с такими инструментами. Использование терминов бизнес пространства 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.