От пилотного проекта к корпоративному стандарту

Статья любезно предоставлена компанией Терн

Сопоставление систем поддержки принятия решений с нуждами предпринимательства

ВВЕДЕНИЕ

КАК УДОСТОВЕРИТЬСЯ, ЧТО ВСЕ ВАШИ ПОЛЬЗОВАТЕЛИ ДОВОЛЬНЫ
УДОВЛЕТВОРЕНИЕ ПОТРЕБНОСТЕЙ ПОЛЬЗОВАТЕЛЕЙ В ОТЧЕТАХ
  Простое создание мощных отчетов
  Простое и мощное разделение и распределение отчетов
  Простая персонализация отчетов

УДОВЛЕТВОРЕНИЕ ПОТРЕБНОСТЕЙ ПОЛЬЗОВАТЕЛЕЙ В ДОСТУПЕ К ДАННЫМ
Автономный доступ к данным с использованием знакомых бизнес-терминов

УДОВЛЕТВОРЕНИЕ ПОТРЕБНОСТЕЙ ПОЛЬЗОВАТЕЛЕЙ В АНАЛИЗЕ
Необходимость интеграции средств построения запросов, отчетов и анализа

ПОТРЕБНОСТЬ В СПЕЦИАЛИЗАЦИИ

Продолжение...

Введение

Как менеджер MIS, вы имеете хороший повод для праздника. Вы только что завершили развёртывание вашей новой системы поддержки принятия решений (DSS - Decision Support System) на десять членов отделения маркетинга и конечные пользователи довольны. Наконец-то у них есть прямой доступ к информации по продажам компании. Новый инструмент DSS предоставляет им доступ к данным по продажам продукта по всему миру, собранным в новом хранилище данных предприятия.

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

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

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

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

Как удостовериться, что все ваши пользователи довольны

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

Рисунок 1. Внутренняя потребность в инструменте DSS может нарастать взрывообразно. По мере того, как пользователи обнаруживают в организации других пользователей, пользующихся "крутым" инструментом доступа к данным, отделение IS оказывается просто заваленным требованиями этого инструмента.

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

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

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

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

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

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

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

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

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

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

• Простое создание мощных отчетов.
• Простое и мощное разделение и распределение отчетов.
• Простая персонализация отчетов.
• Простой анализ и расширение данных в отчетах.

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

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

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

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

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

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

Чтобы указать категории данных, которые нужно включить в отчет, пользователи работают со знакомыми им деловыми терминами, что полностью изолирует их от технической сложности структуры базы данных и языков программирования, таких, как структурированный язык запросов (SQL -Structured Query Language). Пользователи могут составлять свои отчеты с "полностью клиентской" PC-системы или, при помощи WebIntelligence, непосредственно из web-браузера.

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

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

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

Рисунок 3. Document Agent Server позволяет пользователям управлять расписанием автоматического обновления, распределения и публикации в web своих отчетов, причем вся обработка происходит на выделенной системе "back-end". Пользователи могут назначать свои отчеты на отложенное выполнение, что означает, что по мере расширения использования решения DSS в вашей организации персонал MIS не будет перегружен требованиями пользователей.

Организации, выбравшие для себя BusinessObjects в качестве стандарта систем поддержки принятия решений, используют Document Agent Server для автоматизации обновления, распределения и публикации в web своих отчетов (рисунок 3). Программное обеспечение Document Agent Server обычно работает на выделенной серверной системе back-end и обрабатывает отложенные на автоматическое выполнение отчеты.

Расписание для отложенного выполнения составляется самими пользователями, так что команда MIS не перегружается запросами и не превращается в "узкое место". Так как отчеты обрабатываются на сервере back-end, машины пользователей не обременены обработкой отчетов. Даже если пользователи BusinessObjects не имеют доступа к Document Agent Server, они могут обмениваться отчетами (с использованием соответствующей авторизации) посредством обычного "репозитория документов" в базе данных, через сервер файлов, через электронную почту и через world wide web.

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

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

