`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Дмитрий Гудков

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

+22
голоса

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

+22
голоса

Напечатать Отправить другу

Читайте также

Очень интересная статья. Я сам когда то занимался ERP для предприятия в 500 человек.
Но, почему Вы пишете несбыточные хотелки?
Жизнь ведь продалжается. Мы компьютеры по настоящему только начинаем использовать.
И то что сейчас применяется для управления предприятиями - это примитивщина.
Есть еще огромное поле работ для автоматизации.

Как раз насчет 3-й хотелки довольно много можно привести примеров связи управленческого решения и результата работы BI приложения.
Например в системах кредитного скоринга расчитываемый скоринговый бал потенциального заемщика используется не только для принятия решения (управленческого по сути) о выдаче/отказе выдачи кредита, но и записывается в ХД вместе с информацией о самом запросе на кредит и в дальнейшем используется в анализе для оценки качества прогнозной скоринговой модели. Т.е. обеспечивает обратную связь, помогающую модифицировать модель , т.е. улучшить качество управленческих решений. Тоже самое можно сказать и о решениях для Сегментации, Прогнозирования и т.п. Аналитических решениях. Правда, говоря о таких решениях, я имел в виду именно Business Intelligence. одной из функций которой есть извлечение скрытой информации из данных. В Вашей статье же речь идет об Отчетности, т.е. визуализации прошлого. А используя ТОЛЬКО отчеты о прошлом очень трудно сделать формализованное решение, которое потом можно было бы использовать, для анализа качества самого решения. К слову именно Отчетность большинство пользователей называют Business Intelligence, что по моему мнению является не вполне корректным. Отчетность это одна из возможностей BI приложения, а Business Intelligence - другая. Хотя могу предположить, что это вопрос дефиниций, но даже технологически - для решения этих задач в BI приложениях используются различные инструменты. К сожалению в Вашей статье не упоминаются решения Business Intelligence от SAS Institute,. С остальным согласен. есть такие проблемы.

Александр, спасибо за комментарий. BI это сокращение от Business Intelligence, к которому относят универсальные инструменты трех категорий - высокоформатированная отчетнось (reporting), интерактивный анализ данныз (query & analysis), дешборды и карты KPI (dashboarding & scorecarding).
В некоторых частных приложениях действительно могут быть обратные связи между фактическими данными и прогнозируемыми. Особенно это актуально в приложениях, использующих статистические модели, для которых обязательно должно быть регулярное уточнение. Однако в данном случае речь идет о другом - явном, сформулированном, однозначном ответе на вопрос "почему было сделано решение?", включающем как числовые измеряемые факторы, повлиявшие на решения, так и неизмеряемые (например изменения законодательства). Что касается SAS - я знаком достаточно поверхностно с решениями этого вендора, поэтому полагаюсь на позиционирование отраслевых аналитиков, которые относят SAS не к pure-play BI, а к сегменту который называют Advanced Analytics или Analytical Applications. Впрочем, те же аналитики отмечают взаимное движение навстречу портфелей pure-play BI и AA-вендоров. Первые строят коробочные отраслевые приложения (IBM, Oracle, SAP) включающие прогнозные модели, а вторые, включая SAS расширяют возможности по BI.
Что касается "отчетов о прошлом" - это отчасти правда, но лишь отчасти. Не стоит преувеличивать влияние статистических моделей. Они неспособны заменить человека в процессе принятия решений, потому как человеческий мозг действует по совсем другому принципу, чем цифровые вычислительные системы, построенные на императивном выполнении машинных команд.

Здесь мы либо используем разные термины для определения понятий, либо у Вас недостаточно информации о коробочных решениях SAS Institute. Например о том, что у SAS есть готовые преднастроенные индустриальные платформы:
- SAS Banking Intelligent Solutions
- SAS Telco Intelligent Solutions
- SAS Retail Intelligent Solutions

каждое представляет из себя набор ПРЕДНАСТРОЕННЫХ решений для аналитики в областях: Финансы, Клиенты/Продажи, Риски, Операции. Каждое решение построено с учетом специфики индустрии и может работать автономно, на базе общей платформы.
Все они включают в себя логическую и физическую модели, хранения и анализа данных, учитывающей специфику соответствующей индустрии (банки,телко, ритейл и т.п.). Преднастроенные наборы отчетов, учитывающие специфику индустрии.

Все включают в себя инструменты полного цикла преобразования данных:
- ETL,(извлечение/трансформации/загрузка)данных)
- DDS (хранение данных)
- Data marts
- OLAP
- Information Delivery Portal

все включают в себя приложения для преобразования данных, их анализа, моделирования, отчетности, визуализации.

Это реальные коробочные решения, которые тем не менее нуждаются в кастомизации по месту (клиенту).
И внедряют их как коробочные решения.

Что-то не понял к чему это Вы написали. Я видел массу всяких продуктовых презентаций. Если Вы решили здесь вкратце изложить содержание еще одной - я не против, только боюсь формат комментариев не позволит раскрыть тему надлежащим образом :)

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT