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

Первая хотелка - назовем ее "гарантированный репортинг". Проблема всех популярных BI-платформ сегодня в том, что репортинг в них сильно оторван от ETL. Некоторые попытки по сближению расстояния делаются - в некоторых платформах (SAP BusinessObjects, IBM Cognos) появилось сквозное управление метаданными (metadata management), позволяющее свести в одну общую модель метаданных и ETL-процедуры, со схемами источников и приемников, семантические слои с описанием метаданных репортинга (BusinessObjects universes и Cognos packages) и собственно метаданные отчетов - показатели, формулы, объекты отчетов. Это помогает лучше понять как те или иные данные попали в отчет (т.н. data lineage). Но это совсем не помогает в случае, если какие-то данные пропали по дороге. Приведу пример типичной ситуации - некая организация имеет хранилище данных с ежедневной (точнее еженочной) ETL-загрузкой в ходе которой в ХД сводятся данные из нескольких филиалов по стране. В силу некоторых причин, произошел сбой в загрузке данных из одного из филиалов. Как это отразится на автоматически сформированных отчетах, которые пользователи открыли с утра, зарядившись чашкой кофе? Практически никак. Кто-то, возможно довольно быстро заметит, что в таблицах пропущен один филиал и сообщит остальным, что с данными что-то не то. Начнут разбираться и выяснится что данные про филиал потеряны. Вероятно также, что менеджер ХД позаботился о соответствующем контроле качества данных и получил в 3 часа ночи СМС с уведомлением о сбое, так что прийдя на работу первым делом организовал перезагрузку недостающих данных, известив пользователей о проблемах. Но это никак не отразится на внешнем виде отчетов - итоговые суммы, средние значения, проценты прироста и прочие показатели будут посчитаны и отображены, хотя по сути они будут некорректными. На мой взгляд BI-платформы должны содержать механизмы гарантированной правильности вычисления показателей и отображения данных в отчетах. Т.е. данные в отчетах либо должны быть гарантированно верными, либо их вообще не должно там быть, дабы никого не вводить в заблуждение.Поэтому вся цепочка метаданных от системы-источника до конкретной цифры в отчете должна быть завязана на механизм гарантии правильности посчитанных данных. Причем с указанием персонально ответственных за тот или иной участок цепочки. Это значит что в отчете должно быть отражено, что за правильность именно этих данных отвечает Петров (ETL) и Сидорова (расчет показателей внутри отчета), а в случае когда механизм гарантированной правильности определит сбой, вместо неправильных данных должно отображаться соответствующее сообщение об ошибке. И тогда будет сразу понятно, что а)данные не верны и б)за устранение проблемы отвечает Петров и/или Сидорова. Как механизм такой гарантированного репортинга будет реализован - пусть решают разработчики. Уверен, это далеко не самая сложная задача, которую приходилось им решать.

Вторая - семантическая, связанная с интерпретацией отчетов. Как выглядит типичный отчет сегодня? Это таблицы, графики, отдельные KPI, отражающие за заданный период информацию по предприятию в целом или по какой-то частной области - филиалу, бренду, продукту, группе клиентов и т.д. Пользователь смотрит на это и делает какие-то выводы. Какие выводы он делает - знает только сам пользователь. Скорее всего, он эти выводы озвучит коллегам либо устно, либо в емейл-переписке, либо в каком-то документе типа Word-овского файла или PowerPoint-овской презентации. Проблема в том, что интерпретация отчета оторвана от самого отчета. Десять человек могут смотреть в один и тот же отчет и сделать десять разных выводов. Еще 5 человек, которые откроют этот отчет через год могут сделать еще 5 разных выводов и все они будут отличаться друг от друга. Обещанная BI-евангелистами единая версия правды (single version of truth) на самом деле так и остается несбыточной. Технически, в моем представлении, в таблицах и графиках отчета должны отображаться разъяснения, причем они должны быть контекстно зависимыми - т.е. не какая-то общая приписка сбоку отчета (как это есть, например, в BusinessObjects), а зависеть от выбранного периода времени и прочих фильтров по размерностям. Нечто похожее есть в Cognos Planning, но на BI-пакет это пока не распространяется (по крайней мере не было до версии 8.4). Кстати в идеологию ассоциативной модели QlikView это ложилось бы вообще идеально. Больше того, эти пояснения должны быть в структурированной форме, чтобы их можно было искать, ассоциировать, и анализировать причинно-следственные связи. В идеале, должна быть единая для предприятия семантическая модель причинно-следственных связей, учитывающая также и нечисловые, неизмеряемые факторы, поясняющая события происходящие внутри организации, и к которой был бы доступ непосредственно из отчетов, с соответствующим контекстно-зависимым отображением возможности такого доступа на элементах отчета.