• Приглашения в отчетах - Стандартный отчет, созданный по принципу "один подходит всем" и рассылаемый многим пользователям является выгодным по стоимости способом "проталкивания" информации пользователям. Однако вместе с данными команда MIS, построившая этот отчет, также "проталкивает" дополнительную работу пользователям. Если пользователям понадобится просмотреть лишь часть данных, им самим придется провести работу по определению этой части. Возьмите в качестве примера компанию, производящую сотни продуктов. Для такой компании отчет по менеджменту для одного продукта, охватывающий недельную статистику продаж каждого продукта по географическим регионам, даст команде менеджмента по продукту информацию по всем продуктам компании. При отсутствии более важной информации менеджеры по продукту поначалу будут довольны. Однако, отсеивая нужную информации из огромного числа строк ненужных данных по другим продуктам из недели в неделю, они начнут жаловаться, требуя приспособленного под них внешнего вида данных, специфичных для их продукта. Отчет, построенный с использованием приглашений, является выгодным по цене способом сохранить единый корпоративный стандарт отчета, позволяя в то же время менеджерам по продуктам легко отфильтровывать необходимые данные, которые они хотят просмотреть (в данном случае, по своему продукту). Вводя в приглашении названия продуктов, каждый менеджер сможет просмотреть отчет, содержащий только информацию по интересующим его продуктам.
• Отчеты на основе профиля безопасности - Запрашивая от пользователя фильтр, как в приведенном выше случае, группа MIS может соблюдать баланс между двойной потребностью в стандартном отчете и в персоналзованном отчете. Однако во многих случаях по соображениям безопасности фильтрация данных должна проводиться группой MIS, а не пользователем. Эффективный по цене способ решить эту проблему - создание единого стандартного отчета и использование профиля безопасности каждого пользователя для фильтрации данных, отображаемых в отчете. На основе профиля безопасности, установленного для каждого отдельного пользователя BusinessObjects, различные пользователи могут запускать один и тот же отчет, но видеть только те данные, к которым им разрешен доступ.
• Изменяемые отчеты - Получив соответствующую авторизацию от группы MIS, отдельные пользователи BusinessObjects могут не только модифицировать свои отчеты, но и изменять их целиком. Как будет обсуждаться ниже более детально, BusinessObjects позволяет пользователю очень просто модифицировать существующий отчет, изменяя его формат (например, превращая таблицу в график), добавляя в отчет или удаляя из отчета категории данных, объединяя данные из различных источников или добавляя вычисления.

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

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

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

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

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

Многих менеджеров IS пугает термин "специальный". Он подразумевает непредсказуемые действия пользователя, а следовательно, и риск. Однако при использовании хорошего инструмента DSS "специальный" доступ к данным не должен быть связан с непредсказуемостью для IS. Развитые инструменты DSS, такие, как BusinessObjects, успешно сочетают автономию пользователя с контролем MIS, предоставляя следующие возможности:

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

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

Если вы когда-нибудь участвовали в разработке корпоративной базы данных, рынка данных или хранилища данных, или вам приходилось "бороться" с SQL, то вы наверняка знаете, что типичная среда корпоративной базы данных далека от понимания конечным пользователем. Таблицы и столбцы редко называются понятными для пользователя названиями, гораздо чаще используются эзотерические термины типа PID, S001, KNA1, TVKOT, TVTWT, TSPAT, MAKT и т.д. Даже в том случае, если хранилище данных разрабатывалось специально для доступа к нему конечных пользователей, названия таблиц и столбцов скорее соответствуют стандарту разработки MIS, нежели понятны для конечного пользователя. Более того, правильный способ сочетания элементов данных в запросе, составляемом конечным пользователем и взаимосвязь между таблицами также не очевидны. Наконец, некоторые из деловых показателей, которые конечный пользователь хотел бы просмотреть (например, средний объем заказов за месяц), недоступны напрямую и должны быть вычислены, исходя из элементов базы данных.

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

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

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

