Дюжина революций, которые так и не произошли в Business Intelligence (BI)

Юрий Кудрявцев
По материалам статьи Найджела Пендса (Nigel Pendse) "A dozen “next big things” in Business Intelligence that did not happen"

1 марта 2007 г

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

Ниже приведен список 12 наиболее значительных “революционных изменений”, которые так и не произошли. Список, конечно, субъективен, но все изложенные идеи достаточно долго продвигались многими вендорами (или аналитическими агентствами), что подразумевает значительные инвестиции. Некоторые из этих предложений благополучно забыты, другие все еще ждут своего часа.

1. Информационная система руководителя (Executive Information System, EIS)

Разработка подобных систем в 80-х гг. прошлого века велась с большой помпой и азартом. Симпатичные графические интерфейсы, управление мышью и сенсорные экраны. На фоне мейнфремов и персональных компьютеров с DOS EIS смотрелись пришельцами из будущего. Поддерживались цветная графика, возможность интегрировать данные из структурированных и неструктурированных источников, данные из внутренних и внешних систем, ad hoc анализ, многомерные структуры, KPI (Key Performance Indicators) - все те идеи, что благополучно дожили до наших дней в отличие от самих EIS.

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

Несмотря на угасание термина EIS, многие возможности таких систем нашли отражения в современных информационных панелях (dashboards). Согласно результатам последнего опроса OLAP Survey, менее 20% респондентов ответили, что используют EIS, и более 30% используют OLAP-средства для создания информационных панелей. Всего два года назад EIS были впереди.

2. Средства построения систем сбалансированных показателей (Balanced Scorecard)

Многие вендоры (например, Gentia) в 90х годах увидели для себя рыночную нишу приложений для создания систем сбалансированных показателей. Однако от их внимания ускользнул тот факт, что описанная Норбертом и Капланом система показателей представляет собой много большее, нежели программное приложение. Система сбалансированных показателей – это, прежде всего, система управления, пронизывающая все предприятие, и ее создание – это далеко не рутинная работа, лишь в малой степени зависящая от IT. Подобные системы создаются в рамках масштабных проектов по бизнес-консультированию, только на основе результатов которых может быть внедрено какое-либо специализированное программное обеспечение. Немногие организации прошли этот путь до конца, в ряде случаев под видом системы сбалансированных показателей скрывается лишь расширенная инструментальная панель или EIS.

Рай для производителей программного обеспечения поддержки систем сбалансированных показателей так и не наступил, и многие компании (например, Gentia) просто исчезли. Опросы последних лет показывают, что только в 30% внедрений BSC используются специальные инструменты. Excel все еще является доминирующим средством решения подобных задач.

3. BI в экстранет

В эпоху бума доткомов вендоры BI видели быстрый рост использования BI-приложений для межкорпоративного обмена информацией. Это открывало умопомрачительную возможность продавать лицензии не только на всех служащих компании, но еще и на всех внешних контрагентов, клиентов, поставщиков. Более того, в такое светлое будущее верили не только поставщики программного обеспечения, но и клиенты: более 70% респондентов первого издания OLAP Survey в 2000 году планировали внедрить BI-системы для общения с внешним миром в течение пары лет. К 2006 страсти несколько поутихли, только 43% респондентов надеются внедрить BI для экстранет к 2008. Хотелось бы отметить, что доля компаний, уже внедривших подобные решения, остается неизменной (в районе 15%-16%). По-видимому, слишком мало компаний считают необходимым предоставлять своим клиентам online-аналитику.

4. Анализ данных на основе data mining и методов искусственного интеллекта

В конце 1990-х ожидалось, что персональные средства data mining обеспечат доступ ко всем новым достижениям в области анализа данных и поиска скрытых закономерностей прямо на рабочих местах аналитиков. Основные вендоры, такие как Cognos и Business Objects, с гордостью демонстрировали свои продукты, призванные решать эту задачу. Business Objects лицензировала собственную технологию data mining, а Cognos купила компанию Forethought, специализировавшуюся на подобных решениях.

Однако вендоры недооценили тот факт, что для обычных пользователей методы анализа были слишком сложны и, что самое важное, слишком высока была цена ошибки. Выбор метода, проверка корректности выполнения анализа, уточнение входных параметров требовали специальных навыков или образования. Причем задачи все усложнялись с возрастанием сложности алгоритмов. Создавалась дилемма: доступные широкому классу пользователей алгоритмы были слишком малоэффективны, а усложнение набора методов требовало специальной подготовки от будущего пользователя, сужая рыночную нишу. К тому же, высококвалифицированные аналитики уже имели доступ к статистическому программному обеспечения от таких компаний, как SAS Institute или SPPS. Тем не менее, ряд компаний, включая Hyperion, Microsoft и MicroStrategy все еще предлагает упрощенные средства data mining, связываемые с системами OLAP.

5. Предварительно подготовленные аналитические приложения вместо моделирования данных

Ожидалось, что предварительно подготовленные аналитические приложения, основанные на использовании предопределенных моделей данных, для специализированных бизнес-областей или вертикальных индустрий заменят трудоемкий и затратный процесс разработки таких приложений с нуля. Однако Business Content (SAP), Rapid Marts (Business Objects), Performance Applications (Cognos) и другие предопределенные модели часто служат лишь для демонстраций или прототипирования, не освобождая от разработки модели данных в каждом конкретном случае. В случае отказа от разработки специальной модели данных возникают проблемы с производительностью, удобством поддержки, неконтролируемым ростом данных, и в результате следует полное перепроектирование системы.

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

