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

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

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

BI напрямую— зачем?

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

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

Недостаток поддержки. Для успеха проекта создания информационного хранилища требуется покровительство руководства и поддержка со стороны различных подразделений. В то же время прямая бизнес-аналитика — это обычно решение, предназначенное для ограниченного круга пользователей; чтобы успешно его реализовать, не нужны согласования с другими отделами компании, — вполне достаточно поддержки одного подразделения. Это позволяет обойтись без внутрикорпоративных «политических» коллизий. В описанном варианте есть огромный риск: успех BI-решения может привести к тому, что потребности пользователей в подобных возможностях начнут расти лавинообразно и в результате компания начнет создавать информационное хранилище в авральном порядке. Если вы реализуете BI напрямую, не обещайте слишком многого: ваше решение будет точечным, на нем нельзя строить стратегию целого предприятия.

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

Что облегчает прямую реализацию BI

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

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

Настраиваемые диалоги (в таблице строки 1—3). Все ведущие BI-инструменты предлагают развитые диалоги, в которых пользователи могут генерировать заданные отчеты, отвечая на вопросы, например, об идентификаторе товара. В выводимом на экран списке отображаются имеющиеся товары с информативными описаниями, отсортированные заданным способом. Желательно, чтобы BI-инструментарий поддерживал многоуровневые диалоги, в которых, к примеру, после выбора страны (пусть это будет США) можно было бы выбрать город или штат из контекстного списка.

Планирование отчетов (строки 4 и 5). Есть отчеты, не поддающиеся оптимизации, — запросы выполняются медленно и потребляют много ресурсов. Подобные запросы лучше выполнять в непиковые часы, а результаты размещать в кэше на сервере промежуточного слоя. Все перечисленные в таблице инструментальные средства, за исключением Windows-клиентов Cognos Impromptu и Crystal Decisions, поддерживают планирование с помощью расписаний. Готовые сообщения можно пересылать по электронной почте или размещать в корпоративной интрасети, кроме того, все чаще встречается поддержка таких портативных устройств, как мобильные телефоны и персональные цифровые помощники (PDA).

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

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

Специальные запросы: рискованное занятие

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

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

Распознавание агрегированных показателей (строка 8) также позволяет снизить нагрузку на базовую систему. Допустим, в заголовочной таблице заказов хранится суммарное значение в денежном выражении, кроме того, базовая система нормализована и хранит таблицу детализованных данных по заказам, включая идентификаторы и количество изделий. Если пользователю нужно лишь знать имена заказчиков и объемы продаж в денежном выражении, его запросу удовлетворят данные заголовочной таблицы — при этом запрос существенно упрощается, а значит, его выполнение ускоряется.

В ведущие реляционные СУБД уже встроена поддержка агрегированных показателей, поэтому эту задачу часто удается решить, не используя BI-средство. Однако не все СУБД поддерживают эту функцию, и в вашей базовой системе описанной возможности может не оказаться, ведь она изначально и не предназначалась для генерации отчетов. Business Objects — единственное средство, «понимающее» агрегированные показатели. Пользователю достаточно указать в запросе термин «объем», а Business Objects самостоятельно разберется, откуда брать данные — из заголовочной или детальной таблицы. Еще одно неудобство специальных отчетов — медлительность генерации и непредсказуемое время отклика. Есть две возможности облегчить положение пользователей — это потоковая пересылка отчетов (строка 9) и оценка времени выполнения запроса (строка 10).

Потоковая пересылка означает, что сразу после выполнения запроса BI-средство предоставляет пользователю первую страницу данных — остальные данные в это время пересылаются по сети. В описанной ситуации пользователь видит результаты запроса быстрее. Эта функция полезна как для специальных, так и для предустановленных, но не запланированных в расписании запросов. Crystal Decisions, Impromptu и Arcplan поддерживают потоковую пересылку отчетов.

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

Поддержка анализа

Справившись со сложностями доступа к данным OLTP-системы, вы должны превратить эти данные в полезную информацию и проанализировать. Отчетность и аналитические функции BI-средств позволяют организации перейти от создания базовых оперативных отчетов к сложному анализу. Наиболее важные функции, которые должны присутствовать в системе, — это интерактивная аналитическая обработка (Online Analytic Processing — OLAP, строки 11 и 12), готовые функции (строки 13—15) и извлечение данных из различных источников (строка 16).

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

