Лирическое вступление

Когда потоки корпоративных данных выходят из-под контроля и «девятым валом» захлестывают автоматизированные системы, не спешите строить ограждения, укрепляя стены ИТ новыми дорогими программными продуктами. Информация — это благо, ее нужно не ограничивать, а очищать, структурировать и направлять по месту назначения — в специально спроектированные многомерные хранилища. Там, в укрощенных, кристально-чистых аналитических разрезах отразятся бизнес-процессы предприятия, на информационной глади засверкают экономические модели, открывая менеджерам новые горизонты управления. Да и проверенные временем автоматизированные системы, избавившись от несвойственных им функций, еще засверкают новыми конкурентными гранями, оставляя системам поддержки принятия решений (СППР) задачи анализа, моделирования и прогноза.

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

Попробуем ответить на эти вопросы, подкрепляя рассуждения примерами из реальных проектов.

Термины и категории

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

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

  • интеграция и верификация внутренних и внешних информационных потоков;
  • надежное и эффективное хранение согласованных исторических данных;
  • предоставление средств оперативного многоуровневого управленческого анализа;
  • предоставление технологичных инструментов развертывания и сопровождения.

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

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

На другом конце спектра решений находятся системы бюджетирования, позволяющие автоматизировать, в разрезе центров ответственности, подготовку, контроль и анализ исполнения корпоративного бюджета. С технической точки зрения такие системы представляют ограниченный интерес, так как сравнительный анализ проводится лишь по сотням, максимум по тысячам показателей. Для таких задач скорее важны предметные аспекты согласования бюджетов, а от детализации фактических данных исполнители проектов, как правило, на постановочном уровне умело дистанцируются, поэтому эффективность хранения и анализа для них — задача второго плана. Нам представляется, что именно здесь кроются серьезные проектные риски. В результате такого внедрения решается только задача ввода и согласования плановых показателей — без их глубокой привязки к факту. Отсутствие детальных фактических данных практически лишает менеджера возможности проводить серьезный факторный анализ, оценивать адекватность применяемых методик. Это значительно сужает спектр моделей прогноза и анализа по схеме “что если”. Скорее всего, детальный план-факт анализ все равно будет проводиться, но по старым технологиям, “на коленке”, вне рамок системы.

Весьма похожи на СППР системы подготовки параметризованных отчетов. Они, как правило, достаточно мощны, чтобы формировать многомерные отчеты с аналитическими разрезами. Из-за терминологической путаницы такие системы иногда относят к OLAP-решениям, каковыми они на самом деле даже по формальным признакам не являются, так как не имеют в своем арсенале ни средств многомерного хранения информации, ни специализированного аппарата моделирования и прогнозирования. Системы подготовки отчетов лишь имитируют инструменты многомерного хранения — с серьезными временными потерями. А на уровне метаданных они способны решать задачи поддержки принятия решений только на ограниченном объеме данных. Когда же в информационное хранилище переносится вся экономическая история компании и время представления данных превышает десятки, а то и сотни минут, все плюсы, вытекающие из удобства и гибкости описания отчетов, меркнут, и инструмент предстает тем, чем он, собственно, и был с самого начала, — дорогим генератором отчетов.

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

Мир — дворцам, война — хижинам

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

Как известно, чудес не бывает — выигрывая в одном, система должна в чем-то другом уступать своим конкурентам. Альтернатива многомерным хранилищам данных — это хранилища реляционные. В чем архитектурные преимущества многомерного подхода и что определяет границы его применимости? Без ответа на этот вопрос нельзя выбрать конкурентоспособное проектное решение.

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

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

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

Прикладная архитектура

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

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

Рассмотрим системный подход более подробно на примере аналитического многомерного инструмента Oracle Express и сопоставим предлагаемые оптимизационные решения со стандартными подходами, реализованными в базовом аналитическом инструменте Oracle Financial Analyzer (OFA). Перечислим вначале оптимизационные технологии, предоставляемые базовым программным обеспечением.

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

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

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

Достаточно ли этих возможностей для корпоративного решения? Количество измерений только по финансовому блоку информационных потоков компании, как правило, составляет десятки, а чаще сотни формализованных реквизитов. Предположим, что их десять. Но количество разрезов в единичном кубе физически не должно превышать пяти-шести измерений: в противном случае резко ухудшается как производительность, так и удобство представления и анализа данных. И если на постановочном уровне определено, что многомерный анализ необходимо осуществлять по произвольной комбинации измерений над множеством показателей, то количество сочетаний C[5,10] составляет более 250 пятимерных кубов. Очевидно, что практически такую архитектурную конструкцию реализовать невозможно, а значит, требуются организационные решения, значительно сужающие аналитическую часть проекта. В этом случае аналитик перед построением интересующего его разреза или отчета должен очень внимательно проанализировать документацию и понять, существует ли такая возможность в принципе.

Здесь на помощь приходят специализированные предметно-ориентированные архитектурные решения. Рассмотрим их подробнее.

Априорная сегментация топологии

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

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

Предварительный расчет реляционных связей

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

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

Многовариантность представления

Базовый инструментарий дает разработчикам СППР еще один удобный технологический прием. Для представления информации можно визуализировать не сами значения, хранящиеся в многомерных переменных, а их виртуальную форму — формулы. В вырожденном случае формула эквивалентна самому значению, но при наращивании сложности алгоритмов, обслуживающих этот механизм, аналитик может получить целый шлейф показателей, рассчитанных над исходными данными. Причем, что самое важное, “на лету” преобразуются только те ячейки таблицы или точки графика, которые в данный момент видны на экране. Многократное копирование в базе вторичных данных не нужно — большая их часть может быть рассчитана именно в тот момент, когда они будут реально востребованы с точностью до ячейки. Примером использования такого подхода может быть горизонтальный или вертикальный анализ многомерных агрегатов, цветовое структурирование данных, расчет итоговых показателей для динамически формализованных фактор-групп.

Баланс между статикой и динамикой

Последовательные оптимизационные шаги переводят систему в новое качество — в нашем случае аналитическая система обладает всеми исходными данными и предрассчитанными связями, обеспечивающими эффективность обработки и агрегирования. Стандартный подход, предполагающий хранение многомерных переменных на постоянной основе, может быть пересмотрен. Если время формирования “на лету” многомерных разрезов, определенных аналитиком в процессе подготовки принятия решения, укладывается в эргономические требования, то возможен разумный баланс между вычислительной мощностью и размерами многомерной базы. Часть наиболее востребованных кубов со сложными алгоритмами расчета можно накапливать статически, остальные агрегаты должны быть формализованы в многомерные отчеты и рассчитаны пользователем в рамках сеанса работы. При этом многомерный анализ, независимо от технологии хранения и расчета, обслуживается стандартной функциональностью, куда входит весь джентльменский набор средств — от графического представления данных с разной степенью детализации до сложных моделей прогноза и анализа “что если”.

Если использовать такой системный подход, то на сакраментальный вопрос заказчика: “Может ли менеджер самостоятельно провести полнофункциональный многомерный анализ бизнес-объектов по любым произвольным разрезам, формализованным с учетом решаемой задачи, непосредственно в момент принятия решения?” — можно дать положительный ответ. И чем глубже проработка предметной области, чем активнее используются априорные знания о методах анализа, тем эффективнее решения, принятые с помощью аналитического инструмента.

Алексей Галаган — директор департамента информационно-аналитических систем компании "Борлас Ай-Би-Си" (http://www.borlas.ru).