Третья хотелка - это связь отчетов с управленческими решениями. На сегодня сложилась пародоксальная ситуация: BI-системы, которые относят к классу decision support systems (системы поддержки принятия решений), не имеют никакой информации об этих самых решениях. Т.е. открыл менеджер отчет, посмотрел на него, что-то понял (см. хотелка #2) и принял какое-то решение. А вот какое - для BI-платформы остается неизвестным. И как повлияло это решение на что-то в организации - остается тоже неизвестным. И если вдруг в будущем нужно будет понять, почему то или иное решение было принято, и на какие факты опирались при его принятии - то причины весьма возможно останутся тайной, или картина будет неполной. В моем представлении, управленческие решения на предприятии должны учитываться и иметь возможность быть явно связанными с теми или иными отчетами, и/или элементами единой семантической модели причинно-следственных связей. Эта тема до последнего времени полностью игнорировалась производителями BI-платформ. Но небольшие сдвиги в этом направлении уже есть - недавно SAP выпустил пакет StreamWork, в котором есть слабые, но все же зачатки идеи фиксировать управленческие решения в привязке к BI, а в отчетах Gartner 2010г по BI-платформам уже проскальзывала мысль о необходимости в регистрации управленческих решений (decision capture). Я подозреваю, что в Gartner сделали это замечание неспроста, так как наверняка они имеют представление о том, что происходит в лабораториях, например, IBM Cognos и других разработчиков BI продуктов.

Компания QlikTech, производитель системы бизнес-анализа QlikView с штаб-квартирой в г.Раднор (штат Пенсильвания, США), вчера объявила о подаче в SEC пакета документов для выпуска своих акций в свободное обращение. Количество акций, выпускаемых в свободную продажу, и их цена будут определены после утверждения SEC. Андеррайтерами IPO выступили Morgan Stanley, Citigroup и J.P. Morgan.

Источник: пресс-релиз QlikTech

PS. Что это означает для украинских заказчиков QlikView, как потенциальных, так и существующих? Это означает что QlikTech собирается сделать массивные инвестиции в разработку, что не может не радовать. Вряд ли R&D QlikView, расположенный в г.Лунд, Швеция жаловался на недостаток финансирования - рост продаж QlikView в мире за последние годы лежал в пределах 50-80% ежегодно, а количество клиентов перешагнуло отметку в 13000. Однако, топ-менеджмент компании, очевидно, задался вывести компанию на новый уровень развития, ориентируясь прежде всего на сегмент крупных предприятий - с оборотом от 1-2 млрд. долл. и выше, и на расширение географии своих продаж. Для Украины это скорее всего будет означать более глубокую локализацию продукта (правда только русскую), включая руководства пользователя и техническую документацию, а также следующий шаг в развитии веб-клиентов QlikView. Будем надеятся, что первые результаты можно будет увидеть уже в конце этого года.

За несколько лет продаж в Украине программных продуктов от иностранных производителей выработался алгоритм "адаптации" их стандартных продуктовых презентаций под восприятие украинских заказчиков.

Помимо перевода презентации на русский язык, приходится также:

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

Во-вторых, кто-то правильно сказал - "это хорошие отчеты, которые не умеют читать". Почему-то многие считают, что чем правее и выше в отчете находится вендор, тем лучше продукт этого вендора подходит под их конкретные задачи. Это все равно что если бы все мужчины всегда покупали только 42й размер обуви, только потому что 42й размер - это #1 в по статистике продаж.

2. Почти во всех случаях (кроме презентаций в украинских компаниях, заметных в мировом масштабе) убирать/сокращать референсные списки и логотипы иностранных организаций, уже использующих продукт. Выбор, сделанный далекими заморскими компаниями, совершенно не убедителен для отечественных заказчиков. Например, небольшой украинский банк совершенно не волнует что там выбрал себе HSBC для своего филиала в Гонконге. А вот что выбрал такой же небольшой банк через дорогу - интересует гораздо больше. Ну и ли хотя-бы через границу. В смысле - северную.

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

3. Притушить "громкость" разных самоуверенных "маркетинговых" мессиджей. Наши люди особенно чувствительны к навязчивости любого рода рекламы. А бахвальные заявления типа "о непрекращающемся 7й к ряду квартал росте прибыли на акцию компании N" считаю вообще неэтичными и выбрасываю из презентаций без всякого сожаления. Истерические истории успеха типа "Вот мы купили продукт P и теперь мы в полном экстазе с утра до вечера" тоже идут под нож. Клиенты этому не верят и опять же небезосновательно. Даже примеры типа "Вот у нас был софт Х, а теперь мы заменили его на Y и получили прирост производительности в 10 раз" тоже сразу вызывают сомнения, потому что моментально возникают вопросы - а на каком железе крутился софт Х и на каком - Y? А какая была структура данных, характер нагрузки и там и там? И т.д. В этом плане кстати приятно удивил 152-страничный совместный отчет Vertica, Syncsort и HP про установленный ими мировой рекорд по скорости ETL-загрузки данных в ХД (5.4ТБ за 1 час), аудированный сторонней организацией DSS Labs. Отчет включает в себя все - аппаратные конфигурации, настройки ОС, СУБД, схемы данных, программные скрипты, цены и т.д. Хороший пример ответственности за сделанные громкие заявления.

А что же тогда остается? Хорошая продуктовая презентация должна отвечать на вопросы: какое предназначение продукта с точки зрения производителя, в чем его USP, какая может быть польза от применения продукта для конкретной задачи клиента, какие риски внедрения и эксплуатации, требуемые ресурсы для внедрения и эксплуатации, ну и конечно стоимостные характеристики.

Итак, в результате напряженной работы, начатой нами еще летом прошлого года, был создан новый бизнес под названием Acctiva, задача которого – дистрибуция программных продуктов QlikView и Vertica в Украине. Пришло, наверное, время прокомментировать - почему сейчас, почему именно QlikView и Vertica?

Начнем с того, что на мировом рынке BI происходят интересные события. Индустрия, которая зародилась в начале 90-х годов, последние несколько лет явно переживала некоторый "застой". То есть продажи BI-вендоров конечно росли, и BI как был так и оставался одним из трех самых важных приоритетов для CIO мировых компаний. Однако потенциал идей 90-х годов, заложенных в основании практических всех популярных BI-продуктов, занимающих верхние строчки в рейтингах продаж, практически иссяк. BI продукты, такие как BusinessObjects, Cognos, Microstrategy и другие шлифовались многие годы и являют собой хорошо продуманные, прекрасные инструменты, функциональность которых стала настолько похожей, что в нюансах их различий стали глубоко разбираться лишь немногие специалисты. Богатые возможности для подсоединения к источникам данных, развитые средства для моделирования метаданных, приятный глазу интерфейс пользователя,  многоплатформенность - популярные традиционные BI-средства мало в чем уступают друг другу и в каком-то плане уже превратились в commodity, когда предпочтение тем или иным продуктам отдается не из-за некоторой уникальной добавленной стоимости, которую они могут создать, а из-за того кто их продает, как их продает и чем сопровождает свое предложение. И это нормально - это значит наступила стадия зрелости рынка традиционных BI-систем. Это кстати подтверждается массовым переделом рынка BI в 2007-2008 годах, когда Oracle купила Hyperion и стала активно развивать малоизвестный до этого Siebel Analytics, превратившийся позже в Oracle BIEE, Business Objects вопреки уверениям собственного топ-менеджмента неожиданно продалась SAP, а IBM вполне предсказуемо приобрела Cognos, хотя переговоры велись и с другими игроками рынка.

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

Дело в том, что традиционные BI-инструменты являются по сути лишь визуальными построителями SQL/MDX-запросов, обрабатываемых СУБД. И в этой связке именно СУБД отвечает за скорость выполнения запросов и за производительность BI-системы в целом. К сожалению, традиционные СУБД в силу ряда архитектурных особенностей, вызванных прежде всего оптимизацией под интенсивные операции записи, весьма посредственно справляются с аналитическими запросами, для которых характерны тяжелые операции чтения, и показывают невысокую производительность в аналитических системах. Этот факт дал почву для появления за последние 10 лет по меньшей мере полутора десятка новых производителей,  предлагающих заказчикам решения, существенно превосходящие традиционные архитектуры по производительности, оставаясь при этом намного более гуманными к бюджетам. Подробнее про альтернативные архитектуры в BI, читайте в 7м номере "Компьютерного Обозрения", который выйдет во вторник, 2 марта 2010г.

Что же касается Acctiva, то она предлагает украинским заказчикам два, на мой взгляд самых интересных продукта из когорты «инноваторов», отлично вписывающихся в реалии украинского рынка:

Первый продукт - это QlikView производства американской QlikTech (R&D находится в Швеции), одних из пионеров использования подхода in-memory и добившихся в этом успехов наверное более, чем кто-либо еще. QlikView объединяет в себе наглядный, очень "кликабельный" интерфейс пользователя (покликайте сами на demo.qlikview.com), собственный ETL и мощный движок обработки данных, хранящий все данные в сжатом виде в оперативной памяти. На мой взгляд QlikView хорошо подходит под потребности заказчиков в Украине по трем причинам:  

Во-первых, объем данных, накапливаемых в большинстве украинских предприятий, по мировым меркам можно назвать небольшим. Несколько десятков или сотен гигабайт данных – объем, вполне подходящий для хранения и обработки в оперативной памяти, как это и делает QlikView, с использованием агрессивной компрессии данных. При этом скорость отработки запросов на вполне обычном оборудовании, как правило исчисляется секундами, что не может не радовать пользователей.

Во-вторых, для проектов по внедрению BI в Украине характерны относительно простые модели данных. Редко когда количество показателей и размерностей исчисляется тысячами – их число, как правило, не выходит за пределы двух-трех сотен. Так как модели метаданных становятся действительно жизненно необходимыми при количестве показателей и размерностей исчисляемом тысячами  (т.е. на очень крупных проектах), то на меньших по размеру внедрениях их принудительное использование лишь напрасная трата труда и времени, только растягивающая сроки проекта. QlikView коннектится к системам напрямую и не требует построения сложных моделей метаданных. Это существенно упрощает сроки разработки приложений, по сравнению с традиционными BI-системами.  Нет также необходимости строить промежуточные структуры типа хранилищ данных и кубов. Поэтому  начало эксплуатации первого этапа аналитической системы через 1-2 недели после начала проекта не является чем-то из ряда вон выходящим для проектов на QlikView.

А в-третьих, стоимость лицензий QlikView значительно гуманнее для бюджетов украинских компаний, традиционно весьма чувствительных к цене. Стоимость стартового пакета от 6тыс. евро и цена рабочего места в некоторых схемах лицензирования от 300 евро делают QlikView вполне доступным выбором особенно для небольших и средних предприятий.

СУБД Vertica – это второй продукт, предлагаемый Acctiva. Он имеет более узкую специализацию и применяется для аналитических систем с объемом данных от полу-терабайта и больше. Vertica - это специализированная аналитическая СУБД, изначально оптимизированная под характер нагрузки возникающей в аналитических системах. В основе архитектуры Vertica лежат 4 основные концепции:

1. Поколоночное хранение данных;
2. Агрессивная компрессия;
3. Массивно-паралелльная архитектура, работающая на кластерах недорогих Linux-серверов;
4. Встроенная отказоустойчивость без использования лог-файлов.

Эти концепции позволяют обойти многие ограничения производительности при выполнении аналитических запросов, существующих в традиционных СУБД. Поэтому Vertica позволяет получить производительность, иногда превышающую в 50-200 раз традиционные по-строковые СУБД. При этом с точки зрения приложений, Vertica является обычной реляционной СУБД, поддерживающей стандарт SQL-99, и с которой могут работать все популярные SQL-ориентированные BI-инструменты (BusinessObjects, Cognos и др.) и ETL-средства (Informatica, IBM DataStage и т.д.).  Подробнее о технической начинке Vertica читайте на нашем сайте – acctiva.co.uk.

Vertica интересна не только с точки зрения производительности, она также предлагает заказчикам удобную модель лицензирования, выгодно отличающуюся от традиционной. СУБД Vertica лицензируется только по объему данных в хранилище данных, по-терабайтно, без ограничений по количеству процессоров, ядер, памяти или пользователей, в противоположность традиционным схемам лицензирования. Думаю, это оценят многие организации, чьи затраты на лицензии исчисляются сотнями тысяч и миллионами долларов.
Кроме этих двух есть еще пару интересных технологий, как минимум одну из которых мы планируем предложить украинским заказчикам до конца 2010года, но ее название я пока оставлю в секрете.

Если подвести итог, в общем и целом, цель Acctiva – дать возможность предприятиям в Украине познакомиться ближе с инновационными технологиями для создания BI-систем и аналитических хранилищ данных, постепенно набирающим популярность в мире. Эти новые технологии -- тот самый случай, когда из-за некоей магии инноваций «быстрее» перестает автоматически означать «сложнее и дороже». А это значит, что прогресс продолжается. И хотелось бы, чтобы мы все от этого только выиграли.

Из какой индустрии может быть компания, которая добавляет в свое аналитическое хранилище данных ни много ни мало 3 ТБ/день? Нет, это не Google. А вот ни за что не догадаетесь :)

