Тема номера: Аналитические системы и хранилища данных

Алексей Галаган,
директор Дирекции интеграционных проектов
Консалтинговой группы “Борлас”
(www.borlas.ru)

Практические аспекты систем поддержки принятия решений

Источник: статья предоставлена компанией “Борлас” (www.borlas.ru)

Первый вариант статьи был опубликован в журнале “Intelligent Enterprise”, №6, 2003г.

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

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

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

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

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

Все дело в терминах

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

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

И так, задачи СППР могут быть сформулированы следующим образом:

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

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

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

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

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

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

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

Часть 1. Архитектура: “Мир дворцам - война хижинам ”

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

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

Начнем с преимуществ:

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

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

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

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

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

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

Вот оптимизационные технологии, предоставляемые базовым программным обеспечением:

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

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

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

Количество измерений только по финансовому блоку информационных потоков компании, как правило, превышает десятки, а чаще сотни формализованных реквизитов. Предположим, что их десять. С другой стороны, количество разрезов в единичном кубе физически не может превышать пяти - шести измерений, в противном случае резко ухудшается как производительность, так и удобство представления и анализа данных. И если на постановочном уровне определено, что многомерный анализ необходимо осуществлять по произвольной комбинации измерений над множеством показателей, рассчитанных над исходными данными, то количество сочетаний (C m,n где m=5, а n=10) составляет более 250 пятимерных кубов. Очевидно, что практической реализации, такая архитектурная конструкция не имеет, и требуются организационные решения, значительно сужающие аналитическую часть проекта. В этом случае аналитик, перед тем как строить интересующий его разрез или отчет, должен очень внимательно проанализировать документацию и понять, существует ли такая возможность в принципе.

Специализированные, предметно ориентированные архитектурные решения:

• Априорная сегментация топологии
  Предварительный анализ состава входных информационных потоков позволяет, структурировать исходную информацию и осуществлять обработку и хранение устойчивых множеств по специально разработанным методикам. Характерным примером такой априорной сегментации является выделение бизнес объектов с топологией “двулучевая звезда”. Все формализованные реквизиты такого объекта имеют одно общее базовое измерение и одно уникальное для каждого реквизита, описывающее область допустимых для него значений. При лобовом решении задачи преобразования данных из реляционного представления в многомерное, появляется желание спроектировать куб, состоящий из общего измерения и всех уникальных разрезов каждого формализованного реквизита. Как правило, это дорога в информационную бездну. Получается гигантский многомерный куб, оптимизировать который не возможно, даже применяя описанные выше способы. Структура же наполнения его следующая: на пересечении базовой оси с любым измерением, заполненным оказывается только один элемент. Это подсказывает подход, связанный с разбиением бизнес объекта на множество одномерных кубов, прошитых единой технологией обслуживания группы с общим базовым измерением. Ограничения статуса через реляции любого реквизита, распространяется на всю группу. При таком решении коэффициент разреженности практически равен единице, а усложнение групповой обработки компенсируются значительным повышением скорости представления информации, оставляя пользователя, как и прежде, в многомерном пространстве анализа.
• Предрасчет реляционных связей
  Одной из основных операций обработки многомерного пространства является многокритериальное усечение статусов измерений, образующих многомерный куб. Как правило, обработка реляционных связей, через которые осуществляется усечение при реальном, а не демонстрационном, наполнении измерений - крайне не эффективна. А если учесть, что в процессе анализа используются данные операции довольно часто и в различных комбинациях, это одна из оптимизационных точек системы. Решение лежит в плоскости построения избыточных межмодульных связей. Так в примере с “двулучевой звездой”, все реляции, связывающие справочники с базовым измерением куба можно продублировать специальными “value_set” множествами, в которые группируются коды, имеющие общие значения. Тогда вся последующая обработка строится не на медленном переборе реляций для обслуживания алгоритмов, сложных многокритериальных выборок, а на эффективных операциях над предрасчитанными множествами. Таким образом, затратив ресурсы при регламентной загрузке на расчет избыточных связей, мы получаем мультипликативный эффект при многократной обработке данных конечными пользователями. Время обработки и представления данных при таком решении уменьшается в разы.
