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

Алекс Муасси

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

- Будут ли пользователи в организации довольны и смогут ли они найти ответы на свои вопросы?

- Смогут ли пользователи получить доступ ко всем источникам данных вашей компании?

- Способна ли ваша команда отдела информационного обеспечения оказывать поддержку среды DSS без затруднений и наиболее эффективным образом?

Недавнее исследование, проведенное Data Warehouse Institute, показало, что большинство организаций при реализации систем поддержки принятия решений не учитывают, что понадобится новый инструмент DSS через достаточно короткое время. Обзор показывает, что число пользователей удваивается каждые три месяца.

Рис.1 Интервал разочарования -следствие

ограничений на пользование отчетами

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

- читать существующие, заранее подготовленные отчеты (например, еженедельный отчет с последними данными о продажах);

- посылать запросы к корпоративным источникам данных, чтобы получить новые данные (объяснить, например, неожиданные отклонения в производительности);

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

- создавать свои собственные отчеты.

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

 

Удовлетворение потребностей пользователей в отчетах

Чтобы ваши пользователи были довольны своими отчетами, вы должны предоставить им следующие возможности.    

 

Простое создание мощных отчетов

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

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

 

Простое и мощное разделение и распределение отчетов

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

Выигрыш в производительности  -  одно из ключевых преимуществ корпоративной системы поддержки принятия решений. Чтобы достичь максимальной прибыли от вложений (ROI, Return On Investment), вам необходимо свести к минимуму общую стоимость владения.    

 

Простая персонализация отчетов

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

 

Удовлетворение потребностей пользователей в доступе к данным

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

Таким образом, если пользователи проводят 80% своего времени за чтением стандартных или персонализованных отчетов, вы обнаружите, что для выполнения 20% своих задач им требуется “сойти с пути” и получить дополнительные данные, недоступные из имеющихся отчетов. Чтобы удовлетворить этой потребности и избежать “интервала разочарования” (а также связанной с ним перегрузки отдела ИТ отчетами), вам необходимо выбрать корпоративный стандарт DSS, позволяющий пользователям самостоятельно делать специальные запросы к корпоративным источникам данных.

Многих менеджеров отдела ИТ пугает термин “специальный”. Он подразумевает непредсказуемые действия пользователя, а следовательно, и риск. Однако при использовании хорошего инструмента DSS “специальный” доступ к данным не должен быть связан с непредсказуемостью. Развитые инструменты DSS успешно сочетают автономию пользователя с контролем со стороны отдела ИТ, предоставляя:

- “семантическую прослойку”, позволяющую пользователям получать доступ к данным, используя бизнес-термины, что изолирует их от технических деталей базы данных;

- лимиты использования системы, ограничивающие время исполнения или величину пользовательских запросов и защищающие таким образом систему от нежелательных “гигантских” запросов;

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

 

Удовлетворение потребностей пользователей в анализе

Анализ (это слово произошло от греческих слов ana  - найти и lysis  -  решение) может означать разные вещи для различных пользователей, принимающих решения. Для читающего заранее подготовленный отчет анализ означает просто просмотр и сравнение элементов этого отчета. Если объем данных в отчете невелик, то лучший способ просмотреть их  -  табличный или кросстабличный (матричный) отчет. Заметьте, что, хотя сам отчет ограничен небольшим объемом данных, он генерируется в результате обращения к миллионам строк. Например, пользователю, принимающему решения, понадобился средний размер клиентских заказов за каждый из последних четырех кварталов. Если его компания работает с миллионами транзакций с заказчиками в течение каждого года, запрос пользователя (при условии соответствующей авторизации пользователя) может в действительности задействовать каждую транзакцию из этих миллионов, хранящихся в базе данных компании. В то же время на экране пользователя появятся только четыре значения, возвращенные запросом,  -  средний объем заказов за каждый квартал.

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

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

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

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

 

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

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

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

 

Потребность в специализации

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

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

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

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

 

Доступ ко всем источникам данных вашей компании

Чтобы принять инструмент DSS в качестве стандарта для вашей организации, вам необходимо решение, предоставляющее вашим пользователям доступ ко всем критическим источникам данных, как внутренним, так и внешним. Таким образом, от инструмента DSS потребуется доступ к реляционным, наследственным OLAP и персональным источникам данных, а также к информации в WWW. Стремительный рост WWW очень быстро превратил ее в бесценный источник внешней информации (например, о финансовом рынке, новостях производства, о заказчиках) для пользователей, принимающих решения.

Рис.2 Цикл деятельности пользователя

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

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

 

Выбор инструмента, которым просто управлять

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

Теперь перед вами возникают следующие задачи.

Защита корпоративных данных предполагает, что ваш стандартный инструмент DSS поддерживает три “А” безопасности: идентификацию, авторизацию и аудит (authentication, authorisation & auditing).

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

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

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

 

Кто же с этим может справиться?

Итак, после детального обсуждения всех проблем, с которыми могут столкнуться IT-менеджеры при развертывании корпоративной системы поддержки принятия решений, возникает очевидный вопрос: как с ними справиться и какие средства позволят не только создать DSS, но и поддерживать ее на протяжении жизненного цикла? Компания Business Objects в течение 10 лет разрабатывает средства построения DSS. Причем изначально они были ориентированы на крупных заказчиков. После выхода WebIntelligence в декабре 1997 г. компания смогла предоставить решения всех перечисленных выше в этой статье требований. Эта система имеет удобный пользовательский интерфейс и широкие возможности построения запроса, представления информации и анализа.

В России Business Objects представляет компания ТЕРН, телефон: (095) 928-6078.

Версия для печати