6. Встраивание OLAP в СУБД

Во второй половине 90-х гг., когда основные производители СУБД (начиная с Oracle в 1995) обратили свое внимание на область OLAP-приложений (Online Analytical Processing), казалось, что пройдут считанные годы, и средства OLAP будут интегрированы в ядро СУБД. По крайней мере, так обещали в Oracle. Путем соединения продвинутых технологий хранения реляционных данных и многомерные технологии OLAP и переноса их на уже существовавшие РСУБД платформы, вендоры намеривались представить более масштабируемые, быстрые и интегрированные продукты, которые вытеснили бы независимых поставщиков OLAP-приложений.

Хотя все это выглядело логичным и неизбежным, подобный синтез технологий так и не произошел до сих пор. Компания Oracle более других продвинулась к этой цели, однако в Olap Option по-прежнему используется почтенные средства Express. Данные действительно хранятся в реляционных таблицах, однако это в формате данных MOLAP (Multidimensional OLAP), представляемых в таблицах полями BLOB (binary large object), к которым, естественно, нельзя напрямую обращаться реляционными запросами. Т.е. базы данных Express хранятся внутри таблиц Oracle без существенных изменений. Для обращения к OLAP-данным можно использовать SQL, однако при этом происходит внутреннее преобразование в формат многомерных запросов Express.

Microsoft продает Analysis Services вместе с SQL Server, даже не претендуя на внутреннюю интегрированность этих продуктов. После многих лет брожения слухов и домыслов IBM не купила Arbor Software (ставший впоследствии Hyperion) и, более того, прекратила перепродавать продукт Hyperion Essbase, который одно время рекламировался как IBM OLAP Server. Более того, была прекращена разработка ROLAP-версии (Relational OLAP) этого продукта, продавался просто Hyperion Essbase (сервер MOLAP) без какой либо специальной интеграции с DB2. IBM сделала еще одну попытку в проекте IBM Cube Views, однако и этот проект не был коммерчески успешным. Terradata продала свой продукт TerraCubes компании Microstrategу, в недрах которой он и прекратил свое существование. Computer Associates “по случаю” приобрела два ROLAP-продукта, но никогда не пыталась интегрировать их со своими СУБД.

7. BI-порталы

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

8. Естественный язык запросов

Обработка запросов на естественном языке – это еще одна заманчивая, но все еще не реализованная идея. Еще в 1980-е гг. имелась возможность запрашивать базы данных на мейнфреймах IBM на чистом английском языке, используя продукт Intellect от компании AICorp, но результаты были слишком непредсказуемы и ненадежны. Поэтому по мере обнаружения наборов запросов, выдававших правильные результаты, их просто включали в пункты меню. К сожалению, естественные языки не обладают точностью, присущей истинным языкам запросов, так что даже увеличивающееся быстродействие современных компьютеров не гарантирует корректных результатов. Например, Microsoft ввела средство English Query в SQL Server 6.5, улучшала в версиях 7.0 и 2000 - и полностью отказалась от него в версии 2005.

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

9. Новые методы визуализации данных

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

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

10. CRM-аналитика (Customer Relations Management)

На пике популярности CRM решений (начало нового тысячелетия) вендоры BI начали продавать свои продукты для анализа CRM-данных. Некоторые из них выпустили предварительно подготовленные аналитические приложения; особенно перспективным казалось направление анализа журналов Web-серверов. Однако в последнем опросе OLAP Survey лишь 1.7% респондентов отметили, что используют BI-приложения для анализа трафика (4,8% в 2003 г.). И лишь 11.5% респондентов используют OLAP для анализа CRM-данных (17.9% в 2002 г.).

11. BI реального времени (real-time BI)

Время от времени производители средств BI и ETL (Extract-Transform-Load) пропагандируют идею BI-приложений реального времени. В некоторых случаях имеются в виду системы реального времени в общепринятом смысле (разрыв в доли секунды между прохождением транзакции и отображением ее в отчете), в других - контролируемая задержка или же новая технология быстрого перестроения аналитических кубов. Но потребность в BI-приложениях реального времени далеко не очевидна. В некоторых приложениях требуется отчетность реального времени, но это не BI в обычном толковании этого термина, а гораздо более узкие и специфичные применения. Обычно от BI-приложений требуется отчетность на определенную дату (или время), мало кто хочет иметь отчеты, цифры в которых все время меняются. А в случае возникновения задачи отчетности реального времени обычные BI-средства испытывают затруднения при интеграции с шинами обмена сообщениями и часто просто недостаточно быстры.

12. BI для соблюдения правовых норм

Введение ужесточенных правил учета в США и Европе казалось золотой жилой для производителей аналитического программного обеспечения. Полагалось, что для соответствия требованиям Sarbanes-Oxley, IFRS и Basel II понадобится внедрение дорогих систем отчетности и аналитики. Однако, хотя на практике подобные проекты действительно оказались весьма дорогими, они были направлены на проведение аудита всех систем и внедрение новых транзакционных приложений, а не систем BI и CRM.

Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.