• Многовариантность представления
  Базовый инструментарий дает в руки СППР разработчиков еще один удобный технологический прием. При представлении информации можно визуализировать не сами значения, хранящиеся в многомерных переменных, а их виртуальную форму – формулы. В вырожденном случае формула эквивалентна самому значению, но при наращивании сложности алгоритмов, обслуживающих этот механизм, аналитик может получить целый шлейф показателей, рассчитанных над исходными данными. Причем, что самое важное, “налету” преобразуются только те ячейки таблицы или точки графика, которые в данный момент видны на экране. То есть вместо многократного копирования в базе вторичных данных, большая их часть может быть рассчитана только в тот момент, когда она будет реально востребована с точностью до ячейки. Примером использования такого подхода может быть горизонтальный, вертикальный анализ многомерных агрегатов, цветовое структурирование данных, расчет итоговых показателей для динамически формализованных фактор групп.
• Баланс между статикой и динамикой Последовательные оптимизационные шаги переводят систему в новое качество: в нашем случае, аналитическая система обладает всеми исходными данными и предрасчитанными связями, обеспечивающими эффективность обработки и агрегирования. Стандартный подход, предполагающий хранение на постоянной основе многомерных переменных может быть пересмотрен. Если время формирования “налету” многомерных разрезов, определенных аналитиком в процессе подготовки принятия решения, укладывается в эргономические требования, то возможен разумный баланс, между вычислительной мощностью и размерами многомерной базы. Часть наиболее востребованных кубов со сложными алгоритмами расчета могут накапливаться статически, все же остальные агрегаты должны быть формализованы в многомерные отчеты и рассчитаны пользователем в рамках сеанса работы. При этом многомерный анализ, независимо от технологии хранения и расчета, обслуживается стандартной функциональностью, куда входит весь джентльменский набор средств от графического представления данных с разной степенью детализации, до сложных моделей прогноза и анализа “что если”.

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

Часть 2. Функциональность: “ Чем точнее предметное позиционирование, тем мощнее инструмент анализа”

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

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

• Средства подготовки отчетов (reporting);
• Нерегламентированные запросы (ad-hoc query);
• Многомерный анализ (multidimensional analysis);
• Моделирование и прогноз (planning).

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

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

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

Универсальная функциональность – это когда неудобно всем…

Большинство интерфейсных решений современных аналитических систем имеют общий и весьма серьезный, недостаток – для работы с ними требуются глубокие знания в области IT-технологий. Они ориентированы на аналитиков, способных мыслить системными категориями, самостоятельно описывать в этих терминах сложные выборки и правильно интерпретировать полученные результаты. Такой подход серьезно сужает границы применимости СППР, и из корпоративного стандарта превращает в инструмент “продвинутых одиночек”. Фактически же, в большинстве компаний уже сформировался Excel стандарт, он и должен выступать в качестве границы сложности интерфейса, при этом СППР на порядки должна превосходить Excel по объему данных и скорости работы с ними. Такой подход требует отказа от универсальной функциональности, предлагаемой в базовом программном обеспечении. Только таким способом можно обеспечить реальную альтернативу файловой Excel дезинтеграции.

Рассмотрим некоторые наиболее критичные точки штатной функциональности, требующие практического усиления:

• Отсутствие ресурсной детерминированности
  Если не принимать в расчет ограничения доступа к данным, аналитик обладает возможностью обрабатывать и сопоставлять гигантские объемы информации, используя при этом всю аналитическую мощь системы. Очевидно, что многомерные операции поиска, моделирования и прогноза могут переводить СППР в режим пиковых нагрузок на аппаратные ресурсы системы, поэтому, предлагая в качестве базовой функциональности векторные операции над историческими данными, поставщик решения обязан предусмотреть дополнительные встроенные средства контроля их использования. Это могут быть жесткие ограничения на объем обрабатываемой информации или мягкие средства оповещения о прогнозируемом времени обработки запроса. Некоторым, слабо подготовленным пользователям, часть наиболее ресурсоемкой функциональности может быть вообще закрыта. В любом случае должна быть полностью исключена ситуация, когда аналитик неосознанно завешивает систему на длительное время. К сожалению именно так и происходит при работе в штатном решении. В базовую функциональность просто не заложены такие возможности, а ее закрытость и жесткость не позволяет достраивать эти компоненты при внедрении. Последствия очевидны - пользователи не контролируют ситуацию и, как правило, не штатно завершают работу. Вычислительные ресурсы системы при интенсивной работе критического количества пользователей, переходят в системный клинч. Причем ни организационными, ни техническими способами расшивать такие ситуации, как правило, не удается. Система становится практически не пригодной для корпоративного промышленного использования.
