OLAP.ru   Rambler's Top100
Вы находитесь на страницах старой версии сайта. Перейдите на новую версию OLAP.ru
  
Поиск по сайту
Новости
Основы OLAP
Продукты
Business Objects/ Crystal Decisions
Каталог
OLAP в жизни
Тенденции
Download
Яndex
 
 
 
TopList
 
 Business Objects/Crystal Decisions  Oracle  Microsoft  IBM 
 Hyperion  Sybase  Informix  Actuate  SAS Institute  Brio 

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

Alex Moissis, Business Objects

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


Введение

Как менеджер 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. Исследования показали, что такой подход “купи и создай” гораздо эффективнее по цене, чем традиционный метод “написания с нуля”.

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

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

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

Доступ к хранилищам данных и рынкам данных

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

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

  • Существующий дизайн базы данных, или “схему”.
  • Присутствие “агрегатных”, или сводных таблиц.
  • Информацию по настройке хранилища или рынков данных, или “метаданные”.

Работа с вашей схемой разработки базы данных

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

Важность агрегатной осведомленности

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

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

Использование имеющихся метаданных

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

Доступ к данным готовых приложений

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

При стандартизации на предприятиях готовых приложений от SAP, Oracle или PeopleSoft, отделения IS этих предприятий сталкиваются с затруднениями при выполнении пользовательских требований отчетов по данным этих приложений. Конечные пользователи, знающие о существовании готовых приложений, ищут доступ к богатому хранилищу корпоративных данных, охватываемому этими приложениями. Таким образом отделения IS оказываются перегруженными требованиями отчетов в условиях недостатка инструментов и ресурсов для удовлетворения этих требований.

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

Готовые приложения обычно работают со сложными структурами данных. Для ускорения вашей задачи установки среды поддержки принятия решений, которая имеет доступ к этим сложным структурам данных, BusinessObjects выпускает Rapid Deployment Templates (RDT) для ведущих поставщиков приложений, включая SAP, Oracle и PeopleSoft. RDT уменьшает время развертывания от нескольких недель до нескольких дней, позволяя вам предоставить пользователям систему поддержки принятия решений гораздо быстрее. Поскольку отчет BusinessObjects может содержать в себе данные из разных источников, пользователи могут комбинировать данные из различных готовых приложений для увеличения мощности системы поддержки принятия решений в вашей организации.

Использование оперативных данных в “виртуальном” рынке данных

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

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

BusinessObjects Document Agent Server идеален для создания такого “виртуального” рынка данных. Сервер может быть быстро настроен, получать необходимые данные и строить предопределенные пользовательские отчеты. Отчеты при этом автоматически рассылаются пользователям BusinessObjects. И, конечно, поскольку BusinessObjects интегрирует построение отчетов с анализом, получатели этих отчетов смогут пользоваться операциями 2гиперкуба” и “детализации” непосредственно из отчета.

Поддержка серверов OLAP

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

BusinessObjects уже поддерживают несколько серверов OLAP, включая Oracle Express, Arbor Essbase и Informix Metacube, в планы также входит поддержка многомерных сред Microsoft (проект Plato) и SAP (BIW).

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

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

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

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

Защита ресурсов

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

Идентификация

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

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

Авторизация

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

Ревизирование

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

BusinessObjects предоставляют поддержку всех трех “А” безопасности - идентификации, авторизации и ревизирования, - необходимых для организационного стандорта. Этот инструмент дает вам возможность управления существующими системами паролей, такими, как идентификационный механизм операционной системы NT. Ресурсы защищаются посредством назначения предметных областей (юниверсов), деловых показателей (объектов) и даже строк базы данных, к которым пользователь имеет доступ. Информация по безопасности BusinessObjects, которая находится в центральном “репозитории”, позволяет разрешить или запретить пользователю изменение отчета, запроса или базы данных, а также проведение анализа OLAP. Наконец, администраторы могут создавать скрипты для ревизирования действий пользователей.

Уменьшение сложности

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

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

BusinessObjects предлагает ряд инструментов для администрирования DSS в масштабах предприятия, разработанных для облегчения ваших задач. BusinessObjects Supervisor управляет пользователями и ресурсами, позволяя вам определять права пользователей и групп, пользуясь графическим интерфейсом (рисунок 8).

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

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

Для рационализации координирования рапределения отчетов BusinessObjects выпустили Document Agent Server. Document Agent Server обеспечивает обновление и распределение отчетов на основе расписания, или оповещать пользователей об изменении важных деловых показателей. Поскольку теперь конечные пользователи могут самостоятельно определять расписание обновления своих отчетов, ваш персонал освобождается от нагрузки по требованиям пользователями отчетов, упрощая таким образом вашу задачу администрирования.

Наконец, для минимизирования сложности доступа к готовым приложениям BusinessObjects предлагает интерфейси для приложений, или Rapid Deployment Templates (RDT).

Использование преимуществ технологии “нулевого администрирования клиентов”

Скорость развития world wide web в конце девяностых достигла бешеного темпа, в котором предприятия занимаются бизнесом. Web - не только важнейший источник деловой информации, но и механизм коммуникации для деловых партнеров, разделения информации о продуктах - для заказчиков и продажи продуктов и услуг - для производителей. Если вы решили не следовать общему порыву (и, возможно, давлению со стороны высшей администрации) и еще не развернули в web деловых приложений, очень велик шанс того, что вы в скором времени это сделаете. Следовательно, вы должны удедиться, что ваш поставщик DSS предлагает хорошие предложения в web.

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

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

BusinessObjects быстро отреагировали на появление возможности использования world wide web и приняли ряд решений. В 1996, опередив многих конкурентов, компания уже дала пользователям BusinessObjects возможность публиковать свои отчеты в web. В 1997 она выпустила WebIntelligence, настоящее приложение web с архитектурой “тонкого” клиента. Подобно сочетанию клиент/сервер, WebIntelligence позволяет пользователям получать доступ к данным и строить отчеты, пользуясь знакомыми деловыми терминами. Его “архитектура распределенных компонентов” позволяет добиться высоких доступности и производительности, необходимых приложению, к которому имеет доступ большое число пользователей. WebIntelligence использует настроечную информацию BusinessObjects (семантическую прослойку и профили безопасности), что означает, что вы можете быстро и недорого создать среду поддержки принятия решений, которая включает в себя пользователей как приложений клиент/сервер, так и web. Поскольку вы, по всей вероятности, не планируете перенести всю вашу деловую оболочку в web за короткий промежуток времени, это сосуществование и постепенный переход весьма важны для успеха ваших усилий по развертыванию.

Инструмент - это лишь часть решения

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

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

Cкачать статью в .pdf формате

 Обсудить на форуме   Написать вебмастеру 

© 2001 Interface Ltd