Поставщики и независимые разработчики предлагают решения проблемы  недоступных данных

Когда два года назад Дэвид Ричардс приступил к развертыванию приложения корпорации Oracle, предназначенного для планирования ресурсов предприятия (ПРП), он надеялся, что наконец нашел ключ к тайнику с бесценным, но практически недоступным кладом  -  ежеминутно обновляемой детальной информации о деятельности корпорации Rockford Fosgate. Будучи вице-президентом по вопросам ИС этой компании, Ричардс знал, что новые интегрированные приложения Oracle могут собирать подробнейшую информацию обо всех этапах производства, сбыта и распространения, а также о финансовых процессах и сделках в Web, сводя ее в единую базу данных. Все, что ему останется делать, это выбирать данные из нужных таблиц и компоновать из них отчеты, которые дадут менеджерам корпорации бесценные информационные сокровища  -  например, укажут, какие заказчики или продукты обеспечивают наибольший доход. Верно?

В теории  -  да. Но Ричардс скоро осознал, что на практике это далеко не так просто. Сотрудники его отдела смогли написать сценарии, по которым необходимые данные извлекаются из различных модулей приложения Oracle. Но загрузка всего этого добра в отдельную БД, где информация могла анализироваться с помощью запросов, занимала до 36 часов. “При такой производительности мы могли осуществлять полную загрузку новых данных только раз в месяц”,  -  сказал Ричардс. Для информации, поступающей ежеминутно, это не так уж часто.

Ричардс не единственный менеджер ИС, для кого стало сюрпризом, насколько трудно использовать важные данные, собранные пакетами ПРП, такими, как приложения Oracle или SAP R/3. Многие компании внедрили эти программные пакеты в надежде, что они помогут оптимизировать ежедневные операции и накопить массу информации исторического характера, анализ которой позволит найти новые подходы к бизнесу. Однако за немногими исключениями пакеты ПРП не облегчили доступа к бизнес-информации, а скорее наоборот, погребли ее за чересчур сложной структурой представления данных и неадекватными средствами генерации отчетов.

“Поработав некоторое время с приложениями ПРП, накапливающими горы информации о транзакциях, менеджеры поняли, что эти системы являются гробницами данных”,  -  сказал Брюс Ричардсон, вице-президент по исследованиям компании Advanced Manufacturing Research (Бостон).

В результате пользователи все чаще требовали от поставщиков ПРП более эффективных решений. И вот, наконец, поставщики и независимые производители стали откликаться. За несколько последних месяцев все важнейшие поставщики ПРП, включая SAP, Oracle, фирмы J.D. Edwards и Computer Associates International, объявили о своих крупномасштабных инициативах по дополнению инфраструктуры своих приложений хранилищами данных и средствами онлайновой обработки данных (OLAP). Фирма PeopleSoft и компания Baan собираются сделать аналогичные объявления.

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

“Извлечение ПРП-информации превратилось в огромную проблему,  -  говорит директор международной программы фирмы Meta Group (Лондон) Тим Хермон.  -  Планы, излагавшиеся до сих пор SAP и другими поставщиками, выглядят безупречно на бумаге, однако неизвестно, что они предложат в действительности. Мы считаем, что многое из этого они не смогут обеспечить, по крайней мере в течение ближайших двух лет”.

Простой фокус

Как же случилось, что поставщики ПРП и их заказчики попали в такое неприятное положение? Здесь немаловажно то, что такие приложения, как SAP R/3, с самого начала создавались для управления транзакциями, а не запросами. В результате модели представления данных и структуры таблиц, заложенные в основу этих приложений, изначально были тонко приспособлены для получения максимальной производительности онлайновых транзакций (online transaction processing performance, OLTP). В частности, SAP предлагает разнообразные технологии хранения и доступа к информации, например объединенные фонды таблиц и кластеры, призванные обеспечить большую производительность транзакций.

Однако эти хитроумные средства при том, что некоторые пакеты приложений типа R/3 поддерживают свыше 10 000 таблиц, превращают обнаружение всех данных, необходимых для запросов комплексной системы поддержки принятия решений, в серьезную проблему. Именно на этом споткнулись такие пользователи, как Rockford Fosgate, а независимые поставщики средств извлечения и преобразования данных, включая фирмы Prism Solutions и Evolutionary Technology, до сих пор не смогли оказать им существенной помощи.