Для аналитических хранилищ данных объем в 30-50 ТБ обычно считается уже достаточно большим. Причем этот объем накапливается в течении нескольких лет. Как правило, в первых рядах рекордсменов по объемам хранилищ данных идут телекомы. Потом идут (или шли?) инвестиционные банки (которые еще остались на плаву). Потом ритейлеры. Огромные организации. Но 3 ТБ в день в хранилище из них не загружает никто. Или почти никто.

И тем более удивительно встретить в рядах рекордсменов ... разработчика софта. Это компания Zynga, которая разработывает игры для iPhone, а также Facebook и других сетей. Хранилище данных является краеугольным камнем инфраструктуры Zynga, так как собирает в режиме реального времени игровую информацию от 40 млн игроков, что составляет за сутки более 3 ТБ, моментально раскладываемых на колонки в аналитической СУБД Vertica в кластере из 200 Linux-серверов. Собранная информация анализируется по определенным алгоритмам и тут же предоставляется игрокам в виде рекоммендаций. Все это работает 24 часа в день, 7 дней в неделю, 365 дней в году без остановки.

Разработчики игр. 3 ТБ/день. Кто бы мог подумать.

Итак, как я упоминал в своем предыдущем посте, Gartner выпустила новый отчет по BI-платформам, датированный январем 2010 года. Приведем снова эти «магические квадраты»:

Вот как Gartner прокомментировала сложившуюся ситуацию:

"Рынок BI платформ в 2009 году ознаменовался борьбой Давидов и Голиафов между стойкими «чистокровными» (в оригинале pure-play – прим.пер.) BI-игроками и якобы всемогущими мегавендорами. Противостояние было вызвано глобальным переразделом и консолидацией рынка в 2007-2008гг, результатом которого в 2009-м стал период болезненной адаптации к новой ситуации с многочисленными жалобами клиентов мегавендоров, вызванными, в основном, организационной неразберихой после поглощений. Однако, несмотря на эти «болезни роста» мегавендоров, в 2009г на рынке BI-платформ доминировали комплексные «пакетные» продажи, продиктованные потребностями в информационной инфраструктуре и бизнес-приложениях, при контроле 75% рынка пятеркой крупнейших игроков. В то же время, базируясь на исследовании, сделанного для этого отчета, и опросах клиентов Gartner в течение года, очевидна значительная, если не сказать «эйфорическая», удовлетворенность и возросшая заинтересованность клиентов в «чистокровных» BI-платформах. В частности, это справедливо для небольших инновационных вендоров, ориентирующихся на потребности, проигнорированные крупными игроками. Для понимания этого парадокса необходимо рассмотреть несколько основных факторов, влияющих сегодня на принятие решения о приобретении BI-платформы:

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