• Завышенные требования к IT-квалификации конечных пользователей
  Штатный инструментарий описания не формализованных запросов чрезвычайно сложен, что практически исключает работу с ними предметных специалистов, в совершенстве не владеющих информационными технологиями. Не подготовленному аналитику, а тем более руководителю, трудно оперировать такими системными категориями как реляции, иерархии, специальные операции над множествами, требующие знания математической логики и структуры хранилища данных. Использовать универсальное решение как корпоративный стандарт можно только при очень высокой квалификации всех специалистов компании. При специализированном подходе предлагается полностью исключить работу пользователя с системными объектами. Иерархии и реляции становятся невидимыми, вместо них применяется предметно ориентированная технология динамически настраиваемых меню, обслуживающая операции усечения многомерного пространства через реквизиты предметно связанных бизнес объектов. Это позволяет не только упростить описание запросов, но и повысить критериальную мощность многомерных усечений. Специализация, конечно, требует наработанных решений и больших усилий при настройке системы, но альтернативы ровно две: либо высокие требования IT-квалификации к группе внедрения, либо высокие требования IT-квалификации к конечным пользователям, что предпочтительнее - необходимо решить при выборе инструмента.
• Функциональная неустойчивость к аналитическим разрезам со сложной топологии
  Штатные средства многомерного анализа: поворот, сечение, раскрытие, свертка не приспособлены для работы с измерениями, содержащие реальное, а не демонстрационное, количество элементов со сложной топологией множественных иерархий. Базовое решение крайне не эффективно когда количество элементов в измерениях превышает сотни записей. Стандартное представление на экране, так называемых, “страничных” разрезов многомерного куба, не представленных в строках и столбцах таблицы, уподобляет аналитика танкисту, оценивающего мир через узкую смотровую щель. Это яркий пример того, как недостатки функциональности, подчиняют себе всю методику анализа. Прежде чем начать хоть какие-то осмысленные действия, пользователь должен ограничить измерения куба до нескольких элементов, независимо, надо это для получения результата или нет, иначе ему просто невозможно будет работать. Специализированное решение обязано ориентироваться на реальные объемы. Для того чтобы зафиксировать интересующее сечение, аналитик должен иметь удобный механизм поиска требуемого элемента среди тысяч других, используя операции раскрытия выбранного измерения, расширенного контекстного поиска, либо усечение через информационно связные объекты. Ни смена регламента анализа, ни операции вращения, в специализированном решении не должны приводить к смещению статусов базовых осей, что неизбежно происходит в штатной схеме из-за технических ограничений на количество элементов в измерениях многомерного куба.
• Отсутствие активных средств представления данных
  Стандартные решения используют экранную таблицу как форму представления информации, что для двумерных таблиц вполне естественно, а многомерных явно не достаточно. Дело в том, что ячейка таблицы это не просто поле с данными, это пересечение нескольких измерений, это сопоставимая точка на графике, это, наконец, агрегат под которым скрываются детализированная информация и алгоритмы, на основе которых он рассчитан. В специализированной системе должен быть реализован интерфейс, позволяющий, в зависимости от заданного режима работы, обрабатывать активность пользователя, динамически определять статусы измерений многомерных переменных, отображаемых в таблице, и использовать полученную информацию в связных модулях или графических объектах. На этом принципе может работать межмодульные переходы, многомерное вращение, графическое отображение показателей, горизонтальный и структурный анализ. Управляющей панелью становиться весь экран, что при большой функциональной насыщенности весьма полезное расширение. Возможности многомерного анализа при этом переходят в иное качество, но настройка такой функциональности требует специальной технологий для предметной адаптации системы.
