Страница 1 из 1

Какие данные нужны для принятия эффективных решений

Добавлено: Вт апр 08, 2008 9:57 am
Alan
Никитин М.В.
(по материалам citcity.ru, С. Кузнецов Основы хранилищ данных и BI по Ральфу Кимбаллу)


Ральф Кимбалл (Ralph Kimball) всемирно известен как первопроходец, автор статей и книг, преподаватель, лектор и консультант в области хранилищ данных. В течение многих лет он сохраняет убежденность в том, что при проектировании хранилищ данных нужно стремиться к их понятности и быстроте. Его книги по методам многомерного моделирования и проектирования хранилищ данных являются постоянными бестселлерами.

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

Основными абсолютными принципами проектирования хранилища данных по Кимбаллу являются простота (с точки зрения конечных пользователей) и производительность (оправдывающая ожидания конечных пользователей). Дополнительными аспектами, учет которых желателен при проектировании, являются накладные расходы (на само проектирование, на повседневное администрирование и т.д.), стоимость (персонала, программных и аппаратных средств), риски неполучения требуемых результатов, риски чрезмерной централизации.

Основные проблемы, которые выделяет Ральф Кимбалл в области построения корпоративных систем управления данными.

1. В хранилище данных оказываются недоступными данные, необходимые для принятия решений.

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

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

2. Отсутствие четкого взаимопонимания между конечными пользователями и специалистами в области ИТ.

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

Господин Кимбалл предлагает радикальное и неожиданное решение этой проблемы: организовать перемещение специалистов между отделом IT и отделами, в которых работают конечные пользователи корпоративных систем (сроком примерно на год). Это позволит специалистам в области IT завоевать доверие конечных пользователей, лучше узнать специфику бизнеса компании и потребности ее заказчиков.

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

3. Отсутствие явной познавательной и концептуальной модели конечных пользователей.

Симптомом этой проблемы является выбор ИТ-специалистами инструментальных средств на основе бесед с потенциальными продавцами и знакомства с демонстрационными версиями без учета реальных потребностей пользователей. Проблема проявляются в том, что ИТ-специалисты стремятся к сложным решениям и подразумевают, что конечным пользователям нравятся компьютеры, что, по мнению Кимбалла, является величайшим заблуждением.

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

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

4. Запаздывание данных, требуемых для принятия решений.

Очень часто данные требуются в реальном времени. Здесь под требованиями «реального времени» понимаются любые требования к временым характеристикам данных, которые не могут быть удовлетворены действующей процедурой ETL (Extraction, Transformation, Loading – Извлечение, Преобразование, Загрузка).

Решение видится в использовании готовых шаблонов обработки данных, опять же, настраиваемых самими пользователями. Это позволит в реальном времени выделять необходимые наборы данных и применять заранее созданные заготовки решений.

5. Разнообразные факты и измерения препятствуют интеграции корпоративных данных.

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

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

6. Недостаточная подробность данных.

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

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


7. Неудобные форматы данных.

По мнению Кимбалла, неудобной является нормализованная форма реляционных данных. Проблему усугубляет запутанность и запуганность пользователей, сложность формулировки запросов, потребность в специализированном оборудовании для достижения требуемой производительности.

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

8. Слишком медленная доставка данных конечным пользователям.

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

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

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

9. Невозможность перемещения некоторых данных между различными приложениями.

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

Использование общепринятых приложений для работы с отчетами (Excel, Word, Web-браузеры) позволит значительно упростить как процесс восприятия информации пользователями, так и даст им дополнительные возможности по модификации данных.

10. Низкое качество данных.

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

11. Преждевременная агрегация данных.

Наличие в многомерной модели агрегированных данных без соответствующих атомарных данных не позволяет проводить детализацию данных.

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

12. Отвлечение внимания на оценку показателей возврата инвестиций (ROI) хранилища данных.

А именно, расчет показателей ROI до создания хранилища данных с применением стандартных методов, основанных на периоде окупаемости, чистой приведенной стоимости, внутренней норме прибыли, системе сбалансированных показателей, экономической добавленной стоимости, до создания хранилища данных. По мнению Кимбалла, во всех этих методах упускается основной смысл стоимости и, в конечном счете, ценности хранилища данных.

Хранилище данных поддерживает принятие решений. Рекомендуется после принятия решения отнести часть полученной прибыли на счет хранилища данных, а затем сравнить ее с расходами на хранилище данных. Г-н Кимбалл рекомендует считать, что 20% прибыли, полученной в результате принятия решения, получено благодаря использованию хранилища данных. Такой подход соответствует той идее, что единственным осмысленным способом оценки эффективности хранилища данных является оценка его возможности поддерживать принятия решений конечными пользователями.

13. Затрата сил и времени на создание корпоративной модели данных.

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

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


В общем и целом, можно говорить о том, что реляционная модель построения корпоративных хранилищ данных требует серьезного переосмысления. Различные виды нормализованных реляционных СУБД, идеально подходящие для хранения и обработки статистических массивов данных, оказываются слабо приспособлены к требованиям современных корпоративных систем, где в первую очередь важна динамика, и уже совсем не подходят для систем реального времени и обработки потоков данных. Попытки Oracle, IBM и других лидеров индустрии баз данных расширить традиционную модель за счет использования многомерности, объектно-ориентированного подхода приводят в первую очередь к значительному усложнению систем. В результате необходимая функциональность становится практически недоступной рядовому пользователю, требует огромных затрат на внедрение и сопровождение. В итоге приходится мириться с необходимостью использования огромных неповоротливых систем класса ERP, при этом по старинке решая критические задачи управления «в уме» с использованием простейших средств автоматизации.

Возможно, чего-то нового в этом направлении можно будет ожидать от традиционного монополиста – компании Microsoft. В последнее время компания значительно расширила сферу своего присутствия на рынке корпоративного ПО и уже заметно подвинула традиционных игроков. Microsoft всегда отличались умением вовремя замечать перспективные направления в развитии технологий, вполне возможно, что именно от них мы увидим интересные решения. Популярности решений Microsoft, безусловно, будет способствовать высокая распространенность традиционных пользовательских приложений – Office и Internet Explorer.

Не стоит сбрасывать со счетов и компанию Google. Ее web-ориентированные пользовательские продукты могут составить серьезную конкуренцию продуктам от Microsoft. При этом все большее распространение получает сетевой подход к организации корпоративных данных.

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