2. Провидцы (Visionaries – прим.пер.) прошлого года стали Претендентами (Challengers – прим.пер.) в этом году. Благодаря интересу бизнес-подразделений, архитектура приложений для анализа данных, разработанная прошлогодними Провидцами (например, QlikView и Tibco Spotfire) и новичком «магического квадрата» Tableau, стала намного более популярной в отрасли. Организации с удовольствием принимают идею о предоставлении данных конечным пользователям и возможности анализа в режиме «свободно исследуй и запоминай» (в оригинале «surf and save» - прим.пер.), как альтернативу традиционной архитектуре, ориентированной на отчеты. Обеспокоенные успехом вышеупомянутых компаний, производители традиционных BI-платформ пытаются подражать им, выпуская продукты для упрощенного интерактивного визуального анализа данных (например, Microsoft с PowerPivot, SAP с SAP BusinessObjects Explorer, IBM c IBM Cognos Express, и Information Builders с WebFocus Visual Discovery), часто использующих технологии типа in-memory. Факт этого подражания, вместе с растущим признанием пользователей того, что инструменты интерактивного анализа данных могут быть вполне полноценными BI-платформами и использоваться для более широкого спектра задач и вариантов применения, объясняет перемещение этих вендоров из квадрата Провидцев в квадрат Претендентов. Зигзаго-образное перемещение по квадратам от Провидцев к Лидерам является довольно типичным по мере того как вендор, являясь провидцем возможно в специфической области, начинает расширять спектр своих инноваций и подходит под более широкие запросы покупателей. Реакция традиционных BI вендоров на этих новых Претендентов в 2010 году только усилится и возможно приведет к еще большей консолидации отрасли и усилению давления на тех Претендентов, которые не приспосабливают свои продукты под нужды крупных предприятий и не продолжают инновации.