• Узкий подход к композиции типов многомерных фактов
  Стандартный подход к многомерному анализу предполагает, что объектом исследования являются однотипные, как правило, числовые факты. Хотя понятно, что при событийном анализе, более содержательном и информативном, необходимо сопоставлять факты различных типов. Соответственно и стандартная многомерная отчетность, подразумевающая элементарную фиксацию многомерного куба под нужным углом зрения, всего лишь частный случай общего способа построения отчетов, когда в соседних колонках находятся факты комбинированных типов.
• Персонификация и оптимизация сценариев многокритериальных усечений
  В штатной реализации, ограничения на базовые измерения многомерных кубов выставляются вне связи друг с другом, что приводит к появлению в результирующем подмножестве срезов, по которым полностью отсутствуют данные. И хотя существует механизм, подавления на экране пустых строк и столбцов, их присутствие при реальном наполнении многомерного хранилища весьма пагубно влияет на реактивность векторных операций. Более того, если, например, для анализа исторических данных, измерение используется в нескольких многомерных модулях и требует для одного из них предельный диапазон значений, то и во всех остальных кубах аналитик вынужден будет оперировать тем же избыточным набором, хотя реально данные заполнены значительно уже. При специализированном подходе, усечение статуса измерения влечет за собой коррекцию связанных справочников. В этом случае, прежде чем ввести дополнительный критерий отбора, пользователь всегда видит динамическое подмножество, полученное за счет усечения на предыдущем шаге. Он имеет возможность сохранять в самой базе персональные динамические сценарии ограничений, используя их позже для построения персональных отчетов или выборок или передавая в корпоративное пользование. Прослеживается та же идея повышения эффективности анализа: если формализованных реквизитов мало, аналитик способен удержать в памяти сценарий усечения, если мы говорим о реальном корпоративном проекте, количество переходит в качество и работать без специализированного сервиса практически невозможно.

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

Часть 3. Технология: “Даже если птица ходит по земле, видно, что у нее есть крылья…”

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

Без развернутого моделирования не ясно, какими характеристиками будет реально обладать система:

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

А решение ровно эти задач и составляет большую часть стоимости проекта.

Проектирование: “Сделайте мне красиво…”

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

Наиболее реалистичным мы предлагаем считать следующую последовательность шагом проектирования аналитической системы:

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

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

• Масштабность и логическая сложность бизнес объектов управления
  Структура и реквизитный состав бизнес объектов может превышать тысячи наименований, а с учетом системных сущностей, их в среднем около десяти на каждый предметный реквизит, количество объектов в многомерной базе может превышать десятки тысяч. Ручная, пусть с использованием современных графических средств, технология проектирования хранилища крайне не эффективна. Штатный инструментарий должен быть дооснащен специализированным, автоматическим генератором базы данных. Как один из вариантов решения, источником генерации может выступать формализованный Excel файл, описывающий реквизитный состав и логические связи бизнес объектов. Используя его, генератор в автоматическом режиме создает или модифицирует информационное хранилище. Такая технология не только распараллеливает этап описания метаданных, что является одним из узких мест корпоративного проекта, но и оставляет в качестве “сухого остатка” работы квалифицированной команды архитекторов, понятный Excel документ, который позволяет службам сопровождения расширять и модифицировать предметную область, не опускаясь до уровня физических сущностей.
• Другая, не менее актуальная технологическая проблема, создание и сопровождение многомерных агрегатов, методик их расчета и моделирования. И опять, количество таких показателей и динамика изменения моделей настолько велика, что стандартный подход в больших, корпоративных проектах не применим. И здесь возможен вариант использования формализованных Excel файлов, их многопользовательское обслуживание прикладными администраторами и последующий накат на метаданные системы. И в этом случае понятный службам эксплуатации документ будет выступать и как описатель предметного решения, и как источник для модификации метаданных.

Внедрение: “А был ли мальчик?”

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

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

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

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

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

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

Сопровождение: “ Если система не развивается, значит, она умерла…”

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

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

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

P class=bodycopy> И так некоторые результирующие выводы - систематизация и сравнительный анализ схем хранения, обработки и представления информации, позволяет потребителю корпоративных СППР решений уже на предпроектной фазе выбора инструмента оценить риски и cпрогнозировать выходные характеристики системы, способной или не способной дать компании дополнительные конкурентные преимущества.