Основатель компании Hired Brains, поставщика услуг по исследованиям и анализу в области BI и консалтинговых услуг по системам поддержки принятия решений, хранилищ данных и BI-приложений, а также партнер-основатель компании Business Intelligence Alliance.
На большинстве предприятий присутствует пестрый набор разнокалиберных инструментов для аналитики, генерации отчетности и оповещений, причем они никак не связаны в единую BI-архитектуру. Но ситуация должна и будет меняться. Это типичная история о балансе хороших и плохих новостей: хорошо то, что отрасль BI стоит на пороге гигантского прыжка вперед, и плохо, что многие участники рынка отстают от прогресса.
За прошедшие 10 лет приложения, относящиеся к классу Business Intelligence (BI), выросли из простого расширения модуля отчетности на мэйнфреймах до обязательного инструмента распространения и анализа информации. Параллельное взрывообразное распространение хранилищ данных, помноженное на растущую популярность таких общекорпоративных решений, как ERP и CRM, а также повальный рост компьютерной грамотности стали той питательной средой, в которой быстро выросла и сформировалась потребность в BI-решениях и компаниях, их предлагающих. "Поставщики BI-платформ пришли на этот рынок с самых разных рынков: приложений для генерации отчетности (Brio Software и Crystal Decisions), средств генерации запросов (Business Objects), приложений многомерного анализа (Hyperion Solutions и Cognos), инфраструктур (Microsoft и Oracle), бизнес-приложений (SAP), а некоторые начали с нуля (MicroStrategy). Все это разнообразие ведущих поставщиков объединяет термин "BI-платформа", но им еще придется над многим поработать", -- пишет журнал Forrester Research в статье "Взлет BI-платформы". На сегодняшний день на рынке присутствуют уже версии 6 и 7 BI-инструментов, и это свидетельствует об определенной зрелости рынка (стоит заметить, что у части продуктов номера версий явно завышены).
Несмотря на эту относительную зрелость, BI-инструментам еще далеко до приложений, входящих в список решений, обязательных для внедрения на любом предприятии. Однако многие поставщики упорно игнорируют безотлагательную потребность в введении новшеств и вместо совершенствования и расширения своих архитектур сосредоточили внимание на развитии таких тупиковых и "модных" направлений, как панели индикаторов и сбалансированные системы показателей.
Чтобы стать по-настоящему эффективным инструментом, BI должен подняться до уровня остальных корпоративных решений, например как это произошло с бухгалтерскими системами. Сначала в бухгалтерии использовались стандартные системы класса "главная книга/счета кредиторов", на смену которым пришли ERP-решения. Многие поставщики предпочли не переходить на новую архитектуру и решали проблему простым добавлением недостающей функциональности, например подключением модуля учета затрат по операциям. Но неспособность решить архитектурные ИТ-проблемы и необходимость поддерживать до 30 различных версий одного приложения во многих странах закономерно выбросили этих поставщиков на свалку истории. Такая же судьба ждет поставщиков BI, которые проигнорируют общую тенденцию, пойдут на поводу у клиентов и не инвестируют средства в переработку базовых технологий.
Зоопарк BI-решений
Разрыв между "настоящим" ПО уровня предприятия и местом, сейчас занимаемым BI, огромен. В большинстве случаев BI даже не в состоянии охватить целиком одно подразделение и используется лишь на уровне мелких отделов. Процесс выбора часто напоминает конкурс красоты, где решение принимается по принципу "нравится-не нравится", а не на основе четких архитектурных критериев. Нередко приходится видеть, что в одном подразделении установлены два, три и даже больше BI-инструментов.
Хотя некоторые аргументируют подобный пестрый зверинец выбором лучших из существующих решений, утверждая, что каждая программа обеспечивает максимальную производительность, но на поверку такая аргументация оказывается несостоятельной. Производительность катастрофически снижается из-за увеличивающегося кратно числу приложений объема усилий и ресурсов на поддержку, причем это почти не компенсируется высокой производительностью отобранных приложений.
Кроме того, если вновь возникающие бизнес-процессы требуют перемен в хранилище данных, приходится изучать, согласовывать и реализовывать эти изменения не в одном, а в двух или трех BI-решениях, что попросту сводит на нет выигрыш в производительности и быстродействии.
Но, вероятно, наибольшую опасность представляет отсутствие единства, а это нарушение одного из основополагающих принципов хранилищ данных: на предприятии должна существовать "одна правда". К слову сказать, это утверждение чуть преувеличено, так как "правда" в некоторых областях, например бухучете, в любом случае достаточно субъективна. Точности ради следует заметить, что одна из главных целей создания хранилищ данных заключалась в существенном устранении или по крайней мере снижении вероятности получения различных результатов на основании одного и того же набора данных. Поскольку в хранилище данных нет всех расчетных, производных и сводных данных, задача обеспечения точности и целостности таких вычислений ложится на BI-решение.
Невозможно гарантировать точность и целостность в среде со многими BI-инструментами. Для простых запросов и сверток это может быть и несущественно но в более сложных моделях, одна лишь синхронизация вычислений в нескольких разнородных инструментах представляет из себя задачку не из простых. Очень высока вероятность, что отражение изменений, происходящих "наверху", в хранилище данных, приведет к задержкам и ошибкам, даже если это всего лишь ошибка синхронизации.
Кроме того, не существует BI-инструмента, который хорошо работает со стандартной схемой хранилища данных, - большинство требует физического изменения архитектуры хранилища данных. В ситуации со многими BI-инструментами, у каждого из которых свои требования к хранилищу, очень туго приходится архитекторам баз данных. Не исключены конфликты запросов.
Все эти обстоятельства ясно говорят, что использование BI-решений многих поставщиков - плохая идея. Но в мире редко что-то происходит без причины. Почему же, невзирая на все недостатки, компании предпочитают пользоваться более чем одним BI-инструментом? Скорее всего, другого выбора просто нет.
В существующих на настоящий момент "некорпоративных" BI-средствах есть ряд основных функций, но нет одного инструмента, который поддерживает их все:
- специальные запросы и OLAP-анализ;
- статистика, data mining и визуализация;
- корпоративная отчетность;
- анализ с использованием кубов данных;
- доставка отчетов и уведомления.
По сути, в первом приближении определения общекорпоративного BI-решения должны присутствовать все эти функции BI. Причем они должны быть реализованы в рамках единого интегрированного каркаса, предусматривающего архитектуру, метаданные и API (на базовом уровне, а не на уровне программной оболочки приложения).
Разброд и шатание в BI-инструментах
BI-проекты, в которых развертывается только один из подобных инструментов, порождают фрагментацию. Например, многие BI-инструменты основаны на "кубах", хранят данные на "толстых" клиентах или используют оба подхода. Поэтому их масштабируемость ограничена, причем в нескольких направлениях. BI-средства не поддаются вертикальному масштабированию для управления обширным объемом данных, хранящихся в современных хранилищах данных. Также не поддерживается масштабирование по количеству сотрудников (или внешних работников и партнеров), потому что на обновление всех этих данных и ПО требуются совершенно неподъемные административные усилия.
Некоторые поставщики предлагают несколько продуктов, объединенных в единый "набор программ", но даже в лучших из них интеграция сильно ограничена.
В некоторых инструментах поставщики недостаточно поработали над SQL-ядром, которое должно "уметь" генерировать SQL-запросы, оптимизированные для базы данных, с которой работает BI-приложение. Этот недостаток вынуждает создавать нижележащие структуры: витрины данных, кубы и т. п. Из-за этого увеличивается время ожидания при обращении к хранилищу данных, снижается ценность информации, полученной из хранилища, чрезвычайно ограничивается диапазон возможных типов анализа, а ценность всего проекта сводится на нет.
Конечный результат всей этой фрагментации заключается в невозможности для подразделений эффективно совместно использовать данные; управление изменениями требует слишком много усилий и не обеспечивает ожидаемого роста эффективности (и это в то время, когда предприятия должны резко повышать свою "гибкость"), а обеспечение согласованности моделей, определений и даже данных становится неподъемной задачей.
Вавилонская башня BI требует огромных скрытых затрат - оплату работы так называемых теневых ИТ-сотрудников, специальных людей в не-ИТ-подразделениях - финансовом, маркетинговом, управления персоналом или продаж, которые тратят существенное количество своего рабочего времени (до 60 %) на наведение порядка в данных. Выполняя огромную ручную работу по "забивке" данных, созданию и поддержке электронных таблиц и персональных баз данных, вводу, поиску и распространению данных, эти специалисты тратят на выполнение своих прямых обязанностей лишь небольшую часть своего времени - львиная доля рабочего дня уходит на операции с данными, которые, по идее, должны в значительной степени взять на себя хранилище данных и BI-инструменты.
Архитектура оперативных систем обработки данных давно уже не похожа на латаный-перелатаный тришкин кафтан - именно переход к единым решениям вызвал к жизни хранилища данных. Как ни странно, но теперь уже BI-сфера стала разноцветной мозаикой из разнородных приложений - виртуальных островков интеграции.
На пути к корпоративным BI-решениям
Самые крупные и развитые общемировые компании, имеющие достаточно ресурсов и прав на это, энергично реализуют "гибкие" архитектуры, которые призваны освободить корпоративную среду от разнообразия оперативных систем. Подобные инициативы ставят своей целью избавиться от изолированности оперативных систем отдельных подразделений и должны позволить изменять конфигурацию бизнес-процессов на лету, что потребует определенной гибкости этих решений. Однако во многих из этих компаний нижележащие витрины данных и кубы, создаваемые на основе информации из большого и малодоступного хранилища данных, полностью изолированы друг от друга и создаются на основе разных, подчас несовместимых технологий. В то время, когда исчезает разрозненность, борьба с которой привела к появлению хранилищ данных, большинство BI-решений пока все больше погружаются в трясину изоляции.
Те немногие поставщики, которые серьезно задумались об этой проблеме, быстро продвигаются к созданию по-настоящему корпоративного BI-решения. Для других поставщиков это зловещий знак: чтобы перейти на следующий уровень, они должны выбросить за борт старые разработки и перестроить большую часть, если не всю базовую архитектуру. Истинная корпоративная BI-платформа должна обладать рядом качеств.
Полный набор API-интерфейсов. В сущности, лучше иметь более чем один API-интерфейс, например пару Java 2 Enterprise Edition и .Net. API должны предоставлять доступ к 100 % функций всего пакета, обеспечивая возможность прозрачной интеграции в полнофункциональный набор оперативного ПО.
Мощное SQL-ядро. Поскольку не существует достойной альтернативы получению скрытых сокровищ хранилищ данных средствами SQL, BI-решение должно содержать мощный генератор SQL-запросов. Он должен уметь выполнять аналитические запросы лишь в рамках реляционной СУБД (со временем сложность этого требования облегчится за счет внедрения OLAP-ядра и SQL-расширений), используя многопроходную логику и SQL, специально оптимизированный для используемой базы данных.
Достаточная производительность. Корпоративное BI-решение должно обеспечивать достаточную производительность даже при работе с самыми объемными базами данных.
Открытость схемы. BI-решение должно уметь работать с самыми разными схемами баз данных, не требуя физического их изменения.
Масштабируемость. Приложение должно легко масштабироваться от сотен до тысяч или даже миллионов пользователей. По мере внедрения BI-приложений в бизнес-процессы доступ к ним становится "прозрачным". Во многих случаях они вызываются не самим интеллектуальным работником, а автоматизированным агентом, в реальном времени реагирующим на определенные условия, Web-приложением для интерактивных продаж через Интернет или практически любым компонентом, которому нужны аналитические данные.
Единое хранилище метаданных. В BI-решении должно быть единое хранилище метаданных с открытой схемой и полной документацией. Кроме того, и это самое важное, оно должно обеспечивать преемственность и совместимость различных версий схемы метаданных. Некоторые поставщики считают метаданные частным элементом своего ПО и позволяют себе вольности при обновлении версий. В единой гибкой среде подобное отношение недопустимо.
Интеграция в соответствии с метаданными. Любая интеграция между модулями должна реализоваться в рамках метаданных, обеспечивая своего рода ссылочную целостность, которая гарантирует возможность развития и расширения системы всеми участниками. Это условие запрещает удаление зависимых компонентов и добавление компонентов, несовместимых с существующими. Подобная согласованность должна распространяться на весь спектр инструментов разработчика и администратора.
Цель - результаты
Настоящее значение корпоративного BI-решения не в его архитектурной целостности, а в способности помогать сотрудникам выполнять свою работу. Согласованная архитектура интересует технологов, но "рабочих интеллектуального труда" это не интересует. Настоящая проверка инструмента заключается в испытании на предмет того, как он справляется с задачами, выполнения которых требуют от него пользователи. Число запросов в день, терабайты, метаданные, API-интерфейсы - все это мало интересует интеллектуальных работников. Для них важно, экономят ли все эти технологии время и предоставляют ли аналитические данные в интерфейсе, который не вызывает тошноту из-за своей сложности. Эти два требования можно сформулировать и так:
- единый (предпочтительно на основе Web) интерфейс, простой и единообразный для всех подразделений;
- достаточно "мозгов" и вычислительной мощи для полного решения сложных задач - с начала и до конца.
Чтобы еще глубже понять эффективность использования корпоративного BI-решения, мы провели сравнение процедур, которые необходимо провести для решения пяти различных видов исследований, для двух случаев: работа через корпоративное BI-решение и получение тех же или похожих результатов из набора существующих BI-приложений (см. таблицу). Наглядно видно, сколько пользы может принести предприятию общекорпоративное BI-решение.
Таблица. Пример того, как корпоративная архитектура BI коренным образом меняет картину.
| То, что делается за одну операцию в корпоративном BI-решении... | ...в обычном BI-решении представляет собой длительный процесс |
| Коррелирование принадлежности продуктов и профилирование всех активных клиентов и наилучших клиентов для определения продуктов для перекрестных продаж, создание и управление кампаниями. | Использование метода "наилучшего предположения" для определения принадлежности и профилирования ограниченного числа продуктов. Подведение итогов в виде куба или электронной таблицы. Ручной анализ и отправка результатов программисту SQL для разработки статичного запроса либо пересылка плоского файла в систему SAS. |
| Контроль соответствия платежей условиям, налагаемым на счета кредиторов, и наличия всех доступных скидок; мониторинг сроков кредитов для анализа тенденций; создание сводных отчетов для совета директоров по кредитной политике и их распространение. | Сегментирование данных счетов кредиторов по времени и другим признакам для размещения в кубе для целей анализа. Перегруппировка данных посредством ПО для преобразования. Перенос их в систему генерации отчетов и рассылка по электронной почте группе получателей. |
| Контроль в реальном времени потоков информации о приобретаемых по рецептам таблетках конкретного лекарства и использование кластерного анализа для немедленной пересылки уведомления в центр контроля заболеваний о возможных несчастных случаях или эпидемии. | Запуск на исполнение рассчитываемого ночью, после обновления хранилища, отчета о покупках медикаментов по рецептам. Проверка на предмет аномалий и проблем утром. Отправка результатов по электронной почте в центр контроля заболеваний. |
| Прогнозирование спроса на продукты, продаваемые через Web-сайт, на основании исторических данных и других индикаторов, полученных посредством data mining, для предотвращения отсутствия заказываемого товара на складе. | Выборка данных о продажах в приложение data mining. Разработка новой OLAP-модели с использованием индикаторов и заполнение куба итоговыми данными о продажах. Экспорт сводного отчета в Excel для создания прогноза. |
| Оценка кампании по продвижению продукта путем выявления корреляции между частотой кампаний (без перестройки базы данных) и кривой продаж и определение эффективных и неэффективных категорий и критериев; просеивание запросов на самом низком уровне детализации. | Абстрагирование от агрегируемых качеств продукта и сведение детализированной информации о продажах в управляемый набор данных. Постановка задачи программисту на разработку программы на SQL, которая позволит обнаружить корреляцию кампаний и кривой продаж (время измеряется днями или неделями). |
Следующая волна BI-приложений
Компании стали покупать корпоративные решения-наборы, но обнаружили, что, как сказал Дуг Нил из компании CSC Research, они обладают гибкостью жидкого бетона: жидкий он только вначале, но в затвердевшем состоянии крепче камня. Поняв это, компании перешли к стратегии интеграции приложений - разумное, но далеко не идеальное решение. С появлением таких стандартов, как язык разметки бизнес-процессов (Business Process Markup Language), компании вскоре смогут не только проектировать свои бизнес-процессы, но в любой момент изменять их - хоть посередине рабочего дня. Но подобной гибкости придется подождать пару-тройку лет.
Сегодня поставщикам BI-приложений пришла пора самым тщательным образом пересмотреть свои технологии и подготовиться к следующей волне перемен. Грядут трудные времена, так как это сегмент рынка, в котором менее всего инноваций. В технологиях хранилищ данных наблюдается огромный прогресс в области внутренних процессов, таких, как выборка, преобразование, загрузка и обеспечение качества данных; только в течение нескольких последних лет поставщики баз данных значительно улучшили свои продукты; а весь бизнес, связанный с хранилищами данных, стал намного более безопасным и предсказуемым.
И лишь в сегменте BI наблюдается застой. Состав ключевых игроков ненамного изменился за последние 10 лет, а ведь за это же время список Fortune 500 изменился почти наполовину. Грядет грандиозный передел рынка. BI разменял второй десяток, и теперь появилась огромная возможность повышения производительности. Избавление от теневых ИТ-сотрудников, задержек, "царьков данных" и других затруднений позволит освободить анализ, превратив его в действие. Поставщикам, предпочитающим и дальше "без шума и пыли" разрабатывать свою рыночную нишу, оставаясь в комфорте "ничегонеделания", не выжить. Появятся молодые шустрые новички, которые вступят в активную конкуренцию с немногими "грандами" BI-решений. Ну а существующие пользователи BI-приложений должны быть готовы к пересмотру своего выбора.