3. За поглощения расплачиваются клиенты. Неразбериха с клиентами после поглощений обычно развивается по одному и тому же сценарию. После объявления о поглощении клиенты начинают беспокоиться по поводу планов развития продуктов и выполнения озвученных ранее обещаний. Позже происходит собственно юридическое поглощение, в ходе которого часто меняется служба технической поддержки, договорные условия, цены, территории продаж и  названия продуктов. Процесс изменений длится некоторое время и является довольно нелегким для клиентов. В конце концов, для успешных поглощений процесс изменений заканчивается установлением новых норм и процедур для клиентов. Так что в то время как Oracle, которая приобрела Siebel и Hyperion соответственно в 2005 и 2007 годах, благополучно двигается к завершающей стадии этого сценария, что видно по значительно улучшившимся отзывам клиентов в опросах для «магических квадратов» в этом году по сравнению с прошлым, низкие оценки клиентов IBM и SAP в этих опросах подсказывают, что они все еще находятся в муках перемен. Возросший уровень неудовлетворенности клиентов, выявленный в результате опроса, нашел отражение в баллах «Способности к реализации» (в оригинале «Ability to Execute» - прим.пер.) этих двух вендоров.

4. Переход от мониторинга к анализу, прогнозированию и оптимизации. В то время, как традиционные отчеты оставались доминирующим способом донесения информации в 2009 году, увеличивающаяся популярность интерактивных визуальных инструментов позволила ощутить эффект от свободного анализа данных большему количеству пользователей, чем когда-либо. Более того, значительно выросла потребность в более точных прогнозах и оптимизированных бизнес-процессах, а также потребность в предсказывающих показателях, вместо констатирующих, вызванная отчасти экономическим спадом. В ответ на это IBM приобрела лидера рынка прогнозной аналитики SPSS, что оказалось единственной крупной сделкой на рынке BI платформ  в 2009году. В то же время, многие «чистокровные» BI-вендоры (Information Builders, Tibco Spotfire, Microstrategy) и большинство из мегавендоров (SAP, IBM, Microsoft) начали предлагать, либо улучшили свои существующие возможности для использования статистического анализа, прогнозных моделей и алгоритмов, в отчетах, дешбордах и аналитических приложениях . Эти улучшения являются важным шагом в расширении доступности прогнозной аналитики для большего количества бизнес-пользователей, чем традиционные статистические пакеты. Такой сдвиг акцентов на рынке также нашел отражение в сближении позиций в категории «Полнота Видения» (в оригинале Completeness of Vision» - прим.пер.) у SAS и многих других игроков рынка BI.