Для поддержки OLAP в пакетах Brio и Business Objects используется технология микрокубов. При возврате результатов запроса на сервер промежуточного слоя (в Web-версии Business Objects) или на рабочий стол пользователя (Brio) программа динамически формирует микрокуб. В Arcplan микрокубы не создаются, зато результаты запроса кэшируются на сервере приложений. Эти микрокубы или кэшированные данные не такие крупные, мощные и сложные, как «тяжелые» кубы, создаваемые в Hyperion Essbase, Microsoft Analysis Services или Cognos Powerplay. Все они в конечном счете обеспечивают доступ к OLAP-источникам данных. Однако основанный на микрокубах подход обеспечивает простое перемещение вниз по иерархии детализации данных (drill-down) и большую гибкость, так как для построения кубов в данном случае не обязательно заранее точно определять требования к информации.

По замыслу разработчиков Cognos, клиенты должны выполнять полнофункциональный многомерный анализ с помощью Powerplay, поэтому в Impromptu возможность перемещения вниз по иерархии данных не предусмотрена. Тем не менее в Impromptu есть особая функция, называемая связанные отчеты (linked reports), которая позволяет моделировать операцию drill-down. Автор связанного отчета создает в сводном отчете ссылки на запросы, предоставляющие по щелчку более детальные сведения. Запросы создаются отдельно. Подобный подход требует определенных административных усилий и в принципе работает более медленно, чем микрокубы, но при ограниченных средствах это вполне рентабельное альтернативное решение.

Развитые предустановленные функции. При работе в базовой системе вы не в состоянии воспользоваться имеющимися в информационных хранилищах схемами типа «звезда», которые упрощают сравнительный анализ по годам. Нет там и надежного OLAP-инструмента, позволяющего выполнять многомерные вычисления таких показателей, как валовая прибыль или доля на рынке. Таким образом, BI-средства должны восполнять недостатки SQL и отсутствие оптимизированной модели данных. Эти функции имеются во всех ведущих BI-средствах; пакеты, перечисленные в таблице, обеспечивают выполнение таких важнейших задач, как перекрестные табличные данные, отчеты о первых N рядах отсортированной таблицы, подсчет суммарных показателей и доли на рынке (новейшая версия Crystal Decisions также содержит функции для вычисления ключевых показателей производительности, таких, как оборачиваемость запасов и отношение «оборотные средства/текущая задолженность»). Однако не забывайте, что основная работа выполняется на клиенте или сервере промежуточного слоя. Таким образом, для выполнения этих вычислений данные можно пересылать по сети, не обрабатывая их в базе данных, как это делается в витринах данных или в информационном хранилище.

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

В Brio и Business Objects для этой цели применяются микрокубы, а в Impromptu — «горячие» файлы. Однако сверка данных от различных источников обычно утомительна и требует сложных SQL-запросов. Если эта процедура часто повторяется в различных приложениях, в конечном счете может оказаться, что все-таки более рентабельно развернуть витрину данных или информационное хранилище.

Администрирование прямого BI

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

В первом случае пользователям, создающим специальные отчеты, не нужно знать модель взаимосвязи сущностей в базовой системе — они работают с осмысленными бизнес-терминами (например, «идентификатор клиента»), а не с загадочными именами полей (скажем, L33_No). Кроме того, они не должны определять соединения; бизнес-представление исходной системы скрывает от пользователя сложности модели «сущности/отношения» (в Brio и Crystal Decisions эти представления называются словарями, в Business Objects — областями, а в Cognos — каталогами).

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

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

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

В "прямой" реализации BI очень важен аудит (строка 19), цель которого — определить, какие отчеты создаются и когда с ними работают. Таким образом, вы не только получите представление о нагрузке на систему, но и определите, какие предметные области будут востребованы в информационном хранилище. Возможности аудита полностью отсутствовали в более ранних версиях BI-средств, однако теперь они в различной степени доступны в большинстве подобных приложений. Crystal Decisions и Arcplan напрямую не поддерживают аудит, но разработчики заявляют, что эту возможность можно запрограммировать.

Соотношение риска и выгод

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

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

Синди Хаусон (Cindi Howson) — независимый консультант, специализирующийся в области бизнес-аналитики. Ранее она занималась аналитикой в отделении Deloitte & Touche в Хьюстоне и занимала пост ответственного за стандарты BI в одной компании из списка Fortune 500. С ней можно связаться по e-mail: cindihowson@askcindi.com.