Системы поддержки принятия решений: практические аспекты, часть II

Чем точнее предметное позиционирование, тем мощнее инструмент анализа

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

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

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

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

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

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

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

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

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

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

Отсутствие ресурсной детерминированности

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

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

Завышенные требования к ИТ-квалификации пользователей

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

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

Функциональная неустойчивость к аналитическим разрезам со сложной топологией

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

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

Отсутствие активных средств представления данных

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

Узкий подход к композиции типов многомерных фактов

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

Персонализация и оптимизация сценариев многокритериальных усечений

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

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

Технология

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

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

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

При внедрении СППР проектирование представляет собой двунаправленный итерационный процесс. Наиболее продуктивной нам представляется следующая последовательность проектирования аналитической системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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