5. Экономическая ситуация побуждает интерес к бюджетным вариантам. Затраты на BI оставались в 2009-м весомой статьей, поскольку организации обращались к BI для выживания в условиях наиболее тяжелого кризиса в современной истории. В ходе проектов по улучшению поддержки принятия решений, определению операционной эффективности и рисков, а также по более экономически оправданному привлечению новых клиентов, желание делать больше и быстрее за меньшие деньги подогрело интерес к бюджетным (в оригинале low-cost – прим.пер.) вариантам. Помимо Microsoft, как традиционной бюджетной BI-платформы, организации продемонстрировали растущее желание рассматривать open-source решения в качестве варианта для корпоративной BI-платформы, а также проявили интерес к BI-функциональности встроенной в преднастроенных аналитических приложениях и в платформах по управлению бизнес-процессами, а кроме того, в меньшей степени, к альтернативным моделям эксплуатации, таким как SaaS (Software as a Service). Поэтому отчет (Gartner – прим.пер.) содержит комментарии по нескольким альтернативным вендорам в этой категории, которые хотя формально и не попадают под критерии включения в «магические квадраты», тем не менее являют собой вполне жизнеспособную альтернативу для некоторых организаций со специфическими требованиями."

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

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

На прошлой неделе Gartner обновила свои "магические квадраты" посвященные BI-платформам. Хотя в последнее время гартнеровское позиционирование игроков в этом отчете все чаще вызывает сомнения и дискуссии среди аналитиков и обозревателей рынка BI, тем не менее отчет все равно интересен, хотя бы как точка зрения.

Итак, по мнению Gartner квадрат на январь 2010г. выглядит следующим образом:

Для сравнения приведем эти же "квадраты" за 2009г.

Изменения, как видно достаточно существенные. И снова вызывают много вопросов.

Кстати в этот раз, публикацию этого отчета в открытом доступе спонсировали Microsoft и SAS.

(продолжение следует)

По-моему стильненько :)

Индустрия средств для автоматизации бизнес-анализа (BI)  в мире (прежде всего – в западном) и в Украине развивается по разным сценариям. Так уж сложилось. Разный масштаб предприятий, разные уровни конкуренции на рынках, разные уровни технологической зрелости компаний, разные внутренние требования к уровню сервиса и качеству продукции – все это и многое другое является причинами того, что на рынке приложений для бизнес-анализа в мире и в Украине актуальны разные тенденции. Впрочем, своей заметкой мне вовсе не хочется пополнить и без того многочисленные ряды национал-пессимистов – вместо этого хотелось бы сделать небольшой обзор того, чего в украинском BI еще нет, но вполне возможно появится в некотором будущем. Итак:

1.    BI-стандартизация.

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

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

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

2.    «Облачный» (cloud) BI или SaaS (Software as a Service) BI.

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

В общем выглядит как привлекательная бочка меда, но, как это бывает в жизни, не без ложки дегтя. В первую очередь стоит вопрос конфиденциальности данных, размещенных в облаке, который еще больше обострился из-за недавнего скандала с Google и китайскими хакерами. Возникает резонный вопрос - если уж Google не смогла обеспечить достаточный уровень защиты конфиденциальных данных, то стоит ли вообще полагаться на такую модель.
Вторым неоднозначным вопросом является надежность и квалифицированность самого поставщика «облачных» услуг. Тут вопрос обострило скандальное проишествие с принадлежащей Microsoft Danger, которая потеряла данные пользователей «облачного» сервиса T-mobile Sidekick

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

3.    Open-source BI.

Open-source приложения для бизнес-анализа постепенно становятся все более зрелыми и все больше притягивают внимание потенциальных заказчиков. Несмотря на то, что в мире есть много примеров успешного коммерческого использования open source ПО, бизнес-анализ остается областью, где свободное ПО не находится в мейнстриме и остается уделом пионеров-экспериментаторов. Отчасти это объясняется тем, что BI-приложения по определению являются критическими для бизнеса, так как являются конечным поставщиком информации для принятия тактических и стратегических решений. А значит цена ошибки или сбоя является весьма высокой. Кроме того для многих, особенно крупных коммерческих организаций, гораздо более критичним является уровень поддержки продукта и защищенность инвестиций, чем стоимость лицензий или «фенечки и рюшечки» продукта. Вместе с тем, стремление оптимизировать затраты, особенно в период кризиса, подогревает интерес к подобного рода продуктам, которые в некоторых случаях становятся предпочтительным выбором например для государственных учереждений, или для областей анализа, не столь критичных для бизнеса.

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

4.    Операционный BI.