Некоторые организации пробовали справиться с проблемой самостоятельно, но извлечение информации из приложения ПРП и помещение ее в хранилище данных  -  дело долгое и дорогое. “По сути это может отнять у администратора БД все рабочее время”,  -  сказал руководитель отдела ИС фирмы Direct TV (Лос-Анджелес) Майк Скофилд, который на своей предыдущей работе принимал участие в подобном проекте.

Средства генерации отчетов, входящие в комплекты приложений ПРП, также были малоэффективны для решения этой проблемы. Хотя некоторые поставщики, например System Software Associates, снабдили свои функции отчетов поддержкой информационной системы руководителя (executive information support, EIS), большинство подобных инструментов в традиционных пакетах ПРП лишены некоторых возможностей, в том числе многомерного анализа, и их функции в основном ограничены контролем параметров производительности онлайновых транзакций. Кроме того, средства получения отчетов в комплектах ПРП, как правило, связаны всего с одним модулем, затрудняя одновременный анализ данных по нескольким функциям, например по производству и финансам.

“В R/3 можно получать отчеты только по отдельным функциональным областям, тогда как нам нужно комбинировать данные по всей системе R/3 и даже из внешних источников”,  -  говорит Бен Веттиси, директор по приложениям SAP фармацевтической промышленной компании Elf Atochem. Эта компания, внедрившая приложения R/3 на семи из одиннадцати своих предприятий, в настоящее время проводит пилотное тестирование недавно представленной системы хранилищ данных SAP.

Инициативы поставщиков

Последние инициативы поставщиков ПРП по созданию хранилищ данных призваны к тому, чтобы изменить создавшееся положение. Эти поставщики обещают выпустить интегрированные наборы инструментов, которые облегчат процесс извлечения данных из соответствующих приложений, их денормализацию или реструктуризацию из форматов, ориентированных на производительность транзакций, в форматы, ориентированные на систему поддержки принятия решений (decision support system, DSS), загрузку в заказные системы онлайновой аналитической обработки и последующий анализ множественных взглядов на данные с помощью графических инструментов (см. таблицу).

Наиболее амбициозными и в перспективе наиболее предпочтительными являются архитектуры хранилищ ПРП-данных, недавно представленные Oracle и SAP. В то время как другие поставщики, такие, как Peoplesoft и J.D. Edwards, в вопросе извлечения данных тяготеют к партнерству с независимыми производителями, поставщики инструментов онлайновой аналитической обработки и анализа планируют самостоятельную разработку почти всех инструментов хранилищ. Сюда относятся система онлайновой аналитической обработки (OLAP-engine) и даже комплект настольных инструментов анализа на основе Web, который SAP называет Business Explorer. Более того, для доступа к своей OLAP-машине и репозиторию метаданных хранилища компания предлагает третьим фирмам свой интерфейс  -  так называемый интерфейс программирования для бизнес-приложений (Business Application Programming Interface, BAPI)  -  вместо более открытых альтернатив, например OLAP-интерфейса OLE DB, недавно предложенного корпорацией Microsoft.

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

Неясно также, насколько широкую поддержку независимых разработчиков получат так называемые хранилища бизнес-информации (Business Information Warehouse, BIW) компании SAP. В частности, она еще не опубликовала спецификации интерфейса BAPI, который поставщики инструментов OLAP должны использовать для доступа к OLAP-машине SAP. Не удивительно поэтому, что никто из поставщиков клиентских инструментов до сих пор не заявил о поддержке архитектуры BIW, которую SAP анонсировала летом. Скоро начнется пилотное тестирование BIW, в нескольких компаниях. Начало рыночных поставок фрагментов кода BIW запланировано на апрель.

Однако несмотря на относительно закрытый, частный подход, новая архитектура хранилищ данных SAP обещает дать много преимуществ. Компания планирует обеспечить тесную интеграцию между R/3 и BIW, а также быстрые разработки “под ключ”. В дополнение к централизованным средствам администрирования, предназначенным для управления извлечением данных из сложной модели представления R/3 и их загрузкой на сервер BIW, эти хранилища данных будут располагать менеджером метаданных, динамически связанным с бизнес-правилами и моделью данных в R/3. Как заявляют представители SAP, благодаря этому структура данных BIW сама поменяется после того, как пользователь изменит конфигурацию или установит новую версию R/3.

