Мои несбыточные BI-хотелки

Прекрасно понимая, что живу в стране, далекой от производства передовых 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 продуктов.