Операционный BI – это применение BI-инструментов не только для стратегического или тактического менеджмента, где временная шкала измеряется в первом случае в месяцах-кварталах, а во втором случае – в днях-неделях, а и для операционной деятельности компании. В этом случае временная шкала измеряется от реального времени (real-time) до часов, оставаясь обычно в пределах дня.

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

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

5.    BI в SOA архитектуре.

Этот тренд в значительной степени пересекается с предыдущим пунктом об операционном BI. Сама по себе концепция сервис-ориентированной архитектуры (service-oriented architecture) является гораздо более широкой, чем область приложений для бизнес-анализа, но когда применение BI на операционном уровне приняло широкие масштабы, стало очевидно, что SOA как нельзя лучше подходит для такой реализации. В этом случае BI-система организуется как набор сервисов, которые могут вызываться извне как непосредственно пользователями, так и внешними приложениями, например учетными системами, системами электронного документооборота или же системами workflow management. По сервисной архитектуре могут быть построены не только средства визуализации (генерирования отчетов), но и работа ETL-процедур. Такая организация открывает прекрасные возможности для создания BI-приложений, функционирующих в сложной, географически распределенной ИТ-инфраструктуре, в режиме реального времени или близком к нему. Недаром IBM, как большой апологет SOA приобрела именно Cognos, который имеет внутреннюю архитектуру построенную на веб-сервисах, из-за чего хорошо вписывается в более общую сервис-ориентированную архитектуру предприятия. Хотя такая более сложная внутренняя архитектура несколько сказывается на общей производительности Cognos. Заметно продвинулись в ориентации собственных BI-инструментов на SOA также Oracle и SAP, хотя они больше тяготеют к проприетарности, чем IBM. С точки зрения ETL-инструментов, IBM Information Server был перестроен по сервисной архитектуре с выходом 8й версии летом 2008года. Informatica также перешла в лагерь приверженцев SOA с недавним выходом 9-го поколения своего продукта, полностью сервис-ориентированного.

Пока что украинские компании, выбирающие BI/ETL средства для построения собственных систем бизнес-анализа не обращают внимания на SOA-готовность претендующих продуктов, и не упоминают как-либо SOA в перечне критериев выбора, предоставляемых поставщикам. Это вполне понятно, учитывая низкую осведомленность о SOA у отечественных ИТ-архитекторов и малое количества проектов по SOA в Украине. Однако по мере роста предприятий и роста количества разнообразных учетных и транзакционных систем в компании, вопрос интеграции данных встанет более остро. Возможно к тому времени подоспеет и желание расширить применение BI и на операционную деятельность. Хорошо, если существующие на тот момент времени в предприятии BI инструменты будут позволять сделать это без особых сложностей. Ибо если нет, придется смотреть первый пункт – про «зоопарк» BI-систем и BI-стандартизацию.

На мероприятии SAP Influencer Summit в Бостоне было объявлено о том, что юниверсы BusinessObjects будут содержать метаданные по нескольким разнотипным источникам (сейчас один юниверс может описывать данные только в одном источнике). Т.е. для юниверсов будет использоваться принцип федеративного доступа к данным. Кроме того, предполагается сделать модели многоуровневыми - с разным уровнем абстракции для бизнес-пользователей и ИТ-разработчиков.

С одной стороны - это давно ожидаемое, в кругах разработчиков, новшество. С другой стороны - тот же Cognos, например, давно уже это использует. Равно как и многоуровневое представление метаданных. Это хорошо для крупных (по мировым масштабам) предприятий, где внедрение BI затрагивает сотни и тысячи пользователей. Для таких случаев, хорошо классифицированная модель метаданных с разными уровнями абстрации - жизненная необходимость, дабы не потеряться в сотнях и тысячах показателей и размерностей (аттрибутов).

Но боюсь, для украинских реалий, где превалируют небольшие и средние BI-проекты, а количество пользователей редко переваливает за сотню и в большинстве случаев ограничивается двумя-тремя десятками, это будет означать, что трудоемкость разработки на BusinessObjects вырастет, и будет сравнима с трудоемкостью разработки на том же Cognos. Это также означает, что разрыв в сложности разработки, по сравнению например с BI-продуктами от QlikView или Microsoft, которые используют достаточно минималистическое представление метаданных, будет увеличиваться совсем не в пользу SAP BusinessObjects.