BIW будет также включать заранее сконфигурированные объемы и запросы OLAP, которые обеспечат быстрый доступ к таким важнейшим наборам данных R/3, как анализ доходности и анализ наличного товара.

В мае Oracle представила собственное решение под названием OADW (Oracle Applications Data Warehouse  -  хранилище данных приложений), тоже тесно интегрированное с ее приложениями. Помимо инструментов управления хранилищем данных в него вошли собственная OLAP-машина Oracle и инструменты анализа Express Analyzer. Комплект включает серию готовых объемов OLAP, разработанных для основных тематических областей Oracle Applications, названную коллекцией.

“Мы считаем, что, предлагая набор заранее сконфигурированных объемов, даем пользователям возможность гораздо быстрее организовать свои хранилища данных”,  -  говорит директор по маркетингу продуктов подразделения приложений корпорации Oracle Питер Хеллер.

Дэвид Ричардс из Rockford Fosgate думает так же. Его компания провела бета-тестирование OADW и недавно приступила к ограниченному использованию этой системы в производстве, дав менеджерам возможность по-разному просматривать и комбинировать данные приложений Oracle, анализируя тенденции доходности в каналах производства и сбыта. Это уже дало Rockford Fosgate определенные преимущества. “Мы работаем в очень динамично развивающейся области и хотим быть лидерами на рынке”,  -  заявил Ричардс.

Замещение доморощенных систем извлечения данных инструментами Oracle, по словам Ричардса, позволило получать более свежие данные. Фактически постепенная загрузка 22 Гб производственной информации приложений Oracle с помощью инструментов OADW занимает всего 5 часов. “Это уже гораздо лучше, чем 36 часов, но мы надеемся, что когда-нибудь подобные процессы станут еще быстрее”,  -  сказал Ричардс.

Шагая рука об руку

Если SAP и Oracle пошли по пути относительно частных решений, то другие важнейшие поставщики, стремясь заполнить пробел с системами поддержки принятия решений в своих приложениях, предпочли открытые интерфейсы и партнерство с поставщиками OLAP и инструментов. Например, компания J.D. Edwards заключила договор с Oracle, в соответствии с которым последняя должна создать инструменты для извлечения и перемещения данных из своего пакета ПРП One World в хранилище данных Oracle. Кроме этого она заключила соглашения с фирмой Cognos и корпорацией Arbor Software, которые должны обеспечить совместимость своих OLAP-машин с OLAP-машиной One World. Аналогичный подход использует и компания Baan.

Что касается PeopleSoft, то она намеревается вскоре представить собственную стратегию. Уже известно, что для версии 7 приложения ПРП PeopleSoft запланирована интеграция “под ключ” данных общей системы финансового учета и OLAP-машин Cognos и Arbor. В версии 7.5 будет увеличено число заранее сконфигурированных объемов и предложены инструменты, с помощью которых пользователи смогут создавать свои собственные объемы. Наконец, через полтора года в версии 8 PeopleSoft предложит полноценное хранилище данных.

Поставщики ПРП признают, что они только начали претворять в жизнь свои обещания, касающиеся новых хранилищ данных. По словам аналитиков, здесь еще остается много вопросов. Например, SAP до сих пор не объявила цены на BIW. Такие поставщики, как Oracle и SAP, не доказали, что смогут облегчить введение в новые хранилища данных из других источников, кроме их собственных приложений.

Встроенные инструменты перемещения данных для SAP должны разработать независимые компании, в частности ETI и Software AG, однако выпуск этих продуктов еще не начат. Oracle имеет собственный инструмент, но в настоящее время он обеспечивает лишь импорт данных из БД Oracle.

Несмотря на эти проблемы, многие пользователи систем ПРП, по-видимому, намерены ждать ключей от гробницы данных. Meta Group предсказывает, что в конце концов две трети заказчиков ПРП инсталлируют хранилища данных, которые предложат поставщики их ПРП-приложений. “Мы проводим оценку BIW и, вероятнее всего, инсталлируем это хранилище одновременно с очередной масштабной модернизацией R/3,  -  сказал Бен Веттиси из Elf Atochem.  -  Создать его самостоятельно нам не под силу”.

Джефф Моуд