• "Семантически динамические" объекты - Для формулирования запроса информации из базы данных пользователь BusinessObjects может комбинировать знакомые термины, такие, как "Название Продукта", "Год" и "Доход" (в таком случае он или она получит отчет, показывающий доход по названию продукта и по году). Если пользователь скомбинирует "Название Продукта" с "Регионом" и "Доходом", он или она получит отчет, показывающий доход по названию продукта и по региону. Для каждого из запросов бизнес-индикатор "доход" имеет различное значение (годовой доход по продукту в первом случе и региональный доход - во втором) и отображает данные из различных частей базы данных. "Семантически динамическая" технология запросов BusinessObjects гарантирует правильную интерпретацию запроса пользователя и возвращение из базы соответствующих данных. Эта уникальная возможность BusinessObjects определять контекст пользовательского запроса и формулировать соответствующий запрос к базе данных дает пользователям возможность просто и самостоятельно получать доступ к базе данных и освобождает вашу команду MIS от повторяющихся просьб пользователей о поддержке.
• Вычисленные данные - Кроме изолирования пользователей от сложности структуры вашей базы данных, вам потребуется предоставить пользователям доступ к элементам, которые хотя и доступны из данных, не находятся в базе в явном виде. Например, хотя ваша база данных может накапливать данные по заказам каждого клиента (имя клиента, заказанные продукты и их количество, дата, поштучная цена и т.д.), средний объем сделок за определенный период времени может не быть доступным конечным пользователям в явном виде, хотя он может быть легко получен, если пользователь перенесет всю информацию по заказам в электронную таблицу. Другими примерами деловых показателей, недоступных в явном виде в базе данных, являются показатели квартального или годового роста дохода, измерения годовых расходов и бизнес-показатели, такие, как доход на сотрудника или число транзакций на продавца. BusinessObjects сочетают в себе легкий доступ к корпоративным данным с гибкостью электронных таблиц, позволяя пользователям включать в отчеты такие обычные деловые показатели.

Рисунок 5. BusinessObjects предоставляют конечным пользователям автономный доступ к данным. Для создания отчета пользователи просто перетаскивают знакомые деловые показатели в "панель запросов".

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

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

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

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

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

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

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

BusinessObjects предоставляет вам весь спектр аналитических возможностей, которые понадобятся вам для удовлетворения любых аналитических требований к DSS в вашей организации. BusinessObjects предоставляет это решение посредством поддержки множества форматов отображения данных, сложных вычислений для манипуляций с данными, операции свертывания/разворачивания для временного скрытия частей отчета, анализ OLAP для навигации в данных (с модулем Explorer), и "бурение" данных (с модулем BusinessMiner). Более того, BusinessObjects позволяет пользователям анализировать данные непосредственно в отчете, что обусловлено интеграцией аналитических возможностей с построением отчетов и запросов. И, наконец, BusinessQuery для Excel позволяет пользователям, предпочитающим проводить анализ (в частности, прогнозирование) в электронных таблицах, получать доступ к базе данных напрямую из MS Excel.

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

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

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

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

1. Пользователь просматривает заранее подготовленный отчет (например, отчет по доходу за продукт по странам за текущую неделю).
2. Пользователь анализирует данные в отчете, просматривая из в различных перспективах (гиперкуб) или на разных уровнях детализации (детализация). Если взять пример менеджмента продуктов, рассматривавшийся выше, пользователь может пожелать просмотреть "кусок", представляющий доход за продукт в зависимости от цвета продукта или "провести детализацию" для просмотра дохода за продукт по городам.
3. Пользовательский анализ может также включать в себя автоматический поиск структур данных в базе с использованием новейшего компонента деловых решений DSS - "бурения" данных.
4. В процессе анализа пользователь может обнаружить, что для ответа на важный вопрос по данным необходимо получить дополнительную информацию из базы данных. Например, пользователю может понадобиться сравнить доход за текущую неделю с доходом за предыдущие четыре недели.
5. Разместив новые данные в отчете, пользователь может продолжать анализ.
6. Когда анализ завершен, пользователь может подвести итоги с помощью ряда модифицированных отчетов (или "снимков" анализа), разослав их другим пользователям для поддержки решения или планирования.

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

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

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

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

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

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

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

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

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

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

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

Продолжение...