API-интерфейсы и влияние XML

Некоторые платформы OLAP и добычи данных предлагают API-интерфейсы, которые позволяют аналитикам создавать собственные решения. Однако поставщики решений, как правило, вынуждены писать специальные программы для различных платформ, чтобы предоставить не зависящее от платформ решение. Новые ориентированные на XML службы на базе Web обеспечивают общий интерфейс для механизмов OLAP. Компании Microsoft и Hyperion опубликовали XML for Analysis (), API-интерфейс, основанный на протоколе SOAP, предназначенный специально для стандартизации взаимодействий при доступе к данным между клиентским приложением и источником данных, работающими через Web. На основе этой XML-спецификации поставщики решений смогут писать программы с помощью одного API-интерфейса, а не использовать множество интерфейсов, ориентированных на решения разных производителей.

Архитектуры OLAP-серверов

Традиционные реляционные серверы не обеспечивают эффективное выполнение сложных OLAP-запросов и поддержку многомерных представлений данных. Но, тем не менее, три типа реляционных серверов баз данных — реляционной, многомерной и гибридной оперативной аналитической обработки — позволяют выполнять OLAP-операции в хранилищах данных, построенных с использованием систем управления реляционными базами данных.
Серверы ROLAP. Размещаются между основным реляционным сервером, где находится хранилище данных и клиентским инструментарием переднего плана. Серверы ROLAP поддерживают многомерные OLAP-запросы и, как правило, оптимизированы для конкретных реляционных серверов. Они указывают, какие представления должны быть материализованы, возможные запросы пользователей в терминах соответствующих материализованных представлений, и генерируют сложные SQL-серверы для основного сервера. Они также предусматривают дополнительные службы, такие как планирование запросов и распределение ресурсов. Серверы ROLAP наследуют возможности масштабирования и работы с транзакциями реляционных систем, однако существенные различия между запросами в стиле OLAP и SQL могут стать причиной низкой производительности.
Нехватка производительности становится менее острой, благодаря ориентированным на задачи OLAP расширениям SQL, реализованным в серверах реляционных баз данных наподобие Oracle, IBM DB2 и Microsoft SQL Server. Такие функции, как median, mode, rank, percentile дополняют агрегатные функции. К другим дополнительным возможностям относятся агрегатные вычисления на перемещающихся окнах, текущие сводные значения и точки прерывания для улучшенной поддержки формирования отчетов.
Многомерные электронные таблицы требуют группировки по различным наборам атрибутов. Для того чтобы удовлетворить эти требования Джим Грей и его коллеги [2] предлагают расширить SQL двумя операторами — roll-up и cube. Свертка списка атрибутов, включающего продукт, год и город, помогает находить ответы на вопросы, в которых фигурируют:

группировка по продуктам, годам и городам;

группировка по продуктам и годам;

группировка по продуктам.

Пусть дан список из k столбцов, оператор cube предлагает группировку по каждой из 2**k комбинаций столбцов. Многочисленные операции «group by» могут быть выполнены эффективно за счет распознавания общих частей вычислений [3]. Разумно подобранные предварительные вычисления могут увеличить производительность серверов OLAP [4].

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

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

Добыча данных в Web

Большинство крупных компаний поддерживают Web-сайты, где клиенты могут просмотреть информацию, запросить данные о товарах и приобрести их. Поскольку каждый клиент имеет личный контакт с компанией через Web-сайт, компании могут персонифицировать работу с ним. Например, сайт может рекомендовать клиенту продукты, услуги или статьи, относящиеся к области его интересов. Одной из первых такие персонифицированные системы начала развертывать компания Amazon.com.
При создании таких Web-систем возникают два важных вопроса: сбор данных и методы персонификации. Анализ данных регистрации, автоматически накапливаемых данных о поведении клиента на Web-сайте, позволяет выявить привычки предпочтения клиентов. Анализ такого рода позволит FSC предложить специальные спортивные носки клиентам, покупающим обувь. Модели добычи данных могут использовать подобную информацию о поведении клиента, особенно, когда она сочетается с данными, которые клиенты вводят при регистрации или оплате, чтобы персонифицировать посещаемые клиентами Web-страницы и снабдить их соответствующей рекламой. Со временем, по мере роста числа пользователей, компания может рекомендовать дополнительные продукты, учитывая схожесть предпочтений клиентов.

Добыча данных

Предположим, что FSC хочет начать кампанию по рассылке каталогов, на которую отводится бюджет не более 1 млн. долл. Учитывая это ограничение, аналитики отдела маркетинга хотят определить круг клиентов, которые, вероятнее всего, отреагируют на эту акцию и начнут делать покупки по каталогу. Инструментарий добычи данных предлагает необходимые для этого функции прогнозирования и анализа за счет определения шаблонов и характеристического поведения в пределах набора данных.
Обнаружение знаний (knowledge discovery) — процесс определения и достижения цели посредством итеративной добычи данных — как правило, состоит из трех этапов:

подготовка данных;

построение модели и ее оценка;

применение модели.

Дополнительные факторы при оценке моделей

Не существует одного класса моделей или алгоритма, которые позволили бы в любом случае создать идеальную модель для всех приложений. В силу этого платформы добычи данных должны поддерживать несколько типов построения моделей и предоставлять дополнительные средства для обеспечения расширяемости моделей и взаимодействия между ними.
В некоторых случаях аналитикам может потребоваться уникальная корреляционная модель, которую не поддерживает платформа добычи данных. Для этого платформы добычи данных должны быть расширяемыми.
Многие коммерческие продукты создают модели для конкретных областей применения, но реальная база данных, на которой должна применяться такая модель, возможно, будет работать с другим сервером баз данных. Платформы добычи данных и серверы баз данных, таким образом, должны поддерживать взаимозаменяемость моделей.
Недавно рабочая группа Data Mining Group () предложила воспользоваться Predictive Model Markup Language, стандартом на базе XML, для обмена рядом популярных классов моделей прогнозирования. Идея состоит в том, чтобы любая база данных, поддерживающая этот язык, могла импортировать и применять любую описанную на нем модель.

Дополнительные вопросы OLAP и добычи данных

К другим важным вопросам в контексте OLAP и технологии добычи данных относятся пакетные приложения, платформы и их API-интерфейсы, влияние XML, приближенная обработка запросов, интеграция OLAP и добычи данных, а также добыча данных в Web.

Физическая архитектура базы данных

Системы баз данных используют избыточные структуры, такие как индексы и материализованные представления для эффективной обработки сложных запросов. Определение самого подходящего набора индексов и представлений — это сложная задача формирования физической архитектуры. Хотя поиск в индексе и сканирование индекса могут быть эффективны для запросов, связанных с выбором данных, запросы, предполагающие интенсивную обработку данных, могут потребовать последовательного сканирования всей реляционной таблицы или ее вертикальных фрагментов. Увеличение эффективности сканирования таблиц и использование распараллеливания для уменьшения времени ответа на запрос — важные моменты, которые следует учитывать при проектировании физической архитектуры [1].

Хранилище данных

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

Индексные структуры

Методы обработки запросов, которые используют операции пересечения и объединения индексов, полезны при ответе на запросы с множественными предикатами. Пересечение индексов используется при выборке по нескольким условиям и может значительно снизить необходимость (или вообще устранить ее) в доступе к базовым таблицам, если все столбцы проекции можно получить посредством сканирования индексов.
Благодаря особой природе «звезды» соединение индексов детальных данных особенно удобно для систем поддержки принятия решений. Хотя индексы традиционно устанавливают соответствие значения в столбце списку строк с этим значением, соединенный индекс поддерживает связь между внешним ключом и соответствующими ему первичными ключами. В контексте схемы «звезда» соединенный индекс может связать значения одного или нескольких столбцов таблицы измерений с соответствующими строками таблицы фактов. Схема на рис. 2, к примеру, может поддерживать соединенный индекс по атрибуту «Город», который каждому городу ставит в соответствие список идентификаторов тех кортежей в таблице фактов, которые описывают продажи в данном городе. Важно подчеркнуть, что соединенный индекс предварительно вычисляет бинарное соединение.
Соединенные индексы по нескольким ключам могут представлять предварительно вычисленные n–кратные соединения. Например, многомерный соединенный индекс, созданный на основе базы данных продаж, может соединять Город.Название Города и Продукт.Название в таблице фактов. Элемент индекса для (Сиэтл, Running Shoe) указывает на идентификаторы записей в кортежах таблицы «Продажи» с такой комбинацией.

Инструментарий хранилищ данных

Создание хранилища данных из независимых источников данных — многоэтапный процесс, который предусматривает извлечение данных из каждого источника, преобразование их в соответствии со схемой хранилища данных, очистку, а затем загрузку в хранилище. Data Warehousing Information Center опубликовал обширный список инструментальных средств ETL (extract, transform, load — «извлечение, преобразование, загрузка»), выполняющих эту последовательность операций.

Интеграция OLAP и добычи данных

OLAP-инструментарий помогает аналитикам выявить актуальные порции данных, а модели добычи данных обогащают эту функциональность. Например, если темпы роста объема продаж FSC не соответствуют прогнозируемым, специалисты по маркетингу хотели бы знать аномальные регионы и категории продуктов, для которых не выполняются заданные показатели. Пробный анализ, который выявляет аномалии, использует методику, позволяющую отметить агрегатный параметр на более высоком уровне в иерархии измерений с аномальным результатом. Аномальный результат определяет общее отклонение реальных агрегатных величин от соответствующих прогнозируемых значений над всеми своими потомками [8, 9]. Для вычисления прогнозируемых значений аналитики могут использовать такие средства добычи данных, как регрессионные модели.

Извлечение и преобразование

Цель этапа извлечения данных — перенести данные из разнородных источников в базу данных, где их можно модифицировать и добавить в хранилище. Цель последующего этапа преобразования данных — устранить несоответствия в схеме и соглашениях о значениях атрибутов. Набор правил и скриптов, как правило, выполняет преобразование данных из исходной схемы в итоговую схему.
К примеру, дистрибьютор может разделить имя каждого клиента на три части: имя, отчество (или инициалы) и фамилия. Чтобы добавить предоставленную дистрибьютором информацию о продажах в хранилище FSC, схема которого показана на рис. 2, аналитик сначала должен извлечь записи, а затем, для каждой записи, преобразовать все столбцы с соответствующими тремя частями имени, чтобы получить значение для атрибута «Имя клиента».

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

Система поддержки принятия решений — сложная структура с многочисленными компонентами. Рассмотрим гипотетическую компанию Footwear Sellers Company, которая производит обувь и предлагает ее покупателям по каналам прямых продаж и через реселлеров. Руководителям отдела маркетинга FSC необходимо извлечь следующую информацию из агрегированных бизнес-данных:

пять штатов, сообщивших о самых больших за последний год темпах роста объема продаж в категории продуктов для молодежи;

общий объем продаж обуви в Нью-Йорке за последний месяц по различным видам продуктов;

50 городов с самым большим количеством индивидуальных клиентов;

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

какие данные накапливать и как на концептуальном уровне моделировать данные и управлять их хранением;

как анализировать данные;

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


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

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

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

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

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

Концептуальная модель данных

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


Рис. 3. Пример многомерной базы данных

В многомерном представлении данных запросы drill-down и roll-up — это логические операции на кубе. Еще одна популярная операция — сравнить два параметра, которые агрегированы по одним и тем же измерениям, такими как продажи и бюджет.
OLAP-анализ может включать в себя более сложные статистические вычисления, нежели простые агрегаты, такие как сумма или среднее. Примером может служить такая функция, как изменение процента агрегата в определенный период по сравнению с различными периодами времени. Подобные дополнительные функции поддерживают многие коммерческие средства OLAP.
Измерение «Время» имеет особое значение для таких процессов поддержки принятия решений, как анализ тенденций. К примеру, аналитикам FSC может понадобиться проследить покупательскую активность в отношении спортивной обуви перед крупнейшими национальными легкоатлетическими соревнованиями или после них. Развернутый анализ тенденций возможен, если база данных поддерживает встроенную информацию о календаре и ряд других характеристик «Времени». OLAP Council () определил перечень операций для многомерных кубов.

Литература

T. Barclay et al., «Loading Databases Using Dataflow Parallelism», SIGMOD Record, Dec. 1994
J. Gray et al., «Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub Totals», Data Mining and Knowledge Discovery J., Apr. 1997
S. Agrawal et al., «On the Computation of Multidimensional Aggregates», Proc. VLDB Conf., Morgan Kaufmann, San Francisco, 1996
V. Harinarayan, A. Rajaraman, J.D. Ullman, «Implementing Data Cubes Efficiently», Proc. SIGMOD Conf., ACM Press, New York, 1996
L. Breiman et al., Classification and Regression Trees, Chapman & Hall/CRC, Boca Raton, Fla., 1984
V. Ganti, J. Gehrke, R. Ramakrishnan, «Mining Very Large Data Sets», Computer, Aug. 1999
J. Han, M. Kamber, Data Mining: Concepts and Techniques, Morgan Kaufmann, San Francisco, 2001
S. Sarawagi, «User Adaptive Exploration of OLAP Data Cubes», Proc. VLDB Conf., Morgan Kaufmann, San Francisco, 2000
J. Han, «OLAP Mining: An Integration of OLAP with Data Mining», Proc. IFIP Conf. Data Semantics, Chapman & Hall/CRC, Boca Raton, Fla., 1997
M. Hernandez, S. Stolfo, «The Merge/Purge Problem for Large Databases», Proc. SIGMOD Conf., ACM Press, New York, 1995
H. Galhardas et al., «Declarative Data Cleaning: Model, Language, and Algorithms,» Proc. VLDB Conf., Morgan Kaufmann, San Francisco, 2001

Сураджит Чаудхури () — ведущий научный сотрудник и менеджер группы Data Management, Exploration, and Mining Group исследовательского подразделения Microsoft Research. К области его научных интересов относятся самонастраивающиеся системы управления базами данных, системы поддержки принятия решений, а также интеграция текстовой, реляционной и полуструктурированной информации.
Умешвар Дайал () — старший научный сотрудник лаборатории Hewlett-Packard Laboratories. Он занимается вопросами добычи данных, управления бизнес-процессами, управления распределенной информацией и технологий поддержки принятия решений, особенно в применении к электронному бизнесу.
Венкатеш Ганти () — научный сотрудник группы Data Management, Exploration, and Mining Group исследовательского подразделения Microsoft Research. К области его научных интересов относятся добыча данных и мониторинг больших эволюционирующих множеств данных, а также системы поддержки принятия решений.
Модели добычи данных могут использовать накопленную информацию о поведении клиента для того, чтобы выполнять персонификацию Web-страниц, которые видит клиент.
Специальные решения для конкретных отраслей ограничены по своим функциям, и они не могут удовлетворить все требования к анализу, выдвигаемые предприятием по мере развития его бизнеса.
Требуется еще немало сделать для создания не зависящих от конкретной предметной области инструментальных средств, которые решают проблемы очистки данных, связанные с развитием хранилищ данных.
Surajit Chaudhuri, Umeshwar Dayal, Venkatesh Ganti, Database Technology for Decision Support Systems. IEEE Computer, December 2001. Copyright IEEE Computer Society, 2001. All rights reserved. Reprinted with permission.

Логическая архитектура базы данных

В архитектуре, основанной на схеме «звезда», база данных состоит из таблицы фактов, которая описывает все транзакции, и таблицы измерений для каждой из сущностей. В примере с FSC каждая транзакция охватывает несколько сущностей — клиент, продавец, продукт, заказ, дата сделки и город, где сделка состоялась. Каждая сделка также имеет параметры — в нашем случае число проданных экземпляров продукта и общая сумма, которую заплатил покупатель.
Каждый кортеж в таблице фактов состоит из указателя на каждый объект в транзакции и численные параметры, связанные с транзакцией. Каждая таблица измерений состоит из столбцов, которые соответствуют атрибутам объекта. Вычисление соединения между таблицей фактов и набором таблиц измерений — более эффективная операция, чем вычисление соединения произвольных реляционных таблиц.
Некоторые сущности, однако, связаны в иерархии, которые схема «звезда» корректно не поддерживает. Иерархия — это многоуровневая группировка, каждый уровень которой состоит из непересекающихся групп значений уровня, находящегося непосредственно ниже данного. Так, все продукты могут группироваться в непересекающееся множество категорий, которые, в свою очередь, сгруппированы в непересекающееся множество семейств.
Схема «снежинка» — усовершенствованная схема «звезда», в которой иерархия измерений представляется точным образом благодаря нормализации таблиц измерений. В «звезде», приведенной на рис. 2, набор атрибутов описывает каждое измерение и может быть связан иерархией отношений. Например, измерение продукта FSC состоит из пяти атрибутов: имя продукта (Running Shoe 2000), категория (спортивная), семейство продуктов (обувь), цена (80 долл.) и маржа (80%).


Рис. 2. Схема «снежинка» для гипотетической компании Footwear Sellers Company. Набор атрибутов описывает каждое измерение и связывается через иерархию отношений.

Материализованные представления

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

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

использование материализованных представлений для ответа на запросы;

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

Обновление

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

Очистка данных

Ошибки при вводе данных и различия в схемах могут привести к тому, что таблица измерений «Клиент» будет иметь несколько соответствующих кортежей для одного клиента, что приводит к неточным ответам на запросы и некорректным моделям добычи данных. К примеру, если таблица клиентов содержит по несколько кортежей для некоторых клиентов FSC в Нью-Йорке, то Нью-Йорк может ошибочно попасть в список первых 50 стран с самым большим числом индивидуальных клиентов. Инструменты, которые помогают определить и исправить аномалии данных, могут иметь высокую отдачу; значительное число исследований посвящено проблемам устранения дублирования [10] и инструментам очистки данных [11].

Оперативные аналитические приложения

В типичном оперативном аналитическом приложении запрос агрегирует численные параметры более высоких уровней в иерархию измерений. Пример — первый маркетинговый запрос FSC, для выполнения которого необходим набор агрегированных параметров — пять штатов, сообщивших о самом большом увеличении объема продаж в категории молодежных продуктов за последний год. «Штат» и «Год» — обобщения сущностей «Город» и «Дата».
Применительно к хранилищу данных FSC типичный сеанс OLAP, необходимый для определения региональных объемов продаж спортивной обуви в прошлом квартале, может выглядеть следующим образом.

Аналитик выдает запрос select sum(sales) group by country («суммарный объем продаж для каждой страны»), чтобы просмотреть распределение объемов продаж спортивной обуви в последнем квартале по всем странам.

После выбора страны с самым высоким или самым низким объемом продаж относительно размеров рынка, аналитик выдает второй запрос на вычисление сводного объема продаж в каждом штате данной страны, чтобы понять причины таких отклонений.
Аналитик движется вниз по иерархии, связанной с измерением «Город». Такой анализ сверху вниз по иерархии от самого обобщенного до самого детального уровня называется уточненным (drill-down). При операции обобщения (roll-up) аналитик поднимается на один уровень — скажем, от уровня штата до уровня страны — в иерархии измерений.
Ключевые вопросы, касающиеся OLAP, связаны с концептуальной моделью данных и серверными архитектурами.

Пакетные приложения

При разработке полного решения добычи данных аналитик должен выполнить серию сложных запросов и создать, настроить и применить сложные модели. Компенсировать разрыв между требованиями реального решения для хорошо понятных областей и поддержкой данной платформы добычи данных или OLAP, призваны несколько коммерческих инструментальных средств. Пакетные приложения и средства формирования отчетов могут использовать знания о конкретной вертикальной отрасли для упрощения задачи анализа путем учета специфических для отрасли абстракций более высокого уровня. Data Warehousing Information Center () и KDnuggets () предлагают обширный список решений, ориентированных на конкретные отрасли.
Компании могут приобрести такие пакеты, а не разрабатывать свое собственное аналитическое решение, но пакеты, ориентированные на конкретную область применения, меняющиеся по мере развития бизнеса, ограничены по набору своих функций и потому не могут удовлетворить все потенциальные требования к анализу.

Подготовка данных

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

Построение и оценка моделей

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

Приближенная обработка запросов

Обработка сложных агрегатных запросов, как правило, требует обращения к огромным объемам данных. Например, вычисление среднего объема продаж FSC в различных городах требует сканирования всех данных в хранилище. Во многих случаях, однако, очень быстро и достаточно точную оценку позволяет получить приближенная обработка запросов. Идея состоит в том, чтобы на основе базовых данных максимально точно сформировать сводные данные, а затем получать ответы на агрегатные запросы с помощью этих сводных, а не полных данных. Дополнительную информацию по этому вопросу можно найти в описании проектов Approximate Query Processing () и AQUA Project ().

Применение модели

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

Технология баз данных в системах поддержки принятия решений

Сураджит Чаудхури, Умешвар Дайал, Венкатеш Ганти
22.01.2002

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

Типы моделей

Классификационные модели позволяют делать прогнозы. Для данного нового кортежа классификационные модели прогнозируют, принадлежит ли кортеж одному из набора целевых классов. В примере с каталогом FSC классификационная модель, основываясь на накопленных к текущему моменту данных, определяет, приобретет ли клиент товар из каталога. Деревья решений и простые байесовы модели — два самых популярных типа классификационных моделей [5-7].
Регрессионные деревья и логистическая регрессия — два самых распространенных типа регрессионных моделей, которые прогнозируют численные атрибуты, такие как зарплата или возраст клиента [5].
В некоторых приложениях аналитики точно не знают набора целевых классов и полагают их скрытыми. Модели кластеризации, подобные K-Means и Birch, используются для определения соответствующего множества классов и классификации нового кортежа с отнесением его к одному из этих скрытых классов [6, 7].
Модели на базе правил, в частности модель правил ассоциаций, используются, чтобы выяснить, является ли покупка конкретного набора предметов обуви, с определенной степенью уверенности, индикатором приобретения и другого продукта.

Управление метаданными

Метаданные — информация любого рода, которая требуется для управления хранилищем данных, а управление метаданными — существенный компонент архитектуры хранения. К административным метаданным относится вся информация, которая требуется для настройки и использования хранилища данных. Бизнес-метаданные включают в себя бизнес-термины и определения, принадлежность данных и правила оплаты услуг хранилища. Оперативные метаданные — это информация, собранная во время работы хранилища данных, такая как происхождение перенесенных и преобразованных данных; статус использования данных (активные, архивированные или удаленные); данные мониторинга, такие как статистика использования, сообщения об ошибках и результаты аудита. Метаданные хранилища часто размещаются в репозитории, который позволяет совместно использовать метаданные различным инструментам и процессам при проектировании, установке, использовании, эксплуатации и администрировании хранилища.
Согласованные усилия коммерческих компаний и научных кругов привели к серьезному технологическому прогрессу в решении задач хранения данных. Это нашло отражение во множестве коммерческих продуктов, которые доступны для каждой из трех основных операций: пополнение хранилища данных из независимых транзакционных систем; хранение данных и управление ими; анализ данных с целью принятия обоснованных бизнес-решений. Однако, несмотря на изобилие коммерческого инструментария, остается еще несколько важных направлений для исследования.
Очистка данных связана с интеграцией данных из неоднородных источников, проблемой, которую изучают уже много лет. На сегодняшний день основные усилия концентрируются на проблемах несогласованности данных, а не на проблемах несогласованности схем. Хотя очистка данных в последнее время привлекает большое внимание исследователей, предстоит еще немало сделать для создания инструментальных средств, не зависящих от предметной области, которые решают разнообразные проблемы очистки данных, связанные с разработкой хранилищ.
Большая часть исследований в области добычи данных касается разработки алгоритмов для создания более точных моделей или алгоритмов, позволяющих ускорить этот процесс. Два других этапа процесса выявления знаний — подготовка данных и применение модели добычи данных — по большей части игнорируются. На обоих этапах возникает несколько проблем, в частности, связанных с достижением большей гармонии между системами управления базами данных и технологией добычи данных. В конечном итоге, новые инструментальные средства должны дать аналитикам более эффективные способы подготовки наборов данных, отвечающих конкретной цели, и более эффективные способы применения моделей к результатам произвольных SQL-запросов.

Загрузка

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

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

Джо Людтке (Joe Luedtke)
Перевод:
Это вопрос простой арифметики. Покупка и реализация BI-приложений может оказаться очень и очень дорогой. Одни только лицензии на BI-порталы, ETL-инструменты и средства управления эффективностью оцениваются шестизначными цифрами. Даже лидирующий на рынке инструмент для создания отчетов и запросов часто оценивается в сотни тысяч долларов за лицензию для группы пользователей.
Хотите создать корпоративное Хранилище данных? Что ж, если подсчитать расходы на аппаратное обеспечение, СУБД, инструменты моделирования, средства создания запросов и отчетов, ETL-инструменты, Web-интерфейс, расходы на консультирование и поддержку, то цена подскочит и до семизначной цифры.
Многое уже говорилось и писалось об эффективности вложений в BI-проекты. Часто небольшие и средние компании сталкиваются с бизнес-проблемами, требующими использования BI-средств. Однако мало обсуждался вопрос преодоления барьеров, которые встают на этом пути.

Доступный капитал

Если нет уверенности, что при внедрении BI возникает ценовой барьер, то стоит провести некоторые расчеты. На практике нет четкого определения малого и среднего сектора бизнеса. Иногда критерием является количество сотрудников (100—999), иногда годовой доход компании. В этой статье к фирмам малого и среднего масштаба отнесены те из них, чьи доходы не превышают 500 млн. долларов.
По прогнозам известной аналитической компании Gartner, на IT расходы в малом и среднем бизнесе в 2004 году в среднем будет приходиться 3,2 процента от годового дохода, а, следовательно, финансовые ограничения станут особенно актуальными. А это означает, что если на IT запланировано выделить 3,2% от годового дохода, то компания, получающая 100 млн. долларов в год, сможет потратить на IT чуть больше 3 млн.
Но ведь не вся же эта сумма должна пойти на BI — в лучшем случае 10%, т.е. всего 320 тыс. долларов. При этом сотни две из них придется потратить на администрирование базы данных, разработку отчетов, ETL-обработку, общую поддержку системы, и, таким образом, на аппаратное и программное обеспечение, обновление лицензий и консультантов остается меньше 100 тыс. долларов.
Вглядываясь в эти цифры, понимаешь, почему более 40% компаний этого сектора заявляют, что им не нужно BI-решение. Для многих из них спорить, выиграют ли они от использования BI-средств или нет, совершенно неактуально. Причина в том, что эти средства им просто не по карману.

Наполовину пустой или наполовину полный?

Итак, приходится принять пессимистическую точку зрения: «BI-стакан меньше чем на половину пустой». Впрочем, можно считать его и наполовину полным, если учесть, что 60% фирм малого и среднего бизнеса уверены в необходимости BI-проекта и либо уже реализовали его, либо находятся на стадии внедрения. Что ж, если ценовой барьер удастся преодолеть, то дело пойдет в гору и, наконец, появятся положительные в смысле прибыли результаты.
BI-проект в малом или среднем бизнесе совсем не таков, как в компаниях, входящих в рейтинг Fortune 500 (и в чуть более мелких). Малый масштаб предприятия меняет типичную BI-методологию по нескольким серьезным параметрам:
Полезность и качество. Известно, что средняя компания не стремится купить исключительно самое дешевое ПО, скорее она будет выискивать самое полезное. Признанная марка и положение в рейтинге значит не так много, как текущая польза, которую может принести инструмент. У малого бизнеса нет причин отказываться от покупок на Wal-Mart или Target, если задача состоит в том, чтобы получить хорошее качество за приемлемую цену. Компания Crystal Decision не победит Business Objects или Cognos в рейтинге Gartner в категории «Целостность представления» («Completeness of Vision»), но по полезности может оказаться лучше.
Только то, что нужно. Если штат IT-департамента насчитывает порядка тысячи человек, то ему довольно легко освоить новые специфичные технологии. Другой вопрос, если число сотрудников не превышает двух десятков. Для небольшого IT-отдела стандарты играют еще более серьезную роль, чем для крупного предприятия. Это вопрос обеспеченности технической поддержкой. Небольшой отдел не сможет создать и обслуживать BI-технологии. В качестве интерфейсного средства вряд ли будет выбран BI-портал на базе J2EE-архитектуры, если вся работа ведется на средствах Microsoft. Однако, BI-разработка и администрирование будут возложены на уже работающих сотрудников.
Совершенство архитектуры и наличие технической поддержки. Небольшой IT-штат в рамках малого или среднего предприятия также стремится к упрощению BI-архитектуры.

Однажды автор статьи работал в комиссии в Fortune 1000, которая проводила анализ и проверяла обоснованность двух различных концепций BI-архитектур (Ральфа Кимбола (Ralph Kimball) и Билла Инмона (Bill Inmon)). В этом проекте моделировалось Хранилище данных предприятия, предлагаемое в обеих архитектурах. Задача состояла в том, чтобы выбрать наиболее подходящую архитектуру для предприятия. С другой стороны, автор однажды познакомился с разработчиком в одной маленькой компании, который создал ненормализованный файл с пользовательскими данными и был полностью доволен, называя его Хранилищем данных. Иными словами, приверженность некоторой теоретической архитектурной доктрине может оказаться, с точки зрения размеров IT-отдела, непрактичной, ведь, повторимся, самую большую роль играет полезность проекта.

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

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

Ответы на эти вопросы мы рассмотрим в последующих статьях.

Fortune 1000 ? рейтинг тысячи ведущих американских компаний.

Оригинальный текст статьи можно посмотреть здесь:

Business Intelligence обещает значительный рост в 2005 году

Intersoft Lab
Аналитики предсказывают, что в 2005 г. Business Intelligence (сокр. BI) может стать очень привлекательной областью для IT-инвестиций. Так ли это? Для того чтобы ответить на данный вопрос, известный информационный портал Analyst Views в феврале 2005 г. опубликовал обзор текущих тенденций на рынке BI технологий. Авторы обзора, отталкиваясь от определения Business Intelligence как таковой, обсуждают причины, по которым растет интерес к этим технологиям, и возможные "ловушки", подстерегающие пользователей, а также дают несколько рекомендаций тем, кто намерен использовать данные системы.

Business Intelligence в мире

Интерес к Business Intelligence растет и за пределами США. Согласно результатам компании Forrester Research, почти 30% европейских фирм будут рассматривать возможность внедрения программного обеспечения Business Intelligence в 2005 г. По данным другой компании, International Data Corporation (IDC), в странах восточной и юго-восточной Азии (за исключением Японии) в 2003-2008 гг. среднегодовой темп роста решений, связанных с безопасностью и Business Intelligence, составит 21%.

Еще раз о Business Intelligence

Авторы обзора, ссылаясь на отчет компании Technology Evaluation, напоминают, что:
"Business Intelligence - это не продукт и не система. Это общий термин, который включает архитектуру, приложения и базы данных. BI технология позволяет получать интерактивный доступ к информации, анализировать ее и манипулировать ей в режиме реального времени, предоставляя, таким образом, легкий доступ к бизнес-данным для пользователей. BI технология также позволяет анализировать исторические данные и способствует развитию бизнеса, поскольку с ее помощью можно сопоставлять деловую ситуацию и эффективность бизнеса в прошлом и в настоящем. Все это помогает лицам, принимающим решения, и обеспечивает конечных пользователей важной бизнес-информацией о клиентах или партнерах, в том числе информацией о существующих тенденциях и трендах".
Этот отчет также напоминает о некоторых других сокращениях, связанных с Business Intelligence, которые часто путают с ней. "Такие понятия, как управление эффективностью бизнеса (business performance management,
сокр. BPM), управление бизнес-процессами (business process management, сокр. BPM), управление эффективностью корпорации (corporate performance management, сокр. CPM) и мониторинг деловой активности (business activity monitoring, сокр. BAM), являются составными частями Business Intelligence, но не наоборот".

"Ловушки" Business Intelligence

В пресс-релизе, опубликованном недавно по итогам BI конференции, проведенной в Лондоне ("Фатальные ошибки" Business Intelligence и способы избежать их" ["Fatal Flaws" of Business Intelligence and How to Avoid Them]), ведущие аналитики корпорации Gartner Group Inc. выделили семь основных ошибок, имеющих место при внедрении и использовании BI-систем, а также рассказали о том, как их можно избежать. Авторы настоящего обзора предлагают читателям краткое изложение этой информации: см.

Если мы создадим систему, то

Таблица 1

Таблица 1

Ошибка	Описание	Как избежать
Если мы создадим систему, то автоматически получим все преимущества.	Слишком многие IT-отделы создают Хранилища данных, исходя из предположения, что как только они будут созданы, пользователи автоматически увидят все их преимущества.	BI-приложения требуют ясного и глубокого понимания бизнеса как такового, поэтому истинная ценность Business Intelligence выявляется только при одновременной работе над проблемами IT и вопросами бизнеса.
Менеджеры должны согласовывать цифры.	Слишком многие не могут расстаться с электронными таблицами, поскольку привыкли к ним и знают, как манипулировать цифрами для соответствия политике своей организации.	Корпорации должны заставить свой персонал очистить многочисленные изолированные источники данных, предоставить доступ к данным об эффективности бизнеса большему количеству пользователей и избавиться от тысяч электронных таблиц.
Проблема качества данных? Это не про нас.	К 2007 г. более половины проектов Хранилищ данных смогут использоваться ограниченно или вообще провалятся в результате недостаточного внимания к вопросам качества данных. Более того, многие организации не осознают, что у них есть проблемы с качеством данных, концентрируясь вместо этого на нахождении, извлечении и загрузке данных.	Вопросы качества данных постоянно должны быть в фокусе внимания, а корпорациям необходимо осознать, что за качество данных отвечает не только IT-отдел.
Наш поставщик корпоративных приложений может обеспечить наилучшее решение.	Слишком часто корпорации ошибочно считают, что покупка всего необходимого в "одном месте", т.е. у одного поставщика, окажется как наиболее дешевым, так и самым подходящим для бизнеса решением. Но не стоит думать, что основные поставщики корпоративных приложений, предлагающие также BI-решения и инструменты, могут удовлетворить все информационные нужды компании.	Необходимо всегда сравнивать решение своего поставщика корпоративных приложений с тем, что предлагают ведущие поставщики, специализирующиеся именно в Business Intelligence.
Чарльз Дарвин был прав - BI-проекты должны эволюционировать.	Так же как постоянное использование одних и тех же шаблонов означает, что планы редко меняются, встраивание старых ограничений в новую систему - это одно из самых серьезных препятствий на пути к успеху.	Да, BI-средства должны эволюционировать, но конкретные проекты в этой области - нет. У них должны быть четкие начало и конец, а не постепенный переход из одного состояния в другое.
Мы все можем передать субконтракторам.	К 2006 г. менее 10% тех корпораций, для которых аутсорсинг может быть полезной стратегией, окажутся готовы или способны полностью передать на субподряды свои BI-приложения и операции.	Корпорации должны определить свои ключевые возможности для развития Business Intelligence, чтобы понять, что передавать или не передавать на субподряд. Как и в других случаях, здесь действует свое "золотое правило": необходимо избегать искушения передать на аутсорсинг вообще все, это нужно делать только в тех областях, которые не относятся к основной деятельности компании.
Дайте мне инструментальную панель!	Управленческая инструментальная панель должна рассматриваться как завершающий аккорд.	В первую очередь компании должны получить надежную и стабильную BI-инфраструктуру. Затем им следует создать такой сетевой подход, с помощью которого эти новые технологии могут быть связаны с другими BI-технологиями как внутри, так и за пределами организации, а также с иными технологиями, такими как технологии управления эффективностью бизнеса и интеграции приложений.

Почему растет интерес к Business Intelligence?

Аналитики отмечают несколько причин возрастающего интереса к Business Intelligence в США. Основные из них - это необходимость выполнения требований закона Сарбанеса-Оксли (Sarbanes-Oxley Act) и стремление IT-отделов участвовать в увеличении ценности бизнеса.
По данным нескольких последних опросов директоров по информационным технологиям, IT-отделы действительно начинают заниматься улучшением бизнес-процессов. Изучение мнения 1300 директоров по информационным технологиям, проведенное компанией Gartner Group Inc., показало, что внедрение программного обеспечения класса Business Intelligence - это именно то, что они и подчиненные им IT-отделы могут сделать для улучшения бизнес-процессов своей компании и повышения ее эффективности. По данным этого же исследования, Business Intelligence занимает второе место в списке приоритетов IT директоров по информационным технологиям в 2005 г., уступая только вопросам безопасности. Аналогичные результаты показывают и опросы, проведенные другими фирмами.

Актуарные операции

Актуарные операции— одни из самых сложных в страховом бизнесе. Они включают в себя оценку риска, связанного со страхованием некоторого имущества. В случае страхования жизни или медицинского страхования актуарные операции сводятся к расчету вероятности несчастного случая или смерти на основе различных демографических, психографических и других внешних характеристик. В актуарных вычислениях для определения будущих премий и распределения части перечня дел (book of business) для перестрахования часто используются сложные математические модели, разрабатываемые с помощью аналитических инструментов.

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

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

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

Андеррайтинг и обработка полисов

Андеррайтер определяет, приемлем ли риск, который берет на себя компания, страхуя клиента. Если приемлем, то рассчитывается сумма взимаемой премии. BI-средства позволяют выгодно использовать содержащиеся в Хранилище данные о претензиях, полисах и убытках, с тем чтобы повысить эффективность андеррайтинга.
Перечислим основные сферы применения Business Intelligence в этой области.

Анализ премий. Поступления от премий — основной источник дохода для страховой компании. Анализ премий помогает отслеживать выгодность премии по продукту или группе продуктов, по географическому положению, агентам или филиалам. Применяя метод «slice and dice» можно сгенерировать множество видов анализа и отчетов.

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

BI и структура страхового бизнеса

За предыдущие три десятилетия страховые компании существенно расширили спектр услуг, но при этом в понимании истинных потребностей клиентов они очень отстали. В итоге большинство фирм действуют по принципу «предлагаем то, что умеем», а не по принципу «то, что нужно заказчикам». Однако в последние годы из-за тенденций к дерегулированию (сокращению объема вмешательства государства в экономику) наблюдается рост конкуренции, и это заставляет страховщиков отказаться от традиционной ориентации на услугу и сосредоточиться на нуждах клиентов, корректируя соответствующим образом все бизнес-процессы.
В осуществлении этой цели инструменты Business Intelligence (Хранилища данных, OLAP и data mining) оказывают существенную поддержку на всех этапах страховой деятельности. На рисунке 1 показана цепочка начисления стоимости для страхования. В следующих разделах мы рассмотрим, какие BI-приложения можно применить для каждого элемента этой структуры.

Рис. 1. Структура страхового бизнеса

Человеческие ресурсы

Хранилище данных может существенно помочь в разработке согласованной стратегии управления человеческими ресурсами (Human Resources, сокр.HR ). Оно дает возможность получить полное представление о кадровых ресурсах, повысить производительность труда и сократить расходы.
Рассмотрим некоторые аспекты применения BI в управлении человеческими ресурсами.

Отчеты/Аналитика по HR. Чтобы иметь полное представление о сотрудниках, удобно воспользоваться отчетами и специальными аналитическими функциями. Можно анализировать перемещение кадров и производительность труда, убыль рабочей силы по отделам, соотношение заработной платы и случаев ухода сотрудников и т.п. Данные по HR можно рассматривать вкупе со средними показателями по страховой отрасли и создавать различные отчеты, оценивая производительность данной компании по сравнению с отраслью в целом.

Распределение сотрудников. Связано с распределением персонала при вводе в употребление новых страховых продуктов. В связи с дополнительными потребностями в кадрах агенты и продавцы распределяются по конкретным регионам, где возрастает спрос на страховые услуги (или предполагается его рост).

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

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

Корпоративное управление

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

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

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

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

Немного истории

Конец семнадцатого века ознаменовался бурным развитием международной торговли. Путешествия через океаны были полны угроз и неожиданностей, и мореплавателям нужно было защищаться от опасностей, подстерегавших их в открытом море. Тогда появились новые предприниматели — морские страховщики — люди, которые соглашались покрыть все потери в замен на фиксированную премию. Их бизнес зависел от текущей информации о морских путях, пиратах, политическом климате, погодных условиях и вкусов потребителей на экзотические продукты. Чтобы получить нужные сведения, многие из них приходили в кофейню Эдварда Ллойда (Edward Lloyd's coffeehouse) в Лондоне, где можно было поделиться «интеллектуальными ресурсами» (business intelligence) с другими страховщиками и капитанами торговых судов. В 1771 году 79 страховщиков собрались вместе, чтобы образовать общество, которое впоследствии стало самой известной среди всех страховых компаний — Лондонской компанией Ллойда (Lloyd’s of London).
Те самые «интеллектуальные ресурсы», объединявшие морских страховщиков у Ллойда, стали еще актуальнее в современном страховании. Сегодня оно полностью зависит от возможности преобразования исходных разрозненных данных в информацию о клиентах, рынках, конкурентах, положении бизнеса в целом. За последние годы средства обработки данных получили огромное развитие, и инструменты Business Intelligence широко используются в различных сферах. Однако в страховании они приживались довольно медленно, в основном из-за не очень высокой конкуренции в этой области, обусловленной протекционистской политикой государства. Но теперь, по мере внедрения Internet, консолидации и объединения страхования с другими финансовыми услугами, базовая структура отрасли меняется, и страховщики уже не могут «самодовольно почивать на лаврах».

Страхование. Обзор и основные тенденции

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

страхование имущества и несчастных случаев (Propertyand Casualty, сокр. P&C);

страхование жизни.
Последнее, в свою очередь, делится на:

непосредственно страхование жизни;

медицинское страхование;

и пенсионное страхование.

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

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

Объединение финансовых служб. Поглощение страховых компаний другими поставщиками финансовых услуг (например банками) привело к появлению интегрированных финансовых компаний.

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

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

Управление финансами и активами

Традиционно проценты от инвестиций были самым значимым источником доходов для страховщиков, тогда как андеррайтинговые расходы радикально снижали прибыльность бизнеса. Поэтому, чтобы конкурировать на этом рынке, страховщикам надо повышать эффективность вложений и сокращать страховые издержки. Для этого необходим быстрый доступ к финансовым данным для их анализа. Многие компании, пытаясь повысить качество финансовой отчетности и принимаемых решений, интегрировали данные в Финансовое Хранилище (Financial Data Warehouse, FDW ).

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

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

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

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

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

Управление каналами сбыта

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

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

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

Анализ каналов. Подразумевает оценку эффективности различных каналов. Используя BI-инструменты страхователи могут сравнивать производительность различных каналов, а также получать детальную информацию по отдельным агентам и продуктам.

Развитие электронного бизнеса. Аналитические операции можно применять к данным о клиентах и транзакциях, полученным через Internet. Эти данные необходимо интегрировать информацией из традиционных каналов, чтобы правильнее выполнять сегментацию клиентов, покупающих страховые полисы через сеть. Есть еще один источник потенциально полезных данных, которые могут существенно повысить качество услуг, предоставляемых в online-режиме, — это файлы записи Web-протоколов (Web logs). Обработка Web-протоколов выявляет типичные пути и ошибки навигации на сайте страховщика, находит наиболее посещаемые страницы, определяет узлы, с которых пользователи чаще всего переходят на данный сайт, анализирует ключевые слова, которые набирали посетители сайта, обнаружившие его через поисковые машины. Благодаря такому подходу удается разрешить многие проблемы и оптимизировать сайт с точки зрения удобства использования.

Управление отношениями с клиентами

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

Рис. 2. BI и CRM.
Процесс управления отношениями с клиентами в страховой компании состоит из трех этапов:

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

На этих этапах инструменты BI находят ряд применений:

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

расходы, связанные с обслуживанием клиента за некоторый период;

доходы, полученные от этого заказчика за тот же период.

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

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

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

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

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

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

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

Управление претензиями

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

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

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

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

в страховую отрасль идет очень

Внедрение BI-средств (Хранилищ данных, OLAP и других аналитических инструментов) в страховую отрасль идет очень неравномерно. Лишь немногие компании активно пользуются этими инструментами, но уже многим страховщикам очевидны преимущества данной технологии. Некоторые фирмы прибегли к временным, не масштабируемым решениям, которые часто не справляются со всё возрастающим объемом данных. Поэтому очень важно осознать необходимость применения эффективной BI-среды. Но это лишь первый шаг. Самое сложное — сделать аналитические инструменты неотъемлемой частью процесса принятия решений.
Успех любого Хранилища состоит в эффективном сборе информационных требований от всех групп пользователей. Мнение о том, что «если систему разработать, то ее будут использовать» — ошибочно. Поэтому, опираясь на поддержку высшего руководства страховой компании, очень важно поставить четкие бизнес-цели для BI-решения.

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

Выбор системы бюджетирования: основные требования

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

Перевод:
Рано или поздно настанет пора сменить имеющееся программное обеспечение (ПО) для бюджетирования. Какой должна быть новая система? Сводя десятки, а то и сотни электронных таблиц в один основной бюджет, мы рискуем сделать процесс бюджетирования и планирования чрезвычайно трудоемким и подверженным многим ошибкам: обычно эта задача выполняется раз в год и ее результаты могут устареть к тому моменту, когда бюджет будет наконец-то утвержден.
По словам Дэна Шоллера (Dan Sholler), одного из руководителей компании Meta Group (занимающейся маркетинговыми исследованиями), компании, которые используют элементарные бюджетные технологии, тратят до шести месяцев на составление бюджета, а «к этому моменту ситуация на рынке может совсем измениться — появятся новые продукты или, не исключено, новые конкуренты».
В надежде упростить столь изнурительный процесс и сделать его более точным, многие компании стали обращаться к специальным программам для бюджетирования и планирования, однако столкнулись с другой проблемой — проблемой выбора: предлагаемые на рынке программные продукты столь разнотипны, что их непросто даже классифицировать.
Дэн Шоллер считает, что продукты нужно выбирать на основе набора функций, которые они предлагают, ориентируясь в конечном счете на приоритеты своей компании.
Аналитики, предлагают искать продукты, которые обеспечивают гибкость и динамичность бюджетирования. В целом, хорошее приложение для бюджетирования должно предоставить пользователям возможность объединять фактические данные с планируемыми допущениями, которые можно отслеживаться и корректироваться по мере изменения бизнес-условий. «Бюджетные показатели полезны только в том случае, — замечает Дэн Шоллер, — когда они достаточно динамичны (то есть их можно менять при изменении бизнес-условий) и могут быть связаны с другими показателями, определяющими развитие бизнеса».
Однако каковы бы ни были конкретные нужды компании, качественный продукт должен иметь определенный набор функций.

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

Самые лучшие инструменты для бюджетирования реализованы для работы в браузере (browser-based), утверждает Пол Хэмермен (Paul Hammerman) руководитель научно-исследовательских работ компании Giga Information Group. Web-приложения не требуют установки на компьютеры пользователей, вовлекая в процесс бюджетирования большее число участников и, тем самым, делая его более динамичным.

«Web-приложения позволяют выполнять восходящее и нисходящее прогнозирование (bottom-up and top-down forecasting), обеспечивают ввод текущих данных в реальном времени, в результате некоторых событий или изменений ситуации, — комментирует Пол Хамерман. — Например, торговый агент может использовать инструмент планирования для корректировки своих поставок. Если вероятность заключить сделку меняется, это должно отражаться в прогнозах».

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

Вот, что говорит Дэн Шоллер: «Если я, к примеру, — руководитель производственного отдела на заводе и имею некоторое ограничение по расходам, то мне необходимо знать, из чего эти расходы складываются, то есть каковы показатели работы предприятия: ежедневный объем производства, объем материальных запасов и поставок. Бюджетное приложение должно позволять быстро изменять бюджетные цели и оценивать, как они влияют на эффективность предприятия в целом».

«Бюджетные приложения должны обеспечивать быструю консолидацию показателей так, чтобы при внесении изменений не приходилось бы ждать следующего дня, когда система наконец обработает это изменение и выяснится, какими же станут показатели», — таково мнение Раджи Кочара (Raja Kochar), руководителя группы Business Intelligence в консалтинговой фирме.

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

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

«Главное, чтобы была установлена связь с корпоративными финансами, хотя интеграция с ПО для управления цепочкой поставок, ресурсами предприятия и взаимоотношениями с клиентами тоже важна», — утверждает Дэн Шоллер. «Предположим, что одно из ограничений, которое нужно преодолеть, состоит в том, что расходы на продажи и маркетинг должны составлять 23 процента от планируемых продаж. Можно либо грубо оценить планируемые продажи, либо определить эти данные, получив информацию о продажах из приложения Siebel», — поясняет он.

Интеграция — ключевой показатель, который делает процесс бюджетирования более динамичным. Раджа Кочар добавляет, что очень важна возможность разобраться с планируемыми показателями при различных сценариях, что крайне полезно в тех случаях, когда приложение для бюджетирования можно легко интегрировать с другими приложениями. «Инструмент должен подсказать мне, как повлияют на мои показатели те или иные изменения. Кроме того, необходима возможность, например такого типа: есть некоторый показатель (EBITDA), который нужно обеспечить аналитикам, как его можно достичь?»

Сложные инструменты бюджетирования имеют также и встроенный OLAP-компонент.

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

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

«Функция автоматизации документооборота ( workflow functionality) позволяет финансовому управляющему быстро определять, кто уже представил бюджет, а кто нет; эта функция также предупреждает об отклонениях в показателях, следовательно, ее можно считать важным компонентом приложения для бюджетирования», — добавляет он. — Это особенно важно для крупных организаций, где работает более несколько сотен человек и более. Небольшие фирмы могут решить эту задачу своими силами, без специального ПО».

Хорошая система бюджетирования также требует, по словам Дэна Шоллера, удобного метода «унификации»: «Например, данные в Excell-таблице обычно вводятся в долларах, что вызывает проблемы на уровне отделов.

Вот, если я работаю менеджером на товарном складе, то какое число в долларах нужно ввести, чтобы отобразить ценность моих сотрудников? Мне было бы удобно просто указать, что на складе работает восемь служащих, а система бюджетирования затем сама бы выяснила, как перевести эти данные в доллары, используя самую разную информацию, например из системы управления человеческими ресурсами (Human Resources, HR)».

Дэн Шоллер также призывает не забывать об информационной безопасности — ведь это тоже очень важный момент.

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

Кочар отмечает еще один момент: «Так как многие корпорации переходят на Web-приложения, то для некоторых пользователей был бы удобен доступ к системе бюджетирования через портал. Это позволило бы выполнять индивидуальную настройку инструмента для каждого пользователя, в зависимости от занимаемой им должности».Портал сообщит пользователю, выполняются ли цели, установленные в процессе бюджетирования, и поможет внести соответствующие изменения, а кроме того, позволит ему сохранять на своем компьютере «памятки» (cheat sheets) и замечания по поводу определенных показателей.

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

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

«Идеальное» приложение для бюджетирования должно обеспечивать:

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

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

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

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

Акт о телекоммуникационных системах 1996г.

В феврале 1996г. конгрессом США был принят Акт о телекоммуникационных системах. В телекоммуникационной отрасли происходили существенные изменения, этот акт был своеобразным "ответом" на них - он снял большую часть законодательных ограничений, существовавших в данной сфере. Задачей данного закона было стимулирование конкуренции между телефонными и кабельными компаниями, а также поставщиками Интернет-услуг. Хотя, надо заметить, что некоторые ограничения все же были введены. Так, например, до сих пор конкуренция была слабо развита в предоставлении телефонных услуг на местном уровне. Поэтому, чтобы объединиться и предоставлять совместные телефонные услуги, дочерние компании Bell (компании, которые были созданы после того, как в 1984 г. по решению суда корпорация AT&T была расформирована), по-прежнему контролировавшие большую часть рынка, должны были доказать Федеральной комиссии связи существование определенной конкуренции в данном секторе на местном рынке. Что же касается услуг междугородной связи, то эти компании могли предоставлять их лишь после получения разрешения от соответствующих органов надзора.
После принятия данного акта в сфере телекоммуникаций произошло огромное число слияний и объединений между различными компаниями. В 1997г. общая стоимость произошедших слияний по всему миру была оценена в 102 миллиарда долларов, в 1998г. - 297 миллиардов, в 1999г. - 670 миллиардов долларов. Слияния происходили как между различными компаниями, так и между подразделениями одной компании. Компании старались максимально снизить свои расходы и получить возможность предоставлять своим клиентам весь пакет услуг связи (местные и междугородные звонки, проводные и беспроводные средства связи, телефон, видео и Интернет).
В 1997г. Bell Atlantic, дочернее предприятие Bell, выкупило Nynex, еще одно дочернее предприятие Bell, в результате чего, компания стала основным провайдером телефонных услуг в северо-восточном регионе США. В июне 2000г. компания объединилась с GTE, крупнейшей независимой телефонной компанией в США.
Новая корпорация была названа Verizon и стала одной из ведущих организаций по предоставлению телекоммуникационных услуг. Ее ежегодный доход составлял около 60 миллиардов долларов, а число сотрудников превышало 260000 человек. Компания занималась предоставлением обычных и беспроводных телефонных услуг, а также передачей данных и публикацией печатных и электронных справочников. Основным регионом деятельности компании были США, но ряд операций также осуществлялся и за границей. Verizon - крупнейшая компания по предоставлению местных телефонных услуг (63 миллиона линий локального доступа) и беспроводных телефонных услуг (27 миллионов абонентов). Еще 5 миллионов абонентов компании пользуются услугами междугородней/международной связи. Руководство планирует расширение данного сектора услуг, после того, как компания адаптируется к новым условиям осуществления деятельности.

Изменения в стратегии GTE

После принятия Акта основная стратегическая задача GTE также была несколько изменена, и теперь она формулировалась следующим образом:
Максимизировать доход посредством предоставления полного пакета высокотехнологичных телекоммуникационных услуг по всей стране. В соответствии с данной стратегией… в 1997г. с целью оптимизации эффективности как внутри традиционной сферы деятельности компании, так и за ее пределами была создана национальная организация по продажам и маркетингу. Кроме того, были осуществлены значительные вложения в сферу предоставления услуг обмена данными, а также в сфере передовых Интернет-технологий и услуг.
Подобные изменения в стратегии можно было обосновать рядом факторов. Годовой рост дохода GTE в 1993-1995гг. составил менее 2%. В 1996г., рост дохода уже составил 7%. На период 1997-2006г. прогнозируемый рост доходов должен был составить 10%, т.е. ежегодные доходы этой компании должны были увеличиться с 21 миллиарда долларов до 58 миллиардов долларов к 2006г. Около 5 миллиардов должны были поступить из совершенно новых источников.
Текучесть кадров и текучесть клиентской базы
Две основных проблемы, стоявшие перед большинством компаний по предоставлению телекоммуникационных услуг, были текучесть кадров и текучесть клиентской базы.
Так, в 1999г. 23% всех клиентов, пользующихся услугами междугородной/международной телефонной связи, меняли провайдера, по крайней мере, один раз. Провайдера также поменяли 35% клиентов, использующих услуги беспроводной связи. Текучесть клиентской базы в сфере потребления услуг беспроводной связи в последующие года должна была еще больше увеличиться.
Уровень текучести кадров также был достаточно высок: в компаниях по предоставлению телекоммуникационных услуг он составлял 20-25% в год (в GTE этот уровень был практически такой же, как и в других компаниях данного сектора).
Одновременно с этим, исходя из результатов различных исследований и отчетов, наблюдалось снижение качества предоставляемых услуг. Основными претензиями были недовольство скоростью обработки заказов на услуги, неправильная информация, предоставляемая сотрудниками, дискриминация по расовой принадлежности и т.д. Некоторые небольшие компании (такие как, например, CLEC) пытались осуществлять обслуживание клиентов на более высоком уровне, таким образом, создавая конкурентоспособное преимущество.
Компании объясняли эти проблемы нехваткой квалифицированного персонала на рынке. В конце 90х годов, уровень безработицы в США был близок к рекордно низким показателям.

Система сбалансированных показателей

Каплан и Нортон определили систему сбалансированных показателей (The Balanced Scorecard - ССП), как концептуальную основу для оценки деятельности компании по ряду показателей, как финансовых (традиционные способы оценки), так и нефинансовых.
Финансовые показатели, или как их еще иногда называют "отстающие" индикаторы (lagging indicator), несомненно, играют значительную роль, но тем не менее, они характеризуют осуществляемую деятельность с опозданием. Напротив, нефинансовые показатели, или как их еще иногда называют "опережающие" (ведущие) индикаторы (leading indicator), (качество товаров и услуг, мотивированность и квалифицированность персонала, эффективность внутренних процессов, степень удовлетворенности клиентов и т.д.) обеспечивают данные для прогнозирования деятельности компании и могут использоваться для своевременного решения возникающих проблем.
Необходимость внедрения подобной методики была вызвана изменениями условий деятельности компаний. В век промышленности успех компании зависел, в основном, от инвестиций в материальные активы и от "грамотного" управления персоналом. Во время резких изменений в технологии и в структуре рынка нематериальные активы компании приобретают все большую значимость. ССП структурирует данный аспект деятельности компании. В системе используются нефинансовые показатели, тесно связанные со стратегическими задачами компании. Соответственно, нефинансовые показатели будут различными для всех компаний. Соединение всех элементов в единую систему является достаточно непростой задачей, так как, зачастую, бывает достаточно сложно определить оптимальные показатели для того или иного предприятия, их количество (особенно, учитывая ограниченное время, которое сотрудники могут уделить решению этой задачи), а также возможную степень количественного определения требуемых нефинансовых показателей.

Стратегическая база GTE

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

Стратегическое направление 1: таланты

Привлечение талантливых сотрудников

Инвестиции в человеческие ресурсы

Обеспечение возможности роста и развития персонала

Обеспечение разнородности персонала

Создание атмосферы, способствующей креативной и инновационной работе

Стратегическое направление 2: лидерство

Стимулирование развития лидерских навыков

Определение лидерской компетенции

Поощрение проявления лидерских навыков и качеств

Стратегическое направление 3: система предоставления услуг и осуществления технической поддержки

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

Наращивание возможностей в сфере оказания услуг и технической поддержки

Стратегическое направление 4: интеграция

Расширение возможностей GTE как корпорации в целом

Сотрудничество с профсоюзами

Стимулирование сотрудничества между отделами

Стимулирование корпоративной интеграции

Стратегическое направление 5: HR-возможности

Инвестиции в рост и развитие

Создание организации, предоставляющей услуги на высшем уровне

Оптимизация технических возможностей

Из сотрудников HR-отдела была сформирована рабочая группа, которая должна была разработать конкретную модель для реализации этих стратегических задач. Группа была названа "Планирование, оценка и анализ" (Planning, Measurement and Analysis - ПОА) и состояла из 4 человек под руководством Гаррета Уолкера (Garret Walker). Уолкер уже занимал раньше ряд должностей в GTE, кроме того, он также участвовал в решении организационных вопросов.

Поддержку ПОА осуществляла "Центральная группа оценки HR-отдела", состоявшая из нескольких специалистов из отдела.

Данные взяты из статьи "Кто на Первом канале" ("Who's on First?" - Wall Street Journal), опубликованной в американской финансовой газете Уолл Стрит Джорнел, от 18 сентября, 2000г. "Форма 10-к" от 1998г. (форма ежегодной отчетности корпораций перед Комиссией по ценным бумагам и биржам (дополнение к годовому отчету)). Данные взяты из статьи "Способы удержания клиентов" ("Fighting the Fickle" - Wall Street Journal), опубликованной в американской финансовой газете Уолл Стрит Джорнел, от 18 сентября, 2000г. Для снижения текучести клиентской базы некоторые компании использовали программные средства data mining, а также предоставляли ряд специальных услуг (мне кажется, что использование ПО и предоставление услуг - несколько различные категории…). Так, компания Verizon Wireless, например, в 2000г. внедрила сложный алгоритм в свое программное обеспечение для того, чтобы получить данные о тех клиентах, которые, скорее всего, уйдут из компании. После этого, представители компании должны были по телефону связаться с этими клиентами и выяснить, насколько они удовлетворены предоставляемыми услугами, подобрать оптимальный план, и т.д. по предварительным оценкам, подобная система должна была снизить текучесть клиентской базы на 10 - 15%. Газета "Нью-Йорк Таймс" (New York Times), 12 апреля 2000г., газета "Денвер Роки Маунтин Ньюз" (Denver Rocky Mountains News), 28 мая 2000г. Уолл Стрит Джорнел (Wall Street Journal), 18 сентября 2000г.

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

Verizon Communications Inc: разработка ССП для управления персоналом

Подготовлено по материалам зарубежных сайтов
Перевод:
После принятия Акта о телекоммуникационных системах в 1996г. перед многими компаниями в США встала необходимость адаптации к новым условиям. Кроме того, теперь многие компании оказались вынуждены в прямом смысле бороться за каждого клиента. Джей Рендалл Макдоналд (J. Randall MacDonald), вице-президент HR-отдела (HR - Human Resources, персонал компании. Данный отдел занимается сотрудниками компании, а также всеми вопросами, связанными с управлением кадрами. - прим. перев.) компании GTE, которая в 2000г. должны была войти в состав корпорации Verizon Communications, понял, что в ближайшее время ситуация на рынке должна существенно измениться. В GTE работает больше 100000 сотрудников. Как и в большинстве крупных корпораций, эффективность работы HR-отдела оценивалась по "голому" количественному показателю - сколько человек было принято на работу, сколько тренингов и инструктажей было проведено, а вот качественная характеристика выполненной работы совсем не учитывалась. Главный исполнительный директор GTE четко сформулировал задачу, стоящую перед Макдоналдом: компания вкладывает значительные средства в HR-отдел, и он хочет знать, насколько эти затраты себя окупают.

Значимость персонала

Сотрудники GTE однозначно являются одним из ключевых факторов в успешном функционировании компании. Несмотря на то, что HR-отдел - это отдел, который напрямую связан с оказанием услуг клиентам, в компании не было никакой системы оценки эффективности отдела. А поскольку никаких доходов он не приносил, его сотрудники считались лишь дополнительной статьей в графе расходов.
Чарльз Ли (Charles Lee), главный исполнительный директор и председатель GTE, в основном занимался решением вопросов финансирования и планирования. В свете всех изменений, происходящих в данной отрасли, он, естественно, задавался вопросом о том, какую же роль играет HR-отдел в оптимизации деятельности компании. Ли напрямую заявил главе HR-отдела Джею Рендаллу Макдоналду: "Я понимаю, что вы работаете изо всех сил и тратите значительные средства. Вы предоставляете много специализированных отчетов о своей деятельности, например, количество сотрудников, которых вы взяли на работу в компанию, количество проведенных тренингов. Мы тратим около 75 миллионов долларов в год на обучение персонала. А что мы собственно получаем из этого? Большую производительность? Сокращение времени обработки заказов? Рост доходов?"
Макдоналд понимал, что ему необходима количественная модель оценки работы отдела, которая наглядно демонстрировала бы результаты его деятельности. Он обсуждал эту проблему со старшими менеджерами - функциональными специалистами внутри компании, и со внешними консультантами, специализирующимися на решении проблем, связанных с управлением кадрами. Пока у него не было четкого представления о том, какую же систему следует использовать. Но после того, как он прочитал книгу Роберта Каплана и Дэвида Нортона "The Balanced Scorecard", вышедшую в свет в 1996г., он подумал о том, что данную методику можно внедрить и успешно использовать в своем отделе.

Ccp_vnedrenie

Дополнительные связи.

Рабочая группа также попыталась найти дополнительные связи между вопросами, связанными с управлением персоналом и вопросами, связанными с оперативной и финансовой деятельностью компании. Это статистическое исследование достаточно высокой степени сложности было проведено группой "Оптимизация структуры компании" внутри HR-отдела. Целью исследования было продемонстрировать, как Индекс вовлеченности сотрудника (Employee Engagement Index - EEI) влияет на внутреннее функционирование компании, что, в свою очередь, влияет на Индекс обслуживания клиента и повышает рыночную стоимость акций компании. Также была создана более подробная модель связей, которая наглядно демонстрировала, как решение вопросов управления персоналом в HR-отделе будет способствовать решению корпоративных задач и повышению стоимости акций.

Индексация

С помощью ССП HR-отдел мог сводить результаты оценки совершенно различных видов деятельности в итоговый количественный показатель. Отделу было необходимо оценить общую деятельность по Оперативной перспективе (учитывая все факторы и показатели этой перспективы), например, в 85% или 110% по сравнению с какой-то контрольной точкой. Соответственно, общая оценка работы отдела (по всем перспективам), тогда составляла бы 90% или 115%. Для этого было необходимо решить две задачи:

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

Фактический доход в текущем периоде: 260000 долларов
Контрольная точка: 250000 долларов
Индекс: 100+ [ ((260000-250000)/250000)x100]=104%

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

Фактическое время в текущем периоде: 55 дней
Контрольная точка: 50 дней
Индекс: 100-[((55-50)/50)x100]=90%

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

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

На рис. 1 изображены некоторые из показателей по всем 4 перспективам.
Рис. 1.

Показатели

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

Занимают ли мои сотрудники должности, соответствующие их квалификации?

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

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

Члены рабочей группы расширили этот список вопросов для того, чтобы правильно оценить работу HR-отдела:

Окупает ли HR-отдел средства, затраченные на него?

Используется ли технология для повышения эффективности работы отдела?

Снижается ли уровень текучести кадров?

Каков коэффициент окупаемости инвестиций в персонал?

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

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

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

Первоначально ССП состояла из 118 показателей и включала в себя 400-500 информационных единиц. Одной из причин такого большого количества показателей было то, что при их определении был задействован так называемый "культурный" вопрос: Макдоналд полагал, что сотрудники отдела никогда не работали в соответствии с "оценочной культурой", поэтому было бы проще использовать большее число показателей.

Показатели были разделены на 4 перспективы: Стратегия, Клиент, Финансы и Оперативная. Еще одним достоинством разработанной ССП является то, что она достаточно проста (1 страница), и демонстрирует как отстающие, так и опережающие показатели, а также сфокусирована на основных факторах данного бизнеса и привязана к корпоративной стратегии.

Процесс пересмотра

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

Снижение количества прогулов.

Аналогичной проблемой было количество прогулов. Сотрудники HR-отдела уже давно занимались вопросом отсутствия персонала на рабочем месте без уважительных причин. Если уровень прогулов составлял 4%, то для компании в целом, это означало, что 10000-12000 человек ежедневно не выходят на работу. Гаррет Уолкер подсчитал, что для компании подобный показатель будет означать прямые убытки в размере 300 миллионов долларов в год (если учитывать все факторы, в том числе непрямые показатели снижения производительности, дополнительные сложности в управлении, то сумма убытков уже будет составлять 800 миллионов в год).
Для того, чтобы решить эту проблему нужно было решить ряд проблем. Одна из них заключалась в углубленном анализе данных (drill down). Если общий уровень прогулов составлял, допустим, 4%, то в некоторых регионах страны он составлял 10%, и именно там нужно было максимально тщательно изучать проблему. Второй аспект - это отношение менеджеров к данной проблеме. Некоторые менеджеры просто говорили, что прогуливают плохие, ненадежные сотрудники. Но с другой стороны, вполне вероятно, что какие-то объективные причины, такие, например, как уход за ребенком, нежелание руководства прислушиваться к мнению сотрудника, семейные проблемы, и т.д. вызывали прогулы. В этом случае, в интересах компании было решать данные проблемы. И хотя эта проблема еще не была тщательно изучена, Уолкер полагал, что снижение количества прогулов на 1% снизит расходы компании на 200 миллионов в год, за вычетом, разумеется, стоимости предпринятых мер.
Естественно, что при реализации каких-либо проектов необходимо соотносить расходы на осуществление с предполагаемым итоговым снижением расходов компании. Уолкер признал, что снизить расходы, связанные с текучестью кадров можно просто повысив в два раза заработную плату, или же снизив расходы на обучение персонала (что, в свою очередь, приведет к снижению компетентности сотрудников). Но и тот и другой способы отнюдь не являются решением проблемы.

Снижение уровня текучести кадров

В 1998г. был реализован проект по снижению уровня текучести кадров в колл-центрах (Call-center - отдел, по обработке звонков, поступающих от клиентов касательно сервисного обслуживания). В результате снижения текучести кадров на 1%, расходы компании снизились на 23.6 миллионов долларов в год:

Количество сотрудников отдела составляет около 1% всех сотрудников компании (710+179+59=968 человек). Эти сотрудники остались в компании. Их деятельность оценивалась достаточно высоко.

Исследование было проведено Saratoga Institute, консалтинговой компанией, специализирующейся на решении проблем, связанных с управлением кадрами. В соответствии с результатами исследования, затраты на замещение сотрудника менеджерского звена составляли 150% его годовой зарплаты, затраты на замещение рядового сотрудника - 50%. Эти деньги уходили на процедуру приема на работу, обучение и доведение производительности до требуемого уровня (общая стоимость затрат высчитывалась посредством умножения количества оставшихся сотрудников на 24400 долларов, средневзвешенную стоимость замещения сотрудника).

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

Связь с повышением мотивации персонала

Помимо всего вышеперечисленного, была установлена четкая связь между ССП и системой поощрений персонала. Гаррет Уолкер полагал, что иначе ССП станет просто очередным красивым и "модным", но бесполезным инструментом. В этом Макдоналд был с ним согласен. Поэтому, когда в 1999г. ССП была внедрена, премии для большинства сотрудников были установлены на уровне 10% от основной заработной платы, а для исполнительного звена - 25% или 40%. Половина всех компенсаций была тесно привязана к ССП-показателям, а другая половина зависела от общих финансовых показателей деятельности компании.
Естественно, это привлекло внимание людей, и некоторые сотрудники отдела были против введения этой системы. Они говорили, что некоторые показатели они просто не могут контролировать, на что Макдоналд отвечал: "Да, вы не можете контролировать, но вы можете на них повлиять".
Гаррет Уолкер полагал, что основным преимуществом ССП является оптимизация системы отчетности. В других отделах для выполнения конкретных задач назначались ответственные лица, а в HR-отделе - нет. ССП должна была изменить сложившуюся ситуацию. The BS was meant to change that. Так, если сотрудники отдела принимали на работу водителей грузовиков и обучали их, а потом резко возрастало число аварий, то ответственными были сотрудники из HR-отдела. Точно так же если приема на работу и обучались сотрудники из отдела клиентского обслуживания не справлялись со своими обязанностями, то исправлять ситуацию также должен был HR-отдел.
Гаррет Уолкер говорит: "Если вы проанализируете сложившуюся ситуацию, то вы увидите, что все цепочки начисления стоимости так или иначе связаны с этим отделом, и хотя он также является лишь одним из звеньев, не стоит недооценивать его значимость". Кроме того, ССП стимулирует обмен информацией и сотрудничество между сотрудниками как HR-отдела, так и разных отделов. Так, сотрудник из отдела по подбору персонала может обратиться к сотруднику отдела по связям с профсоюзами для того, чтобы проанализировать показатели недовольства персонала, так как деятельность второго сотрудника напрямую зависит от этих показателей.

Связь

Распространение полученных результатов внутри организации считалось одним из ключевых факторов, необходимых для успешного внедрения системы. Для этого в отдел было приобретено программное обеспечение, позволяющее создавать и ежеквартально публиковать отчеты в режиме онлайн. Информация передавалась всем сотрудникам отдела (более 2000 человек), а также директорам всех подразделений. Материал, публикуемый в режиме онлайн, включал в себя обобщенные результаты в форме графиков и диаграмм, удобных для просмотра. Цветовая кодировка показывала текущую оценку деятельности по отдельным и по обобщенным показателям (зеленый - превышение планируемого результата, желтый - в пределах допустимого, красный - недопустимый уровень). Сотрудники также могли найти конкретную информацию о том, как они справляются со своими обязанностями, выраженную как в абсолютных, так и в относительных показателях (относительно контрольных точек). Например, сотрудник мог получить информацию о том, что фактическое среднее время, необходимое для заполнения вакансии составляло 55 дней, или 90% от запланированного результата. Также сотрудники могли получать и анализировать данные за прошлые периоды. В течение года после внедрения ССП, программу еженедельно использовали более 100 человек.
Интегрированные данные. Одним из существенных преимуществ использованного программного обеспечения является то, что оно содержит слои иерархически взаимосвязанных данных. Это дает сотрудникам возможность просматривать данные "сверху вниз" или "снизу вверх". Например, если HR-менеджер захочет узнать о причинах того или иного явления, то он сможет сделать это, используя технологию углубленного анализа данных (drill down) посредством ряда внутрисетевых ссылок. Данная методика позволяет контролировать "красные" показатели (недопустимые результаты), работу ответственных лиц или групп, а также своевременно принимать меры для решения проблемы (технология углубленного анализа данных стала возможной благодаря использованию Хранилища данных, работающего с ERP-системой компании). Помимо выявления причин, сотрудники могут также просматривать данные "снизу вверх" и получать информацию о том, каков их вклад в достижение корпоративных стратегических целей.
Другие компьютерные файлы. HR-отдел также тесно сотрудничал с IT-отделом для того, чтобы разработать набор аудио и видео файлов, содержащих в доступной форме информацию о целях и возможностях ССП. Было также разработано специальное учебное пособие в режиме онлайн для того, чтобы наглядно продемонстрировать всем сотрудникам HR-отдела преимущества использования ССП.

Verizon Communications Inc: внедрение ССП для управления персоналом

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

Влияние ССП на доходы компании

Мнения тех, кто использует ССП, разделяются: некоторые считают, что можно установить прямую связь между определенными нефинансовыми показателями и доходами компании, другие считают, что нельзя. Гаррет Уолкер полагает, что в конечном итоге, ССП повысит доходы компании. До сих пор, HR-отдел не проводил тщательного исследования данной проблемы.

Дадим слово критикам

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

Использование специальной базы данных

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

Эффективность и производительность

Существует несколько научных школ, каждая из которых придерживается своего мнения насчет технологии Data Mining и ее эффективности. Некоторые специалисты по маркетингу и поставщики приложений считают средства Data Mining, которые редко работают в online-режиме, символом всего устаревшего. В такой форме DM можно использовать для создания широкого профиля определенных типов клиентов - для выяснения, например, что молодые люди в возрасте от 16 до 21 года предпочитают играть в видеоигры, а не посещать картинные галереи, - но ключевой информации о характере поведения конкретного человека эти средства не дают.
Другие разработчики считают, что средства Data Mining работают слишком медленно и не могут выполнять точный анализ и предлагать пользователю нужную услугу в тот момент, когда он находится на сайте поставщика.
"Другие возражения возникают против систем, основанных на правилах, которые выполняют Data Mining анализ на сервере", - утверждает Брэд Вилсон (Brad Wilson), вице-президент отдела маркетинга компании Epiphany, расположенной в городе Сан-Матео (San Mateo), штат Калифорния. Он даже припомнил историю одной фирмы, которая подсчитала, что для того чтобы отразить все возможности на их сайте, потребуется написать 90 тыс. правил для использования традиционных Data Mining методов. Компания решила остановиться на написании одной тысячи правил на первом этапе, учитывая при этом высокую вероятность ошибки. Однако тут еще надо было учесть, что правила пишутся людьми, а они могут быть необъективны.

Конфиденциальность

Одно из возражений против Data Mining звучит особенно громко. Сам по себе аналитический DM-процесс применяется к накопленным анонимным данным, при этом выявляются возможности использования, тенденции приобретения и десятки, если не сотни, других факторов. Но вот выполнение следующего этапа обработки данных - попытка связать их с характером поведения конкретного клиента, чтобы извлечь некий личный опыт взаимодействия с этим человеком, - вызывает настороженность среди поборников прав на неприкосновенность частной жизни.
Вопросы конфиденциальности информации представляют собой интересную задачку. Недавний опрос Harris Interactive показал, что потребители больше беспокоятся о своих правах на неприкосновенность частной жизни, чем о здоровье, налогах и преступлениях. С другой стороны, в одной из статей информационного ресурса ZDNet было отмечено, что лишь ничтожная часть потребителей, посещающих самые популярные сайты, обращает внимание на опубликованные правила, касающиеся конфиденциальности информации. За последний месяц только один из 500 тыс. посетителей сайта About.com щелкнул по соответствующей ссылке.
Защитники конфиденциальности говорят о том, как важно быть честными с клиентами и сообщать им о собираемых данных и целях их использования. "Конфиденциальность не всегда противоречит сбору данных, - поясняет Эндрю Шен (Andrew Shen), аналитик в компании Electronic Privacy Information Center (EPIC). - Всё сводится к тому, чтобы дать клиентам возможность управлять своими данными".
Директивы кажутся простыми, но на практике их реализация сложна. В целом они звучат так:

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

Дать возможность эту информацию о себе не указывать.

Обеспечить просмотр и корректировку личных сведений.
Поставщики ПО для Data Mining решили пойти самым трудным путем, пропагандируя возможность клиентов выполнять директивы EPIC.

Мнение экспертов

Полезно узнать, каково же мнение экспертов относительно этой новой технологии. Приведем несколько кратких цитат наиболее влиятельных членов бизнес-сообществ.
Руководство по приобретению продуктов Data Mining (Enterprise Data Mining Buying Guide) компании Aberdeen Group: "Data Mining - технология добычи полезной информации из баз данных. Однако в связи с существенными различиями между инструментами, опытом и финансовым состоянием поставщиков продуктов, предприятиям необходимо тщательно оценивать предполагаемых разработчиков Data Mining и партнеров.
Чтобы максимально использовать мощность масштабируемых инструментов Data Mining коммерческого уровня, предприятию необходимо выбрать, очистить и преобразовать данные, иногда интегрировать информацию, добытую из внешних источников и установить специальную среду для работы Data Mining алгоритмов.
Результаты Data Mining в большой мере зависят от уровня подготовки данных, а не от "чудесных возможностей" некоего алгоритма или набора алгоритмов. Около 75% работы над Data Mining состоит в сборе данных, который совершается еще до того, как запускаются сами инструменты. Неграмотно применив некоторые инструменты, предприятие может бессмысленно растратить свой потенциал, а иногда и миллионы долларов".
Мнение Херба Эдельштайна (Herb Edelstein), известного в мире эксперта в области Data Mining, Хранилищ данных и CRM: "Недавнее исследование компании Two Crows показало, что Data Mining находится все еще на ранней стадии развития. Многие организации интересуются этой технологией, но лишь некоторые активно внедряют такие проекты. Удалось выяснить еще один важный момент: процесс реализации Data Mining на практике оказывается более сложным, чем ожидается.
IT-команды увлеклись мифом о том, что средства Data Mining просты в использовании. Предполагается, что достаточно запустить такой инструмент на терабайтной базе данных, и моментально появится полезная информация. На самом деле, успешный Data Mining проект требует понимания сути деятельности, знания данных и инструментов, а также процесса анализа данных".

Несоответствие результатов прогнозирования реальной ситуации

Есть одна сложнейшая задача, вставшая перед Data Mining, которую многие эксперты считают неразрешимой и которая оправдывает тот скептицизм, который часто слышен в адрес этой ниши рынка. Средства Data Mining хорошо прогнозируют поведение потребителя на основе данных за прошлые периоды, то есть дают информацию о том, что человек, исходя из его предыдущих приобретений, демографических данных и других параметров, захочет купить с наибольшей вероятностью. Но, по мнению критиков, DM никогда четко не предскажет, что же человек захочет купить на самом деле.
Например, DM-приложение может определить, что 34-х летная домохозяйка, имеющая двоих детей, вероятнее всего каждые три года в ближайшее десятилетие будет покупать отдельную микроволновую печку. Но такое ПО не может определить, что именно эта клиентка скорее купила бы более дорогую печь, где комбинируются микроволновый и конвекционный режимы, если бы та подошла ее по цене.
Кайл Джонстон (Kyle Johnstone), руководитель BI- компании Emerald Solutions утверждает, что для повышения прибыльности (т. е. достижения основной цели маркетинга) в первую очередь нужно не столько просто узнать, чем человек довольствуется сейчас, сколько выяснить, а что он купит охотнее всего. Единственный способ решить эту задачу - спросить у клиентов, чего же они действительно хотят, а не рассчитывать на информацию о характере их прежних приобретений.
"Люди будут утверждать, что любят бифштексы, но для вечеринки в честь Дня Независимости покупают гамбургеры. Есть некоторое несоответствие между тем, что человек покупает, и тем, чего он хочет", - поясняет он. - Можно вычислить характер поведения показателей эффективности, но главной частички головоломки - знания того, чего же хочет клиент - всё равно будет не хватать. Математически это определить невозможно".

Опытность пользователя

Различные инструменты Data Mining имеют свои сильные и слабые стороны. Поэтому конкретные программы должны четко соответствовать уровню подготовленности пользователя и его конкретным целям. Кроме того, Data Mining, как правило, подразумевает употребление определенного технического жаргона, который может сильно усложнить для неопытного пользователя понимание работы программы, ее сути, практических результатов, а также того, какой продукт и каким способом лучше всего использовать для достижения определенных бизнес-целей. Это вызывает замешательство, и часто потенциальный клиент может вообще отказаться от использования Data Mining. Еще хуже если клиент вложит большие средства и пойдет неверным путем или потратит деньги на освоение различных инструментов для того, чтобы, наконец, понять, как нужно было применять Data Mining в данной области деятельности.
"Если Data Mining применяется неправильно, это может разорить компанию", - утверждает Джеф Харибсон, главный администратор компании Elity Systems, занимающейся технологией персонификации. - Использование Data Mining должно быть неразрывно связано с повышением квалификации пользователя".
"Очевидно, что необходимы хорошие специалисты, и применение сложных инструментов предъявляет все большие требования к людям, которые необходимы компании, - указывает Мэри Келли (Mary Kelley), вице-президент отдела маркетинга компании Charles Schwab & Co. "Однако специалистов по Data Mining, которые бы хорошо разбирались в бизнесе, очень не много", - добавила она.
Извлечение полезных сведений невозможно без хорошего понимания сути данных. Кроме того, во многих случаях необходима тщательная интерпретация тех зависимостей или шаблонов, которые были обнаружены. Поэтому работа с этими средствами требует тесного сотрудничества между бизнес-экспертом и специалистом по инструментам Data Mining.
Правильное использование прогнозирующих моделей должно быть грамотно интегрировано в реальные бизнес процессы, с тем, чтобы можно было четко оценивать и обновлять модели.

Проблемы

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

Сложность инструментов

"Сложность - существенный барьер для внедрения Data Mining", - утверждает Грегори Пиатецкий-Шапиро (Gregory Piatetsky-Shapiro), руководитель проекта в исследовательской лаборатории корпорации GTE. - Большинству пользователей не нужен реактивный двигатель. Им нужен всего лишь автомобиль с водителем, который доставит их из пункта A в пункт B".
Есть и такие шутливые мнения, что Data Mining - настолько сложная технология, что для ее освоения необходимо иметь чуть ли не три высших образования: одно в области статистики или вычислительных методов, другое в области бизнесе, чтобы понимать клиентов, и еще одно по вычислительной технике.
Фактически Data Mining - это результат совместных усилий специалистов во всех трех областях. Управление проектом должны брать на себя бизнес-специалисты, задачей которых является формирование набора бизнес-целей (бизнес-задач) и последующая интерпретация полученных результатов. Разработчик-аналитик, разбирающийся в методах Data Mining, в статистике и инструментах должен создать надежную модель. А специалисты по информационным технологиям обеспечивают обработку данных, а также техническую поддержку.

Трудозатраты

Успешный анализ требует очищенных и подготовленных данных. По утверждению аналитиков и пользователей очистка клиентских записей, разделение их на поддающиеся обработке, но статистически достоверные образцы, а затем тестирование и уточнение всех результатов, занимает до 80% процентов всего DM-процесса.
Таким образом, чтобы заставить технологию работать на себя потребуется много времени. Много усилий тратится на анализ предварительных данных и корректировку прогнозирующих моделей.
"Такая работа не очень хорошо идет на эмоциях, а маркетинг часто связан именно с эмоциями, - говорит Мэри Кэлли. - Иногда нужно глубоко вздохнуть и сказать: лучше еще раз это перепроверить".

Высокая стоимость

Хорошая Data Mining программа обходится в сумму от 500 тыс. до 1,5 млн. долл., которая необходима на программное, аппаратное обеспечение и техническую поддержку. Вкладывая средства в такой проект, необходимо убедиться, что эффективность инвестиций будет достаточно высокой. Неплохой проверкой является небольшой DM-проект (от 100 тыс. до 200 тыс. долл.), который позволит выяснить, достаточно ли того объема и качества данных, которые имеются в наличии, чтобы сделать Data Mining полезным для предприятия.
Рынок Data Mining растет. Однако программные инструменты составляют всего лишь 15%. Большая часть средств идет сервисным бюро и системным интеграторам, которые "защищают" пользователей от сложностей технологии.
"Необходимость в сторонней помощи и мощном оборудовании приводит к росту расходов на внедрение Data Mining до 2 млн. долларов и выше" - заключает Херб Эдельштайн, сотрудник компании Two Crows, - За эти деньги поставщики часто продают такую идею: Data Mining дает глубокие знания, которые постоянно приводят к "прорывам" в бизнесе. Однако это не так".

Высокий процент ложных результатов

Инструменты, занимающиеся поиском труднообнаруживаемых зависимостей в базах данных, могут раскрыть действительно драгоценные "самородки" информации, которые дадут хорошие дивиденды в плане финансовой и конкурентной выгоды. Средства Data Mining часто представляются "волшебным ящичком", куда "насыпают" еще не обработанные данные, а "высыпают" уже готовое бизнес-решение. Увы, это не так.
Data Mining, к сожалению, очень часто порождает множество вводящих в заблуждение и не имеющих существенного значения открытий. Многие пользователи и аналитики утверждают, что DM-средства могут выдавать тысячи ложных, статистически недостоверных или бессмысленных результатов. При этом пользователь должен понимать, какие из результатов имеют реальный смысл.
Некоторые ученые предупреждают, что общепринятые методы DM только "упрощают до абсурда" сложное искусство анализа и могут привести к неправильным выводам.
Джону Суоми (John Suomu) раньше представлялось, что с помощью его DM-инструмента удастся получить важные результаты. Казалось, программа обнаружила группу невыгодных клиентов, которые не стоили времени и средств туристической компании, где работал Суоми. Однако проверка показала, что такой результат связан с противоречивостью данных. Открытие оказалось ложным. "Мы подумали, что целый ряд людей - совершенно неподходящие для нас клиенты, хотя на самом деле это было не так", - признается маркетолог Суоми.
"Часто обнаруживаются странные вещи, и в 99,9% случаев они оказываются ложными", - утверждает Майк Айхорст, вице-президент отдела прогнозирования и Data Mining в компании Chase Manhattan Bank. - Постоянно попадаешь в тупик".
DM-инструмент может давать совершенно нелепые результаты, например: "Доктора, покупающие красные "Порше", составляют группу высокого риска невыплаты кредитов, а мужчины-курильщики из определенных районов оказываются выгодными клиентами". "Но такие утверждения могут быть основаны всего лишь на нескольких случайных примерах. А встроенных проверок нет" - объясняет Айхорст.
Например, компания Chase Manhattan, однажды получила неверное значение для среднего баланса нескольких клиентов, пользующихся кредитными картами. Причина оказалась в том, что данные были некорректно переданы. Неправильная сортировка файлов привела к тому, что в качестве прогнозирующего параметра, определяющего интерес клиентов к планируемой маркетинговой кампании, были выбраны идентификаторы клиентов. Конечно, такой результат не имел никакого смысла.
Дэвид Лейнвебер (David Leinweber), управляющий директор в компании First Quadrant, вспоминает, что ему встречались результаты анализа данных, связывавшие эффективность акций с их серийными номерами: "Технология Data Mining раньше применялась на свой страх и риск, а теперь внедряются готовые DM-продукты".

И всё же, несмотря на

И всё же, несмотря на множество рассмотренных недостатков и проблем, связанных с Data Mining, всё больше и больше программных продуктов этого класса находят свое применение.
Ловушки Data Mining не остановили компанию Chase Manhattan, положившуюся на новые методы. Кредитное подразделение, которое работает с более 25-ю миллионами американских семей, использует множество автоматизированных инструментов для изучения характера покупательского поведения клиентов, кредитных рисков и других стратегически важных моментов.
Конкурентные преимущества, которые дает Data Mining, не позволяют игнорировать эту технологию. Но, чтобы получить полезные результаты требуются детальные знания данных и длительные проверки методом "проб и ошибок".
Специалисты, чувствующие высокий коммерческий потенциал средств Data Mining, рассматривают их не только в черно-белых красках. Они видят и другие цвета, полагая, что научный потенциал здесь дает "зеленый свет" для расширения границ применения технологии и влияния на прибыльность бизнеса.
Очевидно, что идея, лежащая в основе этой технологии, имеют массу плюсов. А критики заслуживают отдельные методы ее реализации.

Банк Wells Fargo

Банк Wells Fargo, главный офис которого находится в Сан-Франциско, был вторым по величине банком в Калифорнии и одним из крупнейших в США, его активы в 1997 году составили около 100 млрд. долларов. Банк обслуживал около 10 млн. клиентов в 10 западных штатах: Аризоне, Калифорнии, Колорадо, Айдахо, Неваде, Нью-Мексико, Орегоне, Техасе, Юте и Вашингтоне. К декабрю 1997 в банке насчитывалось около 1900 розничных отделений и 4 400 банкоматов, в том числе 1295 автоматов, которые были приобретены при поглощении компании First Interstate Bancorp в апреле 1996 года (сумма сделки 11, 6 млрд. долларов).
Банк Wells Fargo был хорошо известен в своей отрасли внедрением инноваций и управлением затратами. В большинстве случаев эти мероприятия были взаимосвязаны: часто нововведения позволяли банку сократить оперативные расходы. Что касается нововведений, то Wells Fargo был одним из первых банков в США, который продлил рабочий день и ввел рабочие часы по субботам, а также предложил нетрадиционные каналы предоставления услуг, например установку банкоматов в продуктовых магазинах. Их установка потребовала меньше средств и расходов для поддержки, чем для стандартных автономных аппаратов. Банк также занимал лидирующее положение в тестировании новых методов предоставления розничных услуг, например, создал банковский центр «универсального обслуживания» («one-stop-shopping»), в составе которого под одной крышей объединились: банковское отделение, предлагающее полный набор услуг, кафе Starbucks, химчистка и фотокопировальная служба. Управление расходами в компании проводилось под руководством Карла Рейчардта (Carl Reichardt), который находился в должности председателя правления с 1983 по 1994 годы, и сформировал в банке особую культуру управления, которую можно было бы охарактеризовать следующим лозунгом: «Ведите бизнес так, как будто он принадлежит вам».
Целенаправленное сокращение расходов потребовало от банка отказа от деятельности в тех сферах, где доходы не соответствовали его целям. Например, банк продал портфель жилищных ипотечных кредитов в 1994 году, так как на уровень процентов по кредитам негативно повлияли региональные ставки на ссуды и сбережения. Приобретение компании First Intersate также было попыткой повысить производительность за счет консолидации накладных расходов и закрытия более 300 лишних отделений.

Электронная банковская деятельность

Понятие электронной банковской деятельности подразумевает два вида услуг, которые позволяют потребителям осуществлять доступ к банковским счетам и выполнять операции, используя компьютер. Банковские операции на ПК предполагают использование клиентом программного обеспечения банка или собственного финансового программного пакета, такого как Money или Quicken для доступа к банковской сети через модем. Интернет позволил клиентам осуществлять доступ к информации о банковском счете через всемирную сеть, непосредственно через Web-страницу банка с помощью Web-браузера, такого как Netscape Navigator или Microsoft Internet Explorer.
Если согласно оценкам, в 1994 году только 250000 американских семей пользовались электронными банковскими услугами для доступа к счетам или оплаты векселей, то к 1997 году эта цифра возросла до 4,5 млн., что составило 4,5 % всех семей США. К 2000 году эксперты прогнозировали, что более 17 млн. семей будут использовать электронные банковские операции (см. таблицу 1, где приводится прогноз использования электронных услуг). Развитие электронного банковского обслуживания обусловлено ростом количества домашних ПК, которое повысилось с 78 млн. до 95 млн., то есть ежегодный прирост составил 10%. Более того, именно выполнение личных финансовых операций стало основным применением домашних ПК, опережая использование электронных таблиц и выполнение дома незаконченной в офисе работы.
. Пользователи оперативных банковских услуг и услуг оплаты векселей
Использование интернет в Соединенных Штатах тоже быстро возросло с 1996 по 1997 год — с 34 миллионов взрослых пользователей старше 16-ти лет до 50 миллионов в начале 1997 года. К концу 1997 года 2700 банков и кредитных союзов разработали свои Web-сайты. Тем не менее, большинство из них предоставляли только стандартную, пакетную маркетинговую информацию, и лишь 6% обеспечили пользователям прямой доступ к банковским счетам.

Коммерческие банки

В конце 80-х коммерческая банковская отрасль вступила в период всеобщей консолидации, так как Конгресс, Федеральный резерв и другие правительственные учреждения США снизили барьеры, которые прежде разделяли различные части сферы финансовых услуг. За счет этого стерлись границы между банками, брокерскими фирмами, страхователями, финансовыми компаниями и эмитентами кредитных карт. Наиболее важные изменения произошли после того, как в 1994 году Конгресс выпустил законопроект, разрешающий осуществление полномасштабной банковской деятельности между штатами, а Федеральное резервное управление в 1996 году подняло лимит на объем страховой деятельности, которую мог теперь выполнять филиал банка, с 10% до 25% (от общего дохода). К середине 90-х коммерческие банки имели возможность продавать облигации и взаимные фонды, инвестиционные банки предлагали кредитные лимиты, а эмитенты кредитных карт получили право предоставления страховых услуг. После ряда поглощений и слияний конкуренция в финансовой отрасли еще больше возросла, так как повысились доходы за счет роста масштабов компаний. В 90-е годы некоторые из давно известных коммерческих кредитных учреждений объединились с другими компаниями или были поглощены. К числу таких случаев относятся: объединение Chemical Bank и Manufacturer Hanover в 1991 году, составившее 2,3 млрд. долларов, а также поглощение на сумму 4 млрд. долларов банком BankAmerica компании Security Pacific в 1992 году, объединение Chase Manhattan с банком Chemical Bank на сумму 10 млрд.долларов в 1995 году и поглощение банком Wells Fargo компании First Interstate в 1996 году на 11, 6 млрд. долларов.
Фактически из 13 сделок поглощения и объединения, объявленных в 1997 году, в 6 были вовлечены разные финансовые структуры, из них 3 — коммерческие банки, в том числе банк NationsBank поглотил Barnett Banks на 13,8 млрд. долларов, а Bane One поглотил First USA на 7, 3 млрд. долларов.

Необходимость в новом подходе

Корпоративная идеология в Wells Fargo основывалась на финансовых показателях. Традиционные финансовые характеристики использовались для контроля эффективности на всех уровнях внутри организации. Однако руководство OFS решило, что сами по себе финансовые параметры не позволяют эффективно оценить стратегию и донести ее до сотрудников. Если полагаться исключительно на финансовые показатели, то решения можно принимать только на ближайшую перспективу, например, вынуждено сокращать расходы, в то время как оперативные услуги требуют долгосрочного стратегического рассмотрения в масштабах банка. Подразделение OFS полагало, что оперативные банковские операции не только дают возможность существенного сокращения расходов, но и эффективный путь поиска и сохранения клиентов в течение долгого времени. Стало ясно, что не сдерживание и сокращение затрат, а будущие потенциальные преимущества оправдывают увеличение инвестиций в эту сферу. Мэри Д’Агостино комментирует ситуацию так:
«В Wells Fargo обычно используются финансовые показатели — как выглядит отчет о прибылях и убытках, как эти показатели согласуются с планом. Однако, если смотреть на бизнес только с финансовой точки зрения, то есть риск принимать не самые удачные решения, особенно в области оперативных финансовых услуг. Наш отдел относят к центрам затрат, и никто не хочет вкладывать средства в такое подразделение, если нет гарантии, что в результате не будет получена существенная выгода. Если исходить из таких предпосылок, то новые технологии или продукты разрабатываться не будут. Единственной целью останется сокращение издержек».
Кроме того, в отличие от других отделов банка, отдел OFS работал на рынке, который ежедневно претерпевал огромные изменения. Компании, использующие современные технологии, часто замечают, что все изменения происходят с «интернет-скоростью», то есть в 7-10 раз быстрее, чем при обычном выполнении финансовых бизнес-операций. OFS-подразделение обнаружило, что из-за постоянно меняющейся конкурентной ситуации на интернет-рынке приоритеты проектов постоянно меняются в зависимости от преимуществ и возможностей вновь появляющихся технологий.

Это связано с необходимостью постоянно « отражать угрозы» со стороны конкурентов и соответствовать требованиям клиентов. Мэри Д’Агостино размышляет об этом так:

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

По мере того, как важность оперативных банковских услуг возрастала, все острее вставала необходимость в выработке набора объективных показателей, связанных с стратегией подразделения OFS. Дудлей Нигг вспоминает:

«В начале оперативный канал рассматривался как в той или иной мере исследовательский проект. Цель была только в том, чтобы понять, как он работает, развить его и выяснить возможности использования. По определению исследовательский проект гибок. Для развития ему необходима свобода. Однако если 450000 лучших клиентов переходит на новый канал, то уже нельзя надеяться на случай — необходима определенная доля дисциплины. Нам всегда удавалось ясно изложить оперативную составляющую банковской деятельности в Wells Fargo, однако возникали трудности с эффективной ее реализацией. Необходим был механизм, который гарантировал бы, что наши планы соответствуют нашему представлению, кроме того, нам требовался набор четко сформулированных объективных показателей эффективности. В интернет-пространстве все является новшеством. И нам нужен был хороший способ, выявляющий какие методы помогают в достижении целей, а какие нет».

Online клиенты Wells Fargo

Банковские online услуги Wells Fargo были направлены на сегмент привлекательных клиентов. Такие клиенты имели ряд общих характеристик: средний возраст — 38 лет, доход– от 75 000 до 100 000 долларов, состояние — на стадии накопления, займы — средние и крупные суммы (личные займы, кредитные карты и автомобильные кредиты). Их поведение как клиентов банка обеспечивало три из четырех основных элементов, составляющих бизнес-основу для оперативных финансовых услуг. Во-первых, период сотрудничества клиента с банком дольше среднего — процент ухода к конкурентам online-клиентов на 50% ниже, чем в среднем по банку. Во-вторых, возможность перекрестных продаж для online-клиентов больше, так как они в среднем пользуются большим количеством услуг, чем обычный клиент. В третьих, такие пользователи выгоднее, так как вкладывают и занимают более крупные суммы. Четвертый фактор связан не с активностью клиентов, а с переходом клиентов Wells Fargo на менее затратные каналы, по сравнению с обслуживанием в отделениях, по телефону или через банкоматы. По оценкам Американской банковской ассоциации, online-операция обходится в 0, 01 доллара, тогда как операция с банкоматом — 0, 27 доллара, по телефону — 0, 54, а в отделении банка — 1, 07 доллара.

Оперативные финансовые услуги Wells Fargo: поиск нового подхода

Подготовлено по материалам зарубежных сайтов
Перевод:
Мэри Д’Агостино (Mary D'Agostino), вице-президент и директор по финансам, стратегии и планированию подразделения, занимающегося представлением оперативных финансовых услуг Online Financial Services group, OFS) в компании Wells Fargo, направилась в свой офис после семинара, продолжавшегося полдня в декабре 1997 года. На этом мероприятии управление, работающее над проектом создания сбалансированной системы показателей (СПП — balanced scorecard BSC), обсуждало и, наконец, утвердило основные показатели эффективности для семи целей, лежащих в основе одной из стратегических задач OFS: находить и сохранять ценных и потенциально выгодных клиентов. Мэри была поражена тем, насколько изменилось понимание сотрудниками своего бизнеса, хотя сбалансированная система показателей еще не была закончена.Если до этого подразделение OFS в оценке эффективности в основном ориентировалось на финансовые показатели — что было характерно для работы Wells Fargo в целом — то теперь сотрудники стали рассматривать производительность под разными углами. Мэри Д’Агостино убедилась, что новая система поможет OFS контролировать, как реализуется недавно разработанная стратегия, и сообщать о результатах как внутри OFS-отдела, так и по всему банку. Д’Агостино так характеризует новый подход:
«Этот набор показателей вскрывает суть бизнес-ситуации в отделе OFS. Мы еще никогда систематически не контролировали и не обобщали данные о тех факторах, которые лежат в основе нашего бизнеса. Сбалансированная система показателей поможет понять, что происходит с нашими клиентами и нашими внутренними операциями, а также будет очень полезна для ежемесячного анализа информации. Мы не получили бы такой картины, рассматривая только лишь цифры доходов и расходов».
Д’Агостино с нетерпением ожидала очередной встречи на следующей неделе, где должны были обсуждаться цели и показатели для двух других стратегических задач.

Оперативные финансовые услуги Wells Fargo

В 1989 году банк Wells Fargo впервые ввел электронную услугу, обеспечивавшую доступ к личным счетам через оперативную информационную службу Prodigy. Вскоре после этого Wells Fargo разработал собственную систему, работавшую в операционной системе DOS. Однако к концу 1994 года только 20 000 клиентов использовали эти две услуги, что потребовало от банка начать поиск путей совершенствования оперативных банковских операций (в Wells Fargo принято называть все электронные услуги оперативными — online). В это время подразделение OFS состояло из 75 человек, все они перешли на эту работу из других подразделений банка. В декабре 1994 года отдел маркетинга запустил в работу Web-сайт, который стал частью кампании по продвижению банка в целом. Изначально на сайте была представлена только стандартная маркетинговая информация. Однако вскоре клиенты стали просить предоставления прямого доступа к счетам.
Карен Дерр Гилберт (Karen Derr Gilbert), вице-президент маркетинга OFS вспоминает:
«Мы рассмотрели пожелания клиентов и спросили сотрудников технического отдела: «Можно ли это реализовать?» В мае 1995 года архив данных о балансах и счетах стали доступны клиентам через Web-сайты. Это было уникальным явлением, так как этот процесс управлялся только клиентами».
Wells Fargo стал первым крупным американским банком, предложившим Интернет-доступ (см. таблицу 2). Отклик превзошел все ожидания — более 10 000 клиентов Wells Fargo в первые же два месяца после запуска проекта стали просматривать свои счета через Internet. Дудлей Нигг (Dudley Nigg), исполнительный вице-президент OFS, так оценивает решение внедрить Интернет-услуги:
«В последние годы банки гораздо больше внимания уделяют клиентам. Эта тенденция появилась 15 лет назад, когда в ответ на требование потребителей создать более удобные условия и быстрый доступ, был продлен рабочий день и расширен набор услуг. Мы поняли, что клиенты считают банковские операции неприятным занятием, что заставило нас упростить их. Мы начали изучать более удобные каналы.

Поиск наиболее подходящих для клиента условий проводился среди целого спектра возможностей, в том числе: открывались новые отделения, выполнялись операции по телефону, устанавливались банкоматы. Затем этот спектр был расширен до удаленных средств. В 1994 году все большее количество клиентов находило оперативный канал очень привлекательным, и мы пришли к выводу, что компания Wells Fargo должна активно его предлагать. Как раз в это время ряд обстоятельств способствовали развитию Интернет-услуг: в первую очередь распространение ПК позволило многим людям осуществлять доступ к оперативным банковским услугам. Фактически мы «догоняли» технологии — большинство наших клиентов уже имели ПК и доступ в Интернет, но не многие пользовались оперативными банковскими услугами, поэтому мы просто воспользовались сложившейся ситуацией. И, во-вторых, Интернет приобрел огромную важность гораздо быстрее, чем мы предполагали, особенно здесь на Западном берегу».

Таблица 2 Оперативные банковские услуги в Интернете по 10 самым крупным банкам США от 3/17/98 (проранжированы по активам 1996 года)

Ранг	Банк	Интернет-доступ к счетам	Год внедрения
1	Chase	Нет	—
2	Citicorp	Да	1997
3	Bank of America	Да	1996
4	NationsBank	Да	1998
5	J.P. Morgan	Нет	—
6	First Union	Да	1996
7	Bankers Trust	Нет	—
8	Wells Fargo	Да	1995
9	First Chicago NBD	Нет	—
10	Bane One	Да	1997

Источник: Отчет об оперативных банковских услугах

К 1998 году, Wells Fargo реализовал Интернет-сервис, доступный по адресу , с помощью которого клиенты могли в оперативном режиме выполнять многие банковские операции, например: проверять текущий счет и баланс кредитной карты, оплачивать векселя, переводить фонды, проводить продажу акций и облигаций, заказывать чеки и получать информацию об услугах. Ранее, Web-сайт Wells Fargo уже получил широкое одобрение среди обозревателей отрасли: журнал Smart Money назвал Wells Fargo «Лучшим online-банком» в 1996 году, Ассоциация оперативных банковских услуг посчитала сайт Wells Fargo «Лучшим сайтом в финансовой индустрии США» в 1996 году, а Financial Net News удостоил его звания «Лучшего из банков» в 1997 году.

К началу 1998 году более 450 000 клиентов Wells Fargo использовали банковские услуги online, и компания подсчитала, что это число в течение двух лет должно возрасти до 1 миллиона. К началу 1998 года интернет-сервис Wells Fargo применялся 350 000 online-клиентами; прогнозировалось, что основной рост числа потребителей обеспечит именно этот канал, так, банк регистрировал около 1000 клиентов в день, причем более 80% обращались через интернет.

Достигнув к 1997 году определенных преимуществ как новатор, банк Wells Fargo получил существенную часть всех электронных банковских пользователей в США. Обслуживание или повышение этой доли стало трудной задачей, так как другие банки, кредитные союзы, брокерские фирмы, страховые компании и даже нефинансовые учреждения также вышли на электронный банковский рынок. В результате, стратегией Wells Fargo на ближайший период времени стало стремление заполучить как можно больше клиентов и как можно быстрее. Исходя из этой стратегии, банк Wells Fargo вскоре сосредоточился на проектировании новых услуг, с тем, чтобы удовлетворить потребности клиентов, пользующихся WebTV, сотовыми телефонами Nokia Internet, а также другими устройствами доступа к всемирной сети. Это была попытка найти клиентов в любом месте, где они могли осуществить свои банковские операции.

Организация оперативных финансовых услуг

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

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

Сотрудники получали фиксированную зарплату, в зависимости от квалификации и области деятельности. Цель состояла в том, чтобы переадресовать большинство клиентов к специалистам, занимающимся поддержкой по электронной почте.
OFS-отдел рассматривался как центр затрат (cost center). Это подразделение пыталось возместить затраты на оборудование, сотрудников и маркетинговые программы, получая оплату за свои услуги от других отделов банка. OFS использовала две основные структуры списывания расходов на производственные отделы банка: один вид оплаты взимался за сессию обслуживания, когда клиент входил в систему, чтобы получить только информацию (не выполняя операций), второй вид оплаты взыскивался при выполнении транзакции. Например, если чековый вкладчик вошел в интернет-службу банка, чтобы посмотреть остаток на счете, то эта услуга передавалась к оплате подразделению, занимающемуся чековыми операциями. Сопротивления со стороны других отделов банка не было, так как оперативные банковские услуги оказались более дешевым каналом обслуживания, чем другие. Единственные прямые источники доходов отдела OFS — небольшой объем выплат за услугу оплаты векселей в тех случаях, когда клиенты не удовлетворяли требованию минимального остатка на счете, а также плата за доступ из систем Money и Quicken и премии от третьих фирм (например интернет-провайдеров) за поиск клиентов через совместные маркетинговые программы. Любые другие доходы, полученные от банковского обслуживания клиентов, такие как продажа новых продуктов или рост счетов, относились на счет соответствующего подразделения банка. Согласно модели возмещения издержек, прогнозировалось, что OFS-подразделение прекратит свое существование в 2000 году.

Оперативные финансовые услуги Wells Fargo: реализация системы сбалансированных показателей

Подготовлено по материалам зарубежных сайтов
Перевод:
Подразделение OFS узнало о сбалансированной системе показателей во время обсуждения, которое проводил соавтор этой концепции и один из руководителей консалтинговой компании Renaissance Worldwide (расположенной в штате Массачусетс) Дэвид Нортон (David Norton). Дудлей Нигг и руководство Wells Fargo были впечатлены новым подходом, предлагающим интеграцию набора многомерных показателей для оценки достижения поставленных целей. Дудлей Нигг вспоминает решение реализовать систему сбалансированных показателей так: «Мы рассмотрели ряд инструментов, но остановились на ССП по двум основным причинам. Во-первых, нам понравилась идея сбалансированности. Большинство изученных инструментов не делали акцента на балансе между различными составляющими успеха. Они в основном были нацелены на одну из функций – финансовую или операционную, или на человеческие ресурсы. Во-вторых, эти средства не выделяли количественные показатели для оценки эффективности бизнеса, как это делается в ССП. Эти две уникальные особенности сбалансированной системы привели нас к выводу, что «в этом есть смысл». В сентябре 1997 года после принятия решения о реализации концепции компания Renaissance начала совместную работу с OFS по разработке системы сбалансированных показателей. Дудлей Нигг собрал из сотрудников OFS-отдела команду для работы над проектом. Она состояла из 5 официальных руководителей из OFS и межфункциональной группы менеджеров среднего звена. Мэри Д’Агостино была назначена главой проекта. Дудлей Нигг так оценивает важность участия менеджмента в этом процессе: «Не думаю, что руководство могло бы разработать хорошую ССП, даже если бы у него было желание. Определенного уровня детализации и глубины от высшего руководства невозможно добиться. Поэтому необходимо было участие в этом процессе управленцев среднего звена. Кроме того, это было важно и с точки зрения участия в деятельности компании в целом: Кроме того, это было важно и с точки зрения участия в деятельности компании в целом: сотрудники не поверили бы в идею, если бы сами не являлись ее авторами». Первый шаг процесса состоял в утверждении трех стратегических задачи, разработанных ранее подразделением OFS, на этапе планирования:

Находить и сохранять ценных и потенциально выгодных клиентов

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

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

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

Подразделение обсуждало вопрос, отражают ли эти три задачи тот объем деятельности, который необходимо выполнить в ближайшие 3-4 года для поддержания лидирующего положения на рынке оперативных финансовых услуг. Вскоре участники пришли к выводу, что трех задач достаточно для формулировки общей стратегии. Затем сотрудники приняли участие в серии семинаров по разработке полного набора целей, связанных с каждой из стратегических задач по четырем направлениям сбалансированной системы показателей (финансовому, клиентскому, внутренних бизнес процессов и по направлению обучения и развития). Подразделение старалось тщательно рассмотреть каждую из целей, чтобы убедиться в ее важности и возможности количественной оценки. При этом не все данные для количественного измерения были в тот момент доступны для OFS. Основной принцип отбора состоял в том, чтобы цель поддавалась хоть какой-нибудь оценке. Следующий этап состоял в разработке «схемы связей», где были бы отражены внутренние взаимосвязи между каждой из целей и стратегическими задачами (см. рис. 1). Этот шаг был очень непростым и занял много времени. Руководитель отдела маркетинга Карен Гилберт так вспоминает о нем: «На правильную разработку схемы связей мы потратили несколько недель.

Каждый раз обсуждалось, соответствует ли цель схеме. Часто дискуссии были горячими. Однако для нас было важно провести диспут, так как в результате каждый увидел, насколько все цели взаимосвязаны. В конце концов, этот процесс оказался очень полезным. Все только выиграли от возможности вместе обсудить сложные вопросы, которые возникли перед нашим отделом.» Рис.1.

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

привлечь и сохранить сотрудников и основных работников OFS;

развить потенциальные возможности OFS и планирование преемственности;

повысить управленческую и техническую компетентность на всех уровнях;

продолжить разработку организации и идеологии OFS;

разработать ССП и внедрить ее в OFS.

Подразделение считало, что эти цели необходимы для достижения каждой из основных стратегических задач. А следовательно, цели развития и обучения нужно рассматривать как независимые факторы, влияющие на все три задачи, а не выделять из них подмножества, связанные с каждой задачей в отдельности. После разработки схемы связей подразделение разбилось на подгруппы по стратегически задачам, чтобы для каждой цели найти показатели эффективности. Хотя подгруппы были межфункциональные, по первым двум задачам большую роль сыграли сотрудники маркетингового управления OFS, а по третьей задаче понадобилась помощь работников финансового и операционного отдела, которые занимались сокращением затрат. Подгруппы встречались несколько раз в течение двух недель для того, чтобы подобрать, по крайней мере, два показателя для каждой цели. Все команды встретились вновь для рассмотрения 41 показателя, обсуждая каждый в отдельности: дает ли этот параметр количественную оценку? Удобный ли это способ определения эффективности? Не покрывается ли он другим показателем? Известно, что один из ключевых принципов ССП состоит в ограничении количества показателей, с тем, чтобы сосредоточиться на наиболее важных факторах эффективности.

В результате отдел OFS сократил список показателей с 41 до 25. В тех случаях, когда согласия по показателю достигнуть не удавалось, вопрос о его включении в окончательный список решался голосованием. В результате команда перешла к разработке показателей для перспективы обучения и развития. Трудность состояла в том, чтобы напрямую связать влияние обучения и развития с эффективностью бизнеса в целом. Хотя членам команды и было очевидно, что обучение и развитие влияет на деятельность компании, они чувствовали, что это влияние косвенное, по-сравнению с целями других четырех направлений ССП. Кроме того, стало ясно, что цели обучения и развития труднее поддаются оценке, например, сложно ежемесячно оценивать компетенцию сотрудников. Поэтому команда решила исключить эти показатели из ССП, и рассматривать их ежегодно. Подгруппа, занятая первой стратегической задачей («Находить и сохранять ценных и потенциально выгодных клиентов»), первой разработала полный набор целей и показателей (см. таблицу 1).

Таблица 1. Цели и показатели для задачи «Находить и сохранять ценных и потенциально выгодных клиентов»

Направление BSC	Цель	Показатель
Финансовое	Рост доходов	Доход по продукту/услуге
Клиентское	Приобретение и сохранение ценных клиентов	Количество и процент активных online-клиентов, под активными клиентами подразумеваются те, кто пользовался сервисом не менее одного раза за последние 90 дней
Клиентское	Управление уходом к конкурентам	Количество появившихся клиентов и полное количество клиентовСуммарный доход банка от online-клиента
Внутренних бизнес-процессов	Максимизация надежности	Коэффициент удовлетворенности клиентов (оценивается по результатам опроса клиентов)Процент ухода клиентов, выполнявших операции с чеками
Внутренних бизнес-процессов	Разработка и реализация эффективных маркетинговых программ	Доступность в интернет (взвешенная) (% времени, когда интернет-серверы и серверы оплаты счетов находятся в рабочем состоянии)Время отклика (как долго клиент должен ожидать появления данных на экране)
Внутренних бизнес-процессов	Поддержание лидерства в разработке продуктов и услуг	Расходы на приобретение клиента при его регистрацииВзвешенный индекс конкурента (рейтинг основан на сравнении конкурентов)
Внутренних бизнес-процессов	Достижение высокого качества обслуживания	Процент претензий по оплате векселей (% жалоб о неправильной обработке счетов службой оплаты векселей)Фактор телефонного обслуживания (% клиентских звонков, обработанных в течение 40 секунд)

Сотрудники аналитического и информационного управления финансового отдела OFS вместе предложили наиболее удобный способ сбора данных для каждого показателя. Требования к данным были разделены на 3 категории.

Данные, доступные в нужном формате для OFS;
Данные, имеющиеся в наличии в Wells Fargo, но не доступные в OFS;
Данные, не доступные в Wells Fargo.

Перспективные задачи

BEA Liquid Data

Централизованный подход

Федеративный подход

Рис. 2. Технология федеративного доступа к базам данных позволяет пользователям (например, сотруднику отдела обслуживания клиентов) одновременно обращаться к данным из нескольких разнородных источников. В соответствии с разработанной компании BEA Systems технологией Liquid Data архитектор данных формирует стандартизованные представления данных так, чтобы пользователи могли «под одним углом зрения» изучать несхожие материалы. Затем система объединяет данные с тем, чтобы придать материалу логическую стройность; например, все данные о клиенте объединяются в одну категорию, а данные о заказе — в другую. Так пользователи могут с помощью однократных запросов сервера Liquid Data автоматически получать доступ к нескольким разнородным источникам данных.

IBM DB2 Information Integrator

Microsoft Yukon

Новые технологии

Oracle 9i

d@geercom.com

) — независимый автор, специализирующийся на проблемах технологии.

David Geer, Federated Approach Expands Database-Access Technology. IEEE Computer, May 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.

Технология изнутри

Рис. 1. Традиционно пользователь (например, сотрудник отдела обслуживания клиентов), желающий получить информацию из нескольких источников, может опрашивать источники лишь в порядке очереди, а это связано с более значительными затратами времени и средств, чем в случае одновременного доступа к множеству источников. В данном случае доступ пользователей к отдельным базам данных осуществляется с помощью программных средств интеграции приложений предприятия (enterprise application integration, EAI) и JDBC.

Информационные системы традиционной архитектуры (рис. 1) в каждый момент обеспечивают доступ лишь к одному источнику данных. Объясняется это тем, что до недавнего времени не существовало ни универсального языка для данных, ни качественных метаданных. Если пользователи желают получить необходимые данные из нескольких источников, они должны располагать точными метаданными, описывающими хранимые данные в форматах, доступных для чтения на различных платформах. Между тем, программные и аппаратные средства не отличались ни достаточной мощностью, ни функциональностью, необходимой для осуществления доступа к распределенным данным.
Раньше разработчики вручную создавали адаптеры для работы с полученными из нескольких источников данными, используя при этом API соответствующих источников. Однако вручную созданные адаптеры не способны автоматически подстраиваться под обновляемые версии API.

BI по-новому

Brokering - передача запросов в поисковые машины и получение результатов;

Bridging - установление связей с базами данных;

Full-Text Indexing - полнотекстовая индексация;

Catalog Building - создание каталогов для полуструктурированного и неструктурированного контента.

Следующие уровни FS:

адаптивное обучение (Adaptive Learning), реализующее настройку маршрутизации запросов по содержанию запросов и типам источников данных;

анализ результатов (Result Analysis) обеспечивает фильтрацию и отсеивания ошибочных, несоответствующих запросам результатов;

отслеживание и установка контрольных точек (Tracking & Alerts)дает пользователю возможность самому корректировать процедуры поиска;

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

публикация знаний (Knowledge Publishing)- фиксация результатов работы пользователей;

моделирование интересов пользователя (User Interest Modeling);

адаптивная персонализация (Adaptive Personalization);

представление (Presentation), технология построена на стандартных методах XML/XSLT;

портальные адаптеры (EIP/Portal Adapters);

администрирование.

Компания Intelliseek в настоящее время предлагает три программных продукта:

Enterprise Search Server (ESS) - основной продукт, обеспечивающий настоящий корпоративный поиск" и управление корпоративными знаниями;

BrandPulse - продукт, построенный на платформе ESS и служащий для анализа состояния торговой марки;

ExpressFeedback - новое предложение Intelliseek, служащее в качестве средства обратной связи для анализа отношений с покупателями.

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

Kevin Strange, Business Intelligence in 2003: Year of the "Shake-Up".

Gartner Group, 2002, December.

Business Portals: A Definition, TRIP REPORT Delphi Group Portals Seminar. The Fairmont, San Francisco, 2002, February 12-13.

Oracle9i Application Server Portal Handbook, Overview of Enterprise Information Portals.

Sundar Kadayam, The Promise of Knowledge Management, the ROI of Business Intelligence. KMWorld, 2002, January.

Jennings, Defining The Document and Content Management Ecosystem. Butler Group, September 2002.

Leveraging Knowledge From the Extended Enterprise, Intelliseek.

Данные vs. Информация

В компьютинге до сих пор нет точного определения того, что такое данные, что такое информация и чем данные отличаются от информации. Более пятидесяти лет назад с легкой руки Клода Шеннона и Джона фон Неймана, которым нужно было придать больше наукообразия теории передачи сигналов, была введена теория информации. С тех пор словом «информация» пользуются совершенно произвольно, не проводя разделение на данные и информацию, хотя это явно не одно и тоже. Даже не углубляясь в суть, доказать это совсем просто. Возьмем две книги формально равные по объему, содержащихся в них данных (т.е. с равным числом знаков); пусть одна будет доброкачественным детективом, а вторая — серьезным литературным произведением. Сравним повествования Бориса Акунина, исключая триптих о Пелагие, и «Мастера и Маргариту» Михаила Булгакова. (Это вовсе не критика, Акунина следует признать мастером своего жанра — дело в жанре, как таковом.) Детективы читаются легко, а процесс чтения очень похож на перекачку данных, он может идти непрерывно, поскольку в процессе чтения совсем не нужно привлекать дополнительную информацию и вызывать воображение. За читателя все сделано, в этом особая прелесть детектива. К тому же процесс конечен — трудно представить себе читателя, за исключением группы преданных фанатов, который со временем возвратится к прочитанному и будет вдумчиво перечитывать приключения Эрнеста Фандорина — достаточно один раз перекачать данные. Но едва ли найдется такой читатель, который, прочитав первый раз «Мастера», сочтет, что все понял и не захочет вернуться к нему.

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

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

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

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

Эти данные так и называют — «сейсмика, электроразведка, гравика», подчеркивая тем самым их принадлежность к способу получения; никому и в голову не придет назвать их информацией. Затем данные проходят первичную обработку, в которой участвует эксперт-геофизик, интерпретирующий эти данные, его инструментами являются самые разнообразные системы и средства для трансформации этих данных, в том числе экспертные системы, средства визуализации и многое другое, но главное — его знания геофизики. На выходе он передает геологам, осмысленную им геофизическую ИНФОРМАЦИОННУЮ картину исследуемой площади. Следующий за ним эксперт-геолог дает полученной информации свою интерпретацию, основанную на геологическом знании и, могут быть использованы дополнительные методы исследования. На каждом этапе данные обогащаются экспертизой, из данных формируется осмысливаемая информация, а в конечном итоге знание. Таким образом, в геофизике успешно реализована мучающая многих ИТ-специалистов триада «Данные — Информация - Знание»; здесь все произошло просто и вполне естественным путем, без использования каких-либо не слишком понятных терминов и технологий.

Защита информации vs. информационная безопасность

Разделение представления об информации и данных критически важно и в такой, казалось бы, неожиданной области, которую обобщенно называют информационной безопасностью. Его отсутствие в явном виде приводит к явной путанице части технических, аналитических и организационных мер в этой сфере. Совсем недавно понимание смыслового различия между данными и информацией стало осознаваться и специалистами, работающим в области безопасности. На первых порах (пока, в основном, в академической среде) начинают говорить о двух связанных направлениях. Первое — это собственно классическая защита данных в ее традиционном понимании (Information System Security Data). Второе исследует информационные принципы безопасности информационных систем (Information Principles of Information System Security). Защита данных техническими средствами по существу ближе к обеспечению физической безопасности, а защита информации в информационных системах гораздо более широкое понятие и оно не сводится к тривиальному закрытию источников информации от посторонних.

Хорошо известно, основную часть сведений разведывательные службы получают из открытых источников с применением аналитических инструментов. Прекрасная иллюстрация того, как самые охраняемые секреты могут быть вскрыты посредством анализа публикаций в прессе, приведена в старом фильме «Три дня Кондора» с Робертом Редфордом в главной роли. В нашей стране недавно получило громкую огласку дело по обвинению в шпионаже одного ученого из Обнинска. В банальном смысле он не разведчик, хотя, возможно, и предатель, хотя занимался всего-навсего аналитикой открытых публикаций, однако столь эффективно, что вызвал заметную обеспокоенность спецслужб своими действиями. Далеко не случайно, что вопросами анализа открытых источников давно и серьезно занимается все спецслужбы. В условиях глобализации и развития электронных средств распространения данных задачи анализа приобрели особое значение.

По понятным причинам становится доступным больше сведений о деятельности Центрального разведывательного управления США, чем о географически более близких их коллегах. Сегодня деятельность ЦРУ по защите информации приобретает в определенной степени коммерческий характер, по этой причине в 1999 году было организовано «полуоткрытое» подразделение ЦРУ, названное In-Q-Tel (). Своеобразный венчурный специалист от разведки в лице In-Q-Tel был для привлечения частных компаний к разработке технологий для сбора и анализа информации. Такой шаг сделан, по-видимому, для привлечения новых идей. Задачи, стоящие перед этой организацией, сформулированы следующим образом: «In-Q-Tel проявляет особую заинтересованность к новейшим технологиям извлечения ЗНАНИЙ из различных репозиториев и потоков данных, включая структурированные и неструктурированные ДАННЫЕ и представления релевантной ИНФОРМАЦИИ». В этой не слишком афишируемой программе ЦРУ выступает в роли инвестора в компании-«стартапы» и специальные программы. Первым начинанием стала поддержка компании Systems Research & Development (), где методы анализа, разработанные для казино, перерабатывались в разведывательных целях.

Отнюдь не случайно, что штаб-квартира SRD находится в Лас-Вегасе, очень нетипичном месте для софтверных компаний. Всего под патронажем In-Q-Tel находится менее десятка компаний.

Показательно, что одной из компаний, куда вложены средства In-Q-Tel, оказалась Intelliseek, разрабатывающая интеллектуальные Web-агенты и технологии вскрытия знаний. Вот что сказано по этому поводу на сайте In-Q-Tel: «За последние четыре года Intelliseek смогла изменить представления о том, что такое корпоративный интеллект, решения в области управления знаниями, поиска и открытия позволили решить фундаментальную проблему информационной перегрузки путем идентификации, релевантного поиска, постановки целей и создания персонализированного контента из Internet, и из сетей intranet и extranet».

Что такое Невидимая Паутина

Видимая часть Глобальной паутины (Visible Web) доступна через обычные поисковые машины, невидимая часть, очевидно, — это все остальное. Надо учесть, что распределение между частями меняется (раньше к числу невидимых относились файлы в формате pdf), но все же невидимым остается объем данных, который на порядок больше того, что можно увидеть простыми средствами. Это, прежде всего, — базы данных, допускающие доступ для поиска. В этих базах данных нет готовых страниц, которые предъявляются посредством браузера. Гораздо эффективнее и экономичнее оказывается формировать ответы в динамическом режиме, он обеспечивает возможность формирование страницы соответствующей конкретному запросу, естественно, что формируемую страницу ни один браузер найти не может. Вторая часть — исключенные страницы. Любая поисковая машина имеет определенную политику выбора индексируемых страниц. Если она обнаруживает, что по каким-то определенным признакам включение страницы в базу поисковой машины данных нецелесообразно, она ее исключает.

Более подробно о Invisible Web см.

Что Business Intelligence предлагает бизнесу

24.04.2003

Полноценно перевести словосочетание Business Intelligence (BI) невозможно. Со словом business и без того в русском языке есть очевидные сложности; не меньшие проблемы возникают при попытке подобрать соответствие слову intelligence в данном контексте.
В период кризиса, охватившего практически все компьютерные технологии, область BI оказалась одним из немногих островов процветания в нынешнем далеком от благополучия мире. Более того, аналитики Gartner Group считают, что в области BI предстоят настоящие прорывы. Серьезные перспективы они связывают с новым направлением — New Business Intelligence (NBI).
Компания Intelliseek стала одной из первых, кто проложил мост между KM и BI, назвав свой подход New Business Intelligence. Стимулами к появлению NBI, как сказал Каджам [4], стали рост размещенных в Internet данных и эволюция технологий для агрегирования, анализа и подготовки отчетов на основании разнородных источников.
В словарях приведены десятки соответствующих ему значений; некоторые из них, на первый взгляд, кажутся далекими друг от друга. А уж в сочетании business и intelligence дают нечто невообразимое. Разбираться в фундаментальных различиях между русским и английским языками, являющихся причинами такого рода сложностей, — удел лингвистов, точнее социолингвистов. Поэтому прекратим терминологические рассуждения, и будем в дальнейшем понимать под BI — информационное обеспечение бизнеса, причем в самом широком смысле. Не забудем, впрочем, две прописные истины. Первая: «Бизнес — это война». Вторая: «Информирован — значит вооружен». Другими словами, BI — это и интеллект, и разведка, в общем, все то, что нужно для приятия решений. Любопытно еще одно обстоятельство. В период кризиса, охватившего практически все компьютерные технологии, область BI оказалась одним из немногих островов процветания в нынешнем далеком от благополучия мире [1]. Более того, пришедшие к такому выводу аналитики Gartner Group считают, что в области BI предстоят настоящие прорывы. Серьезные перспективы они связывают с новым направлением — New Business Intelligence (NBI).

Данные, информация и технологии

Еще совсем недавно шутники предрекали, что конец развитию ИТ-решений наступит тогда, когда будут исчерпаны все возможные трехбуквенные названия. Впрочем, по понятным причинам прогресс не остановился: появились четырех и более буквенные аббревиатуры. Но, как известно, «в каждой шутке есть только доля шутки». Действительно, количество названий и соответственно разнообразных технологий для работы с информацией, а точнее говоря с данными, превосходит все мыслимые пределы. Если рост числа собственно технологий (а не их названий) продолжится, то конец и в самом деле возможен — прежде всего, по причине сложности. Технологий действительно море, но стройной карты для них, своего рода новой таблицы Менделеева, где каждой технологии было бы отведено свое место, и были бы обозначены связи между ними, пока нет. И отнюдь не случайно: причина в недостаточной определенности предмета, с которым работают технологии, называемые информационными. Эта неопределенность выражается, прежде всего, в смешении двух ключевых понятий — данные и информация.
Надо признать, что отдельные фрагменты будущей систематизирующей таблицы все таки складываются, причем, как это ни странно, раньше других не в областях, ставших классическими, а в совершенно новой области, такой как интеграция приложений на основе Web-служб. Еще совсем недавно, буквально пару лет назад Web-службы называли плохо определенной областью (ill-defined) компьютинга. Но неожиданно прозрачность в этой сфере наступает раньше, чем в других.
Происходит это, скорее всего, потому, что в данном случае решается задача обмена данными между приложениями. Подчеркнем: обмен ДАННЫМИ между ПРИЛОЖЕНИЯМИ. В этом фрагменте цепочки технологий нет человека, что в каком-то смысле приближает корпоративные системы к техническим системам управления или коммуникационным системам. Основной пафос происходящего в области с совпадающей аббревиатурой BI, (в данном случае обозначающей Business Integration) сводится к тому, что логика бизнес-процессов новыми средствами (прежде всего, серверами приложений) отделяется от логики процессов обработки данных — другими словами, «мухи отдельно, варенье отдельно».

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

Итак, если отбросить детали, нужно подчеркнуть, что современные технологии интеграции на основе стандартов SOAP, UDDI, WDSL и других позволяют сепарировать данные и информацию. Соответственно можно разделить и сами технологии — на те, которые работают в чистом виде с данными, и те, которые обеспечивают работу с информацией.

С появлением J2ЕЕ был сделан первый существенный шаг и теперь силами Sun Microsystems, тройственного союза BEA Systems, Intel, HP, корпорации IBM, а также целого ряда других заинтересованных сторон формируются платформы для обмена данными, между приложениями, образующими корпоративную систему. Но создание платформы для взаимодействия приложений не решает главной задачи — обеспечение ЧЕЛОВЕКА, также являющегося частью системы, средствами для получения ИНФОРМАЦИИИ (ведь, в конечном счете, для принятия решений нужна именно информация). Задачу создания средств для выделения информации из данных, лежащую поверх платформы, решают многие, в том числе и крупные, но по большей части мелкие компании. Они выступают в роли сателлитов, сопровождающих ведущих вендоров; особенно роль свиты бывает хорошо видна на всевозможных выставках, устраиваемых в рамках конференций, которые организуют крупные компании.

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

Корпоративный портал играет роль интерфейсного устройства; его можно воспринимать как инструмент, посредством которого данные представляются в форме, доступной для превращения их человеком в информацию. Традиционные определения порталов (например: «единственная точка персонализированного доступа к источникам бизнес-информации и знания», Delphi Group [2]) выглядят наивно. Что такое источник в данном случае? Более корректное введение в портальные технологии можно найти в [3]. Определению портала в этом документе предшествует определение того, что авторы понимают под KM (knowledge management) и BI, поскольку посредством этих технологий человек реально получает доступ к данным. Подчеркивается, что управление знаниями и информационное обеспечение бизнеса поддерживаются различными технологиями, в том числе и порталами.

Информационные системы для управляющих (executive information system, EIS), системы поддержки принятия решений (decision support), раскопка текстов и данных (text mining и data mining), операционные хранилища данных (operational data store), многомерная аналитическая обработка данных (multidimensional online analytical processing, MOLAP), реляционная аналитическая обработка данных (relational online analytical processing, ROLAP), а теперь еще и business intelligence — все эти и им подобные многочисленные термины могут лишь ввести в заблуждение любого. На самом же деле главный смысл тех глобальных изменений, которые происходят сегодня, заключается в том, что сейчас, прежде всего, требуется выбирать ДАННЫЕ из традиционных приложений и превращать их в ИНФОРМАЦИЮ, в информацию, которая может быть использована для эффективного управления бизнесом. На основе такого подхода дается следующее определение портала: «Портал — это единая точка входа в корпоративной системе, которая позволяет обнаруживать и высвобождать (identify и unlock) структурированную и неструктурированную информацию из различных источников с тем, чтобы превратить ее в корпоративное знание, необходимое для принятия решений».

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

Рис. 1. Происхождение Business Intelligence

Как использовать Business Intelligence в страховании

Дата: 05-05-2003

Автор: Монте Стрингер (Monte Stringer)

Перевод:
Современный бизнес ведется в информационную эпоху, в эпоху интенсивного распространения сетевых технологий и методов обработки данных. И все же малые и средние страховые компании до сих пор пользуются старыми системами для мэйнфреймов, ежемесячно генерирующими готовые управленские отчеты, в которых объединяются оперативные данные из этих систем. Однако в течение нескольких лет возможности таких систем полностью себя исчерпали.
За последние десятилетия, стремясь к сокращению эксплуатационных расходов, многие компании внедрили у себя дополнительные системы обработки полисов и претензий. Но несмотря на создание автоматизированных систем обработки данных, так и не удалось предотвратить сокращения инвестиционных доходов и повышения коэффициентов убыточности. Это негативно повлияло на стабильность работы нескольких крупных страхователей. Новые системы позволили компаниям реорганизовать потоки работ и документооборот, но возникшая при этом информационная инфраструктура, состоящая из совершенно не связанных между собой и не интегрированных программ, оказалась убыточной.
Именно поэтому современная отрасль страхования остро нуждается в использовании средств Business Intelligence— инструментов, позволяющих более точно прорабатывать структуру бизнеса, безошибочно оценивать реальный уровень рисков и соответствующим образом назначать цены этих рисков. BI-системы позволяют лицам, принимающим решения, объединять данные в центральном репозитории управления информацией и затем использовать сложные интегрированные приложения, чтобы быстро «углубляться» в данные, рассматривать и анализировать их по-новому. Эти современные аналитические инструменты обеспечивают ежедневное обновление основных ключевых показателей, по которым оценивается текущее состояние дел компании.

Как выбрать поставщика BI-приложения

На сегодняшний день возможностей выбора производителя BI-средств очень много. Определившись с потребностями, задав необходимые критерии и оценив бюджет, можно спокойно приступать к поиску. Автор статьи ? агент генеральный управляющий. Ресурсы его компании ограничены, поэтому ей понадобилась система со встроенными специфическими страховыми стандартами. Достаточно было сосредоточить усилия на ее настройке под конкретные нужды компании U.S. Risk.

Осмысление BI

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

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

Почему именно сейчас необходимы инструменты Business Intelligence?

Современная экономика и рынок сильно изменились, а это вынуждает изменить также и методы анализа данных, применяемые страховыми компаниями. Лица, принимающие решения (вне зависимости от должности), обязаны отказаться от привычных методов работы и мыслить творчески. Теперь необходимо посмотреть на данные под другим углом и принимать упреждающие решения, которые станут основой дальнейших финансовых успехов.
Компания U.S. Risk, обладает правами национального агента генерального управляющего (Managing General Agent, MGA), является торговым брокером, занимается более 50-ю направлениями страховой деятельности. Недавно фирма внедрила у себя Business Intelligence. Она могла бы сделать это гораздо раньше, но тогда таких специализированных BI-систем еще не существовало. Теперь такие системы доступны, и для определенных сегментов страховой отрасли уже давно назрела необходимость в их применении.
Раньше бизнес успешно продвигался благодаря связям. По мере роста издержек от потерь рынок становился более жестким и компании U.S. Risk пришлось действовать более продумано, оценивая свою деятельность с помощью новой технологии. На сегодняшний день, необходимо максимально использовать все ресурсы, и заблаговременно получать информацию о том, почему та или иная программа или направление в бизнесе не работает с нужной отдачей, а затем предоставить страховым партнерам четкий анализ эффективности программ.

Преимущества Business Intelligence

Оптимизируя процессы и помогая найти оптимальные методы работы, Business Intelligence воздействует на многие сферы страховой деятельности, такие как :

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

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

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

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

Информационные технологии. Сокращаются временные и человеческие ресурсы, которые необходимо привлекать для создания отчетов. BI дает пользователю, вне зависимости от уровня его подготовки и положения в компании, максимальные возможности для доступа, анализа и управления информацией, а следовательно, и для принятия правильных бизнес-решений за счет использования централизованной инструментальной панели (Dashboard).
Например, в Северном Техасе (North Texas) часто случаются сильные ливни. С помощью BI страховые компании могут определить концентрацию крыш в любой географической области, оценивают риски, заранее предполагая возможные дефекты и последствия, и соответствующим образом устанавливают свои тарифы.
Не только страховым компаниям (MGA и другим поставщикам страховых услуг), но и розничным агентам следует осознать полезность BI-средств. Андеррайтинговые решения часто принимаются на основе класса рисков. Например, коэффициент убытков для многоквартирных домов высок, поэтому компания, как правило, решает не принимать на страхование объекты этого класса. BI дает должное понимание специфических характеристик для всего перечня страховых услуг. Возможность быстро получать доступ и легко анализировать точную и своевременную информацию помогает организациям быстро реагировать и предпринимать соответствующие стратегические шаги. В результате, ставки страховых премий растут, а «андеррайтинговый аппетит» становится более последовательным.

Интеграция корпоративной информации: новое направление

Подготовлено по материалам зарубежных сайтов
Перевод:
1 Март 2005 г

Интеграция корпоративной информации: новое направление

Различные типы интеграций

Как отмечает Тим Мэттьюс (Tim Matthews), автор многочисленных публикаций на ресурсах XML Journal, DevX, и Tech Target, технология EII использует распределенный запрос для сбора и интеграции информации из различных источников. Обычно такой запрос называют объединенным, или федеративным (federated). В этом случае запросы распределяются по источникам данных, а затем результаты их выполнения присоединяются другу к другу или объединяются. Продолжая сопоставление EII с другими интеграционными технологиями, Тим Мэттьюс подчеркивает, что EII несколько отличается от других подходов. Так, EAI обычно передает сообщения от одного приложения к другому по концентратору (hub) или шине (bus).

ETL использует физическое перемещение данных из одного местоположения в другое, создавая при этом в складах данных избыточные копии данных. Как правило, эти копируемые данные являются итоговыми данными и в этом случае детальные данные не доступны. В своей основе и EAI, и ETL - это технологии активной доставки, или "проталкивая" (push). EII же является технологией извлечения ("вытягивания") информации (pull), при которой объединенный запрос находит данные, необходимые для пользовательского приложения, и вставляет их в представление с пользовательским контекстом.

Каким образом достигается интеграция информации? По мнению Джона Тейлора, она начинается с сервисно-ориентированной архитектуры (service-oriented architecture, сокр. SOA). Благодаря этому обеспечивается универсальный механизм доступа ко всем системам посредством Web-сервисов, а также универсальное представление данных в формате XML. Это также позволяет обращаться не только к данным, "удобно" хранящимся в базах данных, но и в коммерческих и заказных приложениях, Web-контенте, документах, рисунках, и пр. Использование SOA в качестве основы поддерживает интеграцию и раскрытие информации из структурированных, транзакционных систем, а также из неструктурированных, основанных на контенте систем.

По словам эксперта портала Бесс Голд-Бернштейн (Beth Gold-Bernstein), EII создает слой абстракции между приложениями, которые запрашивают информацию, и исходными системами. Этот слой абстракции исключительно важен для SOA. Он позволяет представить доступ к данным в виде управляемого сервиса. Таки образом, EII минимизирует влияние изменений на исходные системы и, следовательно, максимизирует "активность" бизнеса. Доступ к различным наборам агрегированных данных может быть представлен как сервис в SOA.

Бесс Голд-Бернштейн согласна с Джоном Тейлорjv и Тимом Мэттьюсом, полагая, что технология EII значительно отличается от других типов интеграции. Возможность агрегировать данные из различных прикладных систем в реальном времени требует специализированной технологии, включая кэширование, индексацию и/или оптимизацию распределенных запросов, которые не применяются в других интеграционных решениях.Ни интеграция корпоративных приложений, ни управление бизнес-процессами не позволяют агрегировать распределенные источники данных как единую базу данных или создавать различные виртуальные представления. Однако такая возможность - исключительно полезный и необходимый сервис для всех стилей интеграции, включая компонентные приложения (composite application) и SOA. И поэтому, хотя некоторые аналитики пока не признают EII в качестве уникального класса интеграции, ей определенно предназначено стать более важным компонентом архитектуры корпоративной интеграции.

Перспективы развития

Технология EII стремительно развивается - это быстро растущий сегмент рынка. По оценке авторитетного ресурса , уже сейчас около 58 поставщиков предлагают EII-решения.
Как известно, традиционные инструменты ETL изначально создавались для проектов Хранилищ данных и разрабатывались для физического перемещения данных в пакетах, а не для обеспечения виртуального представления агрегированных данных, к которым можно обращаться в режиме реального времени. Однако, сегодня многие из поставщиков модернизируют свои продукты, включая в них поддержку доступа к данным в реальном времени, и позиционируют эти инструменты как EII-решения.
Тем не менее, рынок EII пока еще только зарождается. Основное назначение этих инструментов - получить доступ в реальном времени к информации, находящейся в различных информационных системах. Кэширование, индексация и оптимизация распределенных запросов являются основными, пока незапатентованными технологиями, с помощью которых эти инструменты могут обеспечить извлечение информации в реальном времени. XML и Web-сервисы быстро превращаются в стандарты, на которые опираются данные продукты. Использование стандартов может позволить этим технологиям стать платформами управления и интеграции корпоративной информации.

Адаптация решения

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

повторная конкретизация переменных в существующем прецеденте и присвоение им новых значений;

уточнение параметров: некоторые прецеденты могут содержать числовые значения, например, время выполнения какого-либо этапа плана; это значение должно быть уточнено в соответствии с новым значением другого свойства;

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

Адаптивное управление на основе прецедентов

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

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

Адаптивное управление на основе прецедентов

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

Формирование обобщенных образов состояний ОУ на основе априорной информации (обучение).
Идентификация состояния ОУ по его выходным параметрам (задача распознавания образов).
Определение влияния входных параметров на перевод ОУ в различные состояния (обратная задача распознавания).
Прогнозирование поведения ОУ в условиях полного отсутствия управляющих воздействий.
Прогнозирование поведения ОУ при различных вариантах управляющих воздействий.

Адаптивное управление по прецедентам, основанное на классификации состояний управляемых объектов

Л. Е. Карпов, В. Н. Юдин,
Труды Института системного программирования РАН

Исходные понятия

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

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

Литература

1.обратно	Я. З. Цыпкин. "Адаптация и обучение в автоматических системах". М.: Наука, 1968.
2.обратно	Н. Г. Загоруйко. "Прикладные методы анализа данных и знаний". Новосибирск, ИМ СО РАН, 1999.
3.обратно	, М., ИСП РАН, препринт № 18, 2006.
4.обратно	В. И. Скурихин, В. А. Забродский, Ю. В. Копейченко. "Проектирование систем адаптивного управления производством". Харьков, "Вища школа", 1984.
5.обратно	А. А. Жданов. "Метод автономного адаптивного управления". Известия Академии наук. Теория и системы управления, 1999, № 5, стр. 127-134.
6.обратно	Математика и кибернетика в экономике. - М.: Экономика, 1975.
7.обратно	Alan Bundy, editor. "Artificial Intelligence Techniques". Springer Verlag, 1997.
8.обратно	Klaus-Dieter Althof, Eric Auriol, Ralph Barlette, and Michel Manago. "A Review of Industrial Case-Based Reasoning Tools", AI Intelligence, 1995.
9.обратно	S. S. Anand, J. G. Hughes, D. A. Bell and P. Hamilton. "Utilising Censored Neighbours in Prognostication, Workshop on Prognostic Models in Medicine", Eds. Ameen Abu-Hanna and Peter Lucas, Aalborg (AIMDM'99), Denmark, pp. 15-20, 1999.
10.обратно	В. В. Кузьменко, Д. В. Гришин. "Теоретические аспекты функционирования адаптивной системы управления предприятием". Вестник СевКавГТУ. Серия "Экономика". № 2 (10), 2003. ISBN 5-9296-0140-2. .

1(к тексту)

Работа поддержана грантами Российского фонда фундаментальных исследований № 06-07-89098-а и № 06-01-00503-а.

Направления в развитии систем поддержки принятия решений

Различают два направления в развитии систем поддержки принятия решений:

вывод, основанный на правилах;

вывод, основанный на прецедентах.
Практически все ранние экспертные системы моделировали процесс принятия экспертом решения как чисто дедуктивный процесс с использованием вывода, основанного на правилах. Это означало, что в систему закладывалась совокупность правил вида "если...то...", согласно которым на основании входных данных генерировалось то или иное заключение по интересующей проблеме. Такая модель являлась основой для создания экспертных систем первых поколений, которые были достаточно удобны как для разработчиков, так и для пользователей-экспертов. Однако с течением времени было осознано, что дедуктивная модель моделирует один из наиболее редких подходов, которому следует эксперт при решении проблемы.
Идея вывода по правилам является привлекательной, потому что она подразумевает наличие хорошо формализованной задачи, для которой существуют научные методы, доказавшие свою применимость и позволяющие получить решение, не требующее дополнительных доказательств.
Но окружающий мир сложен. Существует много слабо формализованных задач, для которых, возможно, будут найдены решения. Кроме того, существует ряд задач, для которых никогда не будет найдено формальное решение (судопроизводство, медицина). Актуальность проблемы обусловлена и многочисленностью таких задач, и практической потребностью найти хотя бы одно сколько-нибудь подходящее решение там, где из-за отсутствия формализованного метода нельзя найти все решения или оптимальное решение.
На самом деле, вместо того чтобы решать каждую задачу, исходя из первичных принципов, эксперт часто анализирует ситуацию в целом и вспоминает, какие решения принимались ранее в подобных ситуациях. Затем он либо непосредственно использует эти решения, либо, при необходимости, адаптирует их к обстоятельствам, изменившимся для конкретной проблемы.
Моделирование такого подхода к решению проблем, основанного на опыте прошлых ситуаций, привело к появлению технологии вывода, основанного на прецедентах (Case-Based Reasoning, или CBR), и, в дальнейшем - к созданию программных продуктов, реализующих эту технологию.

Описание локальной контекстно-зависимой метрики

Существуют разные способы разбиения множества объектов на классы:

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

Локальная метрика, основанная на классах эквивалентности, делит все объекты на две группы: входящие в один класс с текущим и не входящие в этот класс. Она может принимать только два значения. Если исследуемый объект попал в класс, то близкими (равными по метрике) ему могут считаться объекты этого же класса. Остальные - не равны. Такая метрика не полностью учитывает взаимоотношения между текущим объектом и окружающими (контекст), особенно когда объект попадает в область пересечения классов.
Формирование классов происходит до рассмотрения исследуемого объекта и естественно, не в его признаковом пространстве. На этапе предварительной обработки, когда объекты собирают в классы, признаковым пространством для класса будет пространство, общее для всех признаков этого класса. Далее, после того, как классы сформированы, естественно рассматривать их в общем для них признаковом пространстве (в транзитивном замыкании пространств всех объектов).
При рассмотрении исследуемого объекта он может быть отнесен сразу к нескольким классам. Такая ситуация может возникать, если у объекта часть признаков по отношению ко всем этим классам отсутствует. Это же может произойти из-за недостаточной или некачественной информации при обучении или при разделении на классы. На практике возникновение подобных ситуаций не является редкостью. Проиллюстрируем их на простом примере (рис. 7).

Описание локальной контекстно-зависимой метрики

Рис. 7.Отнесение недостаточно описанного объекта к двум классам.
Два непересекающихся класса A и B описаны в пространстве признаков {X1, X2}. Объект исследования O представлен одним признаком X1, признак X2 у него отсутствует.

В этом пространстве признаков {X1} проекции классов пересекаются, и объект попадает в это пересечение.
Для более точной оценки нужно было бы добавить к контрольному объекту значение признака X2 (так же поступают и в медицине: если имеющихся показателей не хватает для дифференцирования заболеваний, только дополнительное исследование позволит сделать окончательный вывод), но на практике это не всегда возможно.
До сих пор считалось, что попадание объекта в область пересечения классов является препятствием для оценки объекта. Поскольку от этой ситуации избавиться не удается, ее надо постараться использовать. Для этого будем использовать аналоги - объекты соответствующих классов, попадающие в ту же область пересечения.
При рассмотрении объекта соответствующая ему точка сравнивается с расположением классов в проекции на пространство его признаков. Другие объекты, входящие в один класс с ним, считаются близкими к нему. Объекты могут также попадать в область пересечения классов. Все объекты можно разделить на группы (рис. 8), основываясь на сложности этого пересечения. Объекты, находящиеся в той же области пересечения, что и исследуемый объект, естественно считать более близкими к нему, чем те, которые находятся вместе с ним в каком-нибудь одном из классов, не входя в область пересечения. Этому можно найти простое объяснение: если считать, что введением классов мы разбили множество объектов на основные понятия, то с тем же набором признаков, что и текущий объект, они подобны ему по принадлежности к понятиям, обозначаемым классами.
Сравнив введенное понятие близости с тем, что говорилось ранее, нетрудно заметить, что предложенная метрика является локальной и контекстно-зависимой. Локальной, потому что привязана к рассматриваемому объекту, контекстно-зависимой - потому что зависит от его набора признаков. Приведем более строгое определение предлагаемой меры:
Расстояние от текущего объекта до другого равно разности количества классов, куда попал текущий объект, и количества классов из этого числа, в котором находится другой.
Это значит, в частности, что расстояние между текущим объектом и другим объектом, находящимся в той же области пересечении классов, равно нулю. На рис. 8 цифрами помечены области с соответствующим этим цифрам расстоянием от текущего объекта до объекта из этой области.
Предложенная мера не является метрикой в классическом понимании, а только имеет интерпретацию расстояния. Для нее не гарантируется выполнение правила симметричности, потому что она привязана к объекту, и, при переходе к другому объекту, будет рассматриваться уже в его пространстве признаков. По этой же причине не гарантируется выполнение правила треугольника. Однако она позволяет учитывать контекст взаимоотношений объекта с окружающими, особенно в непосредственной близости от него.

Рис. 8. Степени близости объектов.

Понятие адаптивного управления

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

открытое, или разомкнутое,

замкнутое, или управление с обратной связью, и

адаптивное.
Первый тип - разомкнутое управление, которым предполагается наличие цели, определяющей управляющие воздействия для достижения этой цели. Структура разомкнутого управления (рис. 1) проста. Отсутствие обратной связи упрощает управление. При отклонении результата от запланированного проводится анализ, который объясняет причины отклонения, но не ставит задачи изменить что-либо в управлении.

Рис. 1.Структура разомкнутого управления.
Второй тип - замкнутое управление (управление с обратной связью), при котором (рис. 2) предполагается возможность изменять управление в зависимости от его воздействия на конечный результат. Эта методика управления рассчитана в основном на малые промежутки времени. Если же результат воздействия фактора проявляется через достаточно большое время, часто возникают значительные затруднения.

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

Рис. 3. Структура адаптивного управления.
С термином адаптация связаны понятия адаптивного управления, адаптивной системы и адаптивной модели.

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

Адаптивной считают систему, которая может приспосабливаться к изменениям внутренних и внешних условий [,].

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

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

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

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

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

Понятие локальной контекстно-зависимой метрики

Управление плохо формализуемыми объектами

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

Целью управления можно считать стремление замедлить процесс уменьшения рабочей ткани (как можно дольше удерживать ОУ в текущем классе).

Рис. 4. Упрощенный вид переходов объекта управления.

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

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

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

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

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

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

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

Возможные приложения предлагаемого метода адаптивного управления

К приложениям с плохо формализуемыми объектами, для которых бессмысленно пытаться получить явный вид передаточной функции, можно отнести, в первую очередь, медицинские приложения, затем управление предприятием, игру на валютном рынке, системы защиты информации (обнаружение информационных воздействий) и другие.
Адаптивное управление предприятием, или "включенное" оперативное управление чаще подразумевает собой действия, направленные на преодоление кризисной ситуации на предприятии []. Модель адаптивного управления должна содержать критерий, относительно которого принимается решение, и характеристики объекта в виде совокупности управляемых переменных.
Управление должно происходить в условиях неполного, нечеткого и неточного знания характеристик объекта управления и характеристик окружающей среды, в которой функционирует этот объект. Кроме того, в ходе реализации экономического процесса, происходящего в условиях неопределенности, обычно меняются параметры объектов-участников процесса и характеристик окружающей их среды. В такой ситуации не представляется возможным получить четкую форму модели объекта управления, как параметрическую, так и структурную.
Метод управления по прецедентам предлагается в качестве основы реализации таких адаптивных регуляторов экономических процессов.
В настоящее время становится очевидным, что качественно новый уровень защищенности сложных и многофункциональных информационных систем может быть достигнут лишь за счет реализации адаптивного управления процессами защиты информации. При этом под "адаптивным управлением" понимается процесс целенаправленного изменения параметров и структуры системы защиты информации с целью поддержания требуемого уровня защищенности систем.
Современные сетевые технологии уже трудно представить без механизмов защиты. Однако при их детальном анализе всегда возникают несколько вопросов: насколько эффективно реализованы и настроены имеющиеся механизмы, как противостоит атакам инфраструктура защиты, может ли администратор безопасности своевременно узнать о начале таких атак?

Противостояние атакам - важное свойство защиты. Казалось бы, если в сети установлен межсетевой экран (firewall), то безопасность гарантирована, но это распространенное заблуждение может привести к серьезным последствиям.

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

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

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

Выбор прецедента

В таких системах одной из самых важных является проблема выбора подходящего прецедента. После того, как прецеденты извлечены, нужно выбрать "наиболее подходящий" из них. Это определяется сравнением признаков ОУ в текущей ситуации и в выбранных прецедентах. Определение метода, на котором будет основываться нахождение меры сходства прецедентов, решается во время создания системы ее разработчиками. Наиболее популярным и часто используемым является метод "ближайшего соседа" []. В его основе лежит тот или иной способ измерения степени близости прецедента и текущего случая по каждому признаку (будь это текстовый, числовой или булевский), который пользователь сочтет полезным для достижения цели.
Говоря более строгим языком, вводится метрика (расстояние) на пространстве всех признаков, в этом пространстве определяется точка, соответствующая текущему случаю, и в рамках этой метрики находится ближайшая к ней точка из точек, представляющих прецеденты. Описанный здесь алгоритм очень прост. Реально применяются некоторые его модификации. Обычно прогноз делается на основе нескольких ближайших точек, а не одной. Такой метод более устойчив, поскольку позволяет сгладить отдельные выбросы, случайный шум, всегда присутствующий в данных.
Каждому признаку назначают вес, учитывающий его относительную ценность. Полностью степень близости прецедента по всем признакам можно вычислить, используя обобщенную формулу типа:

где wj - вес j-го признака, sim - функция подобия (метрика), xij и xik - значения признака xj для текущего случая и прецедента, соответственно. После вычисления степеней подобия для всех прецедентов получаем их единый ранжированный список.
Метод прост, может быть реализован очень эффективно, но требует для работы большой памяти, так как в процессе нахождения значения зависимой переменной для новой записи используется вся существующая база данных.
В методе ближайшего соседа, в классическом его представлении, используются только признаки текущего случая и прецедента. Но в управлении важен еще и результат воздействия, то, насколько он приближает к цели. При вводе метрики можно учесть и этот критерий. Считая, что цель должна быть достигнута за конечное число шагов, можно считать более близким прецедент, позволяющий достичь цели за меньшее число шагов. Мы пока не рассматриваем более сложные случаи управления, когда прецеденты выстраиваются в определенный порядок (в общем случае - в некоторые структуры). Так, например, в медицине лечение иногда проводят этапами, выводя больного из комы сначала в некоторое промежуточное состояние, не граничащее с комой, а затем уже стараются приблизить его показатели ближе к норме.
В общем случае, можно представить многоуровневую метрику, где прецеденты сравниваются по:

Состоянию до воздействия;
Воздействию;
Состоянию после воздействия.

Вывод, основанный на прецедентах

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

Описание проблемы.
Решение этой проблемы.
Результат (обоснованность) применения решения.

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

перечень того, что выполнено,

результат,

способ восстановления (в случае отказа),

перечень того, что можно сделать, чтобы избежать отказа,

результаты восстановления.
Описание результата может также включать ссылки на другие прецеденты, текстовую информацию (рис. 5).

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

Интеграция трех самостоятельных направлений, относящихся

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

Аллокации затрат и согласование бюджета

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

Аналитические возможности OLAP

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

Нyperion Pillar и Hyperion Essbase. Характеристики продуктов. Пример применения

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

Перевод:

Основные особенности

Hyperion Pillar? одно из наиболее известных решений на рынке продуктов бюджетирования. Любой продукт, позволяющий менеджерам подразделений планировать свою деятельность таким образом, как они привыкли мыслить, должен обладать достаточно гибкими функциями для распознавания информации и распределения ресурсов различными способами. Hyperion Pillar имеет хорошие возможности моделирования бизнес-процессов, благодаря которым менеджеры, задавая определенные связи между данными, могут больше не мучиться с макросами или формулами в электронных таблицах. Для надежности планирования в Hyperion Pillar включен расчет на основе стандартных показателей, таких как уровень зарплаты, цены на продукцию, объем производства, процент инфляции и процент брака.
Информацию можно распределить по различным измерениям, что позволит систематизировать данные с учетом текущих бизнес-потребностей. Таким образом, бюджетирование можно будет проводить как по всему проекту, так и по каналам распространения, ряду продуктов и вообще по любым другим категориям, которые компания пожелает задействовать при планировании. Для каждого измерения можно задать атрибуты, которые описывают бизнес-структуру. Например, территории должны быть включены в региональную иерархию, а отделы объединены в группы. Способы анализа данных практически неограниченны, и это позволяет задействовать в расчетах все показатели, а не только те, которые входят в круг представлений какого-то одного отдела.
Возможности моделирования, заложенные в Hyperion Pillar позволяют оценивать конъюнктуру рынка и влияние различных стратегий на результаты ее деятельности. Пользователи могут создавать и хранить стандартные шаблоны распределения по периодам времени: кумулятивные, с задержкой, смешанные, ? и динамически их применять к различным элементам моделей. К дополнительным возможностям относятся: полное моделирование с математическими операторами и расчетами по финансовым ведомостям.

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

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

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

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

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

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

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

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

Подготовка пользователя

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

Отчет о прибылях и убытках.

Баланс.

Движение денежных средств.

Организация:

Географическая

Функциональная/ Направление бизнеса

Транспортные средства

Анализ:

Финансовые показатели

Сравнение фактических и бюджетных показателей

Сравнение бюджетных и прогнозируемых показателей

Сравнение прогнозируемых показателей с фактическими

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

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

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

Сравнение бюджетных расходов с обязательствами.

Полный набор финансовых отчетов с горизонтальными и вертикальными трендами и диаграммами.

Финансовые соотношения с временными отклонениями.

Краткие сводки по периодам (дням, неделям, месяцам, кварталам, годам) или по «периодам до даты».

Количество/номера сотрудников, рабочих часов, накладные расходы по сотрудникам.

Номер проекта, функции подпроекта.

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

Любые количественные данные для трендового анализа в долларах или других единицах.

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

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

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

Пример внедрения продуктов Hyperion для бюджетирования в правительственных структурах.

В этой части статьи рассказывается о том, как инструмент OLAP-анализа фирмы Hyperion (Hyperion Essbase) можно применить для автоматизации бюджетирования в крупных правительственных учреждениях, таких как Администрация общих служб (General Services Administration, GSA). Описываются методологии распределенной бизнес обработки, анализа и управления на всех уровнях предприятия.

Техническая разработка

Разработка OLAP-системы на основе Essbase выполняется достаточно просто. Система комплектуется из десяти полнофункциональных блоков примерно за шесть месяцев (в зависимости от требуемой модели). Для поддержки Essbase-кубов через приложение, реализованное на основе тонкого клиента (такого как Alphablox или Executive Viewer) требуется только один основной сервер. Поэтому данные можно загружать в реальном времени на защищенный сервер и через сутки использовать для анализа. Если две системы настроить по принципу «реле» (таким образом, чтобы пока загружаются и рассчитываются данные одного Essbase-куба, другой уже доступен с загруженными и рассчитанными данными), то отчеты можно обновлять каждые четыре часа.

Comshare MPC

Comshare MPC считается продуктом мирового класса, представляет собой единое комплексное приложение стратегического менеджмента, предназначенное для бизнес-планирования и управления. Объединяет и интегрирует все данные и задачи, связанные со стратегическим планированием, бюджетирование, прогнозированием, финансовой отчетностью и анализом, в единую систему.
Web-приложение Comshare позволяет:

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

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

обеспечивает единую модель программирования для доступа к любому типу данных, вне зависимости от того, где данные хранятся — компоненты доступа к данным имеют удобную для пользователя архитектуру программирования, которая не зависит от инструмента и языка;

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

EPS Software — PROPHIX

Компания EPS предложила новый подход к разработке ПО для бюджетирования и планирования. Prophix — продукт для разработчиков с доступной по цене лицензионной схемой. Главное его достоинство состоит в том, что Prophix не требует настройки продукта и обеспечивает быстрое внедрение. EPS не работает с торговыми представителям, в место этого на интернет-сайте размещается демо-версия продукта, обеспечивающая обучение потенциальных покупателей. Приобретая Prophix, компаниям не нужно проводить длительные мероприятия по покупке, такие как подача заявок на предложения (Requests For Proposals, RFP)и рассмотрение ответов на них.

Hyperion — Pillar and Planning

Pillar — это приложение для предприятия (Enterprise Application System, EAS), которое может быть интегрировано в существующую ERP-систему компании-клиента. Pillar обеспечивает клиентскую базу данных для планирования, основанного на допущениях, а также аналитический инструментарий; выполняет импорт и интеграцию данных в централизованную базу из других программ управления, работающих на различных системах. Используя Pillar, менеджеры могут создавать множество специальных сценариев планирования, например: влияние задержки выпуска продукта или материальных затрат на финансовые потоки и т. п.
Многие организации используют продукт Hyperion Pillar в сочетании с OLAP-сервером Hyperion Essbase. Являясь мощным OLAP-сервером, Hyperion Essbase реализует базовые технологии, которые сочетают реляционную модель хранения данных с многомерной OLAP-машиной, анализирующей и распространяющей любые объемы данных, как на уровне подразделений и так в масштабах всего предприятия.
Hyperion Essbase дает конечным пользователям возможность оперировать данными в реальном времени, анализировать бизнес-показатели, а также быстро создавать и внедрять сложные аналитические приложения.
При совместном применении продукты Hyperion Pillar и Hyperion Essbase предоставляют широкие возможности для поддержки бизнес-процессов, финансового анализа и совместной работы для предприятия. Например, пользователи системы Hyperion Pillar могут использовать приложения СУБД Hyperion Essbase для произвольного анализа больших объемов данных из различных источников. Также, менеджерам становятся доступны все преимущества использования OLAP-отчетов для анализа актуальных бюджетных данных. Посредством интеграции с Hyperion Essbase, бюджетные данные в системе Hyperion Pillar доступны тысячам пользователей, которые могут использовать более 60 инструментов доступа от компании Hyperion и ее партнеров по программе Hyperion Alliance.

Новая парадигма для планирования и бюджетирования

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

прогнозирование затрат;

прогнозирование доступности продукта;
прогнозирование клиентских ожиданий.
Причем все эти операции приходилось выполнять независимо друг от друга, используя несогласованные между собой системы. Такой подход требовал слишком много времени, да и конечные результаты часто не соответствовали рыночной действительности.
Однако сейчас ситуация постепенно меняется: модернизация (реинжиниринг) бюджетирования и планирования становится стандартной процедурой. Для этого требуется стратегическое планирование методом «сверху вниз», выполняемое руководителями отделов. И теперь самые современные системы, применяющиеся уже в большинстве быстроразвивающихся компаний, собирают и интегрируют данные из всех источников, выдают финансовые показатели на основе допущений и сценариев, а кроме того, способствуют принятию правильных решений в минимальные сроки.
Да, это рецепт успеха, однако он зачастую требует больших затрат на информационную поддержку, связанных с приобретением систем планирования ресурсов предприятия (Enterprise Resource Planning, ERP) и других аналитических инструментов, которые специализируются на проверке, консолидации и автоматизации операций и финансовой информации. Крупным корпорациям нелегко покрыть расходы на покупку ПО, оплату труда персонала, занятого поддержкой, а также на настройку и консалтинг. Поэтому в будущем с целью создания более качественных бюджетных планов инфраструктура бизнеса будет опираться на интеграцию программных приложений с данными, поступающими от основных поставщиков и покупателей.

Развитие рынка ПО для бюджетирования

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

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

SRC Software — The Advisor Series

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

Типы решений: ПО разработчика и ПО дизайнера

Программные продукты для разработчика (Builder products) — это дорогие решения, стоящие около 50 тысяч долларов. Они представляют собой инструментальные средства, требующие настройки и дополнительной разработки и предназначены для реализации конкретных нужд отдельной компании, как-то: создания финансовых и бухгалтерских систем, организационных структур и т. п.
С другой стороны, продукты для дизайнера (Designer products) полностью готовы и требуют минимальных расходов на настройку и внедрение. Обычно эти продукты удобны для пользователя и практически не требуют программирования. Средняя цена таких решений составляет менее 10 тысяч долларов, при том, что их возможности мало чем отличаются от аналогичных систем для разработчиков.

Каждый из технологических процессов не

№ 2

900

2750

№ 3

1000

2500

( Каждый из технологических процессов не может «простаивать», поэтому заданы минимальные загрузки.)

Потребителям

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

Цены, рублей за тонну
Бензин	Керосин	Дизельное топливо	Мазут
11000	9500	8000	3000

Кроме того, предполагается, что вся продукция обязательно реализуется потребителям.

Требующиеся результаты

Требуется

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

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

Рассматриваемая задача является типичной для данного предприятия.

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

Схема оценки прибыли

На данном предприятии используется следующая оценка прибыли:

Вычисление оценки прибыли	- суммарная прибыль в рублях, полученная от реализации всех продуктов переработки нефти по всем технологиям
Переменные	- суммарный объем нефти сортов А и Б в тоннах, перерабатываемый по технологии № S
Коэффициенты	- оценка прибыли в рублях, полученная от реализации продуктов переработки тонны нефти по технологии № S, где - сумма цен продуктов переработки, - затраты при переработке

<

/p> (Перепродажа нефти условно считается «технологическим процессом № 4».)

По условию задачи критерий оптимальности

плана имеет вид:

В рассматриваемых условиях коэффициенты

имеют следующие значения:


В рублях	6766,667	4100	4266,667	1400
В относительных величинах	0,409	0,248	0,258	0,085

Данные из условия задачи, необходимые для расчета коэффициентов

, собраны в Excel-таблице . Сами коэффициенты – в строке № 13.

Замечание. Величины

по условию задачи в сумме должны совпадать с объемом V суточной поставки нефти. Если разрабатывается перспективный план, то этот объем V может быть не известен. Тогда допустимо предположение V=1, а величины

будут долями единицы, т.е. «относительными объемами».

Ограничения на объемы сырой нефти по каждой технологии

Ограничение	Пояснение
	- доля нефти сорта А в технологии № S, - объем суточной поставки нефти сорта А, - суммарный объем нефти, перерабатываемый по технологии № S
	- доля нефти сорта Б в технологии № S, - объем суточной поставки нефти сорта Б,
,	, - соответственно минимальная и максимальная загрузки нефти для технологии № S

Из первых двух неравенств автоматически следует, что

, то есть суммарный объем перерабатываемой нефти не больше объема суточной поставки нефти

.

Данные из условия задачи о характеристиках технологий, необходимые для расчета коэффициентов

, собраны в Excel-таблице . Сами коэффициенты – в строках № 15 и № 16 соответственно.

Объемы сырой нефти каждого сорта для отдельных технологий

При условии, что найден оптимальный план, для каждой технологии № S, S=1, 2, 3 сырье распределяется следующим образом:

Объемы нефти по сортам и технологиям	Пояснения
	- доля нефти сорта А в технологии № S, - объем нефти сорта А в технологии № S, - суммарный объем нефти, перерабатываемый по технологии № S
	- доля нефти сорта Б в технологии № S, - объем нефти сорта А в технологии № S,

Данные из условия задачи о характеристиках технологий, необходимые для расчета коэффициентов

, собраны в Excel-таблице Сами коэффициенты – в строках № 15 и № 16 соответственно.

Аналогии

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

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

(См.MainNotion_Date)

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

(См.MainNotion_Struct.)

3) Метод анализа иерархий имеет аналогии с теорией неотрицательных матриц.
Расчеты рейтингов, проводимые в методе анализа иерархий, математически основываются на методах расчетов собственных векторов для неотрицательных (и в частности, для стохастических) матриц.

(См. MainNotion_Date)

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

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

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

Cтруктуры

1) Узел – общее название для всех возможных решений (альтернатив), главного критерия (главной цели) рейтингования решений, всех факторов, от которых, так или иначе, зависит рейтинг. Название узла совпадает с названием соответствующего решения, критерия или фактора. Заметим, что с математической точки зрения схема ситуации принятия решения (структура модели), которая строится в методе анализа иерархий, является графом. Таким образом, понятие «узел» вполне оправдано. Ясно также, что решения, критерий и факторы являются «узлами» проблемы принятия решения.

2) Уровень – группа всех однотипных (равноправных, однородных, гомогенных и т.п.) узлов. Название уровня отражает назначения, функцию группы узлов в ситуации принятия решения. Каждый узел определяется не только своим названием, но и названием уровня, которому он принадлежит. Ясно, что отдельный уровень образуют альтернативные решения (узлы этого уровня однотипны в том смысле, что они являются решениями; прочие узлы таковыми не являются). Главный критерий рейтингования, как правило, один – это отдельный уровень. На рейтинг оказывают влияние несколько групп факторов – это также уровни.

3) Вершина – узел, соответствующий главному критерию (главной цели) отбора альтернатив.

4) Связь – указание на наличие влияния одного узла (доминирующего) на другой (подчиненный).

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

Связь от узла-фактора к узлу-фактору означает, что важность учета второго фактора рассматривается с точки зрения первого фактора.

5) Кластер – группа узлов одного уровня, подчиненных некоторому узлу другого уровня –вершине кластера (доминирующему узлу).

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

Кластер определяется: 1) своей вершиной, 2) названием уровня, 3) списком узлов.

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

Эта система является иерархической (но не является строгой иерархией).

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

Название системы отражает ее назначение, принадлежность к сфере деятельности, в которой принимается решение.

7) Иерархия – система, в которой уровни расположены и пронумерованы так, что: 1) нижний уровень содержит рейтингуемые альтернативы, 2) узлы уровней с большими номерами могут доминировать только над узлами уровней с меньшими номерами. Таким образом, в иерархии связи определяют пути одной направленности - от вершины к альтернативам через промежуточные уровни, которые состоят из узлов-факторов. Система представляет собой строгую иерархию, если допустимы связи только между соседними уровнями от верхнего уровня к нижнему.

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

Формирование структуры без обратных связейRules_WithOutBackLink (иерархии) и формирование структуры с обратными связямиRules_WithBackLink производятся по определенным правилам.

Данные

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

Часто трудно непосредственно определить набор приоритетов (вектор приоритетов) узлов кластера. Тогда используется процедура парных сравненийMethodUse_TwineCompare и метод собственного вектораRules_EigenVectorMethod.
2) Пaрные сравнения узлов кластера – оценки (качественные или количественные) отношения приоритета одного узла к приоритету другого, т.е. результаты парных сравнений – это оценки важности (предпочтительности, вероятности и т.п.) каждого узла кластера относительно каждого из других по критерию, заключенному в вершине кластера. Результат парного сравнения – оценка отношения «весов» сравниваемых объектов («веса» объектов численно выражают их предпочтительность, оптимальность, значимость и т.п.). Цель парных сравнений – определение приоритетов узлов кластера. Для того, чтобы уточнить, в каком смысле название вершины кластера является критерием для проведения сравнений используется формулировка критерия для парных сравненийAdvice_TwineCompareCriterion.

Для проведения парных сравнений задаются параметры: шкала сравнений и способ сравнений. При проведении парного сравнения объектов

достаточно установить только один из результатов

(оценка отношения «веса» объекта

и весу объекта

) или

, так как

.

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

Т.е. если результату сравнения пары объектов ставится в соответствие значение

на шкале, то число

- оценка отношения «весов» объектов («веса» объектов численно выражают их предпочтительность, оптимальность, значимость и т.п.Examples_Test2).

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

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

Дискретной шкале соответствует конечный набор чисел. Дискретные шкалы отличаются по величине наибольшего значения (при количественных сравнениях) или по количеству основных градаций (при качественных сравнениях).

Если число

- верхний предел шкалы, то

- нижний предел шкалы, т.е. все результаты парных сравнений, выраженные в такой шкале, лежат в пределах от

до

. Если результату сравнения пары объектов соответствует единица, то значения «весов» объектов оцениваются как равные. Кроме того, для дискретной шкалы

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

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

до

.

Непрерывная шкала имеет непрерывный набор градаций (между основными делениями шкалы есть всевозможные промежуточные). Градациям непрерывной шкалы соответствуют числа на отрезке числовой прямой. Непрерывные шкалы отличаются по величине наибольшего значения (при количественных сравнениях) или по количеству основных градаций (при качественных сравнениях). Если «вес» объекта

оценивается как превышающий «вес» объекта

, результату

парного сравнения объектов

соответствует значение на шкале, большее единицы.

В противном случае

Формулировка задачи принятия решения

Часто экономические, медицинские, политические, социальные, управленческие проблемы имеют несколько вариантов решений. (Эти решения относятся к одной проблеме, и в этом смысле они однородны. По отношению друг к другу варианты решений являются альтернативами.)
Таким образом, в типичной ситуации принятия решения:

1) рассматриваются несколько вариантов решения,

2) задан критерий, по которому определяется в какой мере то или иное решение является подходящим,

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

Иерархия (структура и данные)

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

Данные взяты из таблицы , построенной на основе условий задачи.

Результаты (подготовка к расчетам и просмотр)

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

С учетом условий задачи заданы ограничения,

которые в итоге приняли вид (на предыдущем рисунке – этап 4)

А затем получены результаты (на предпоследнем рисунке – этап 6).

(на графике «распределение ресурсов» - количества тонн смешанной нефти для каждой технологии; прибыль от переработки тонны примерно 1528 рублей 43 копейки)
После этого на основе данных о долях нефти в каждой технологии (см. , строки № 27 и № 28) получены результаты:

Источник задач

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

В связи с этим возникают следующие вопросы: какой метод нужен иCommonInf_MetodSelect какова .CommonInf_TaskDefination

Эффективность применения метода

Если для принятия решений достаточно использовать только объективные данные, то в смысле точности и быстроты получения результата более предпочтительными могут быть другие методы (например, методы оптимизации целевого критерия).

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

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

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

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

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

Какой метод нужен?

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

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

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

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

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

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

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

Преимущества и недостатки метода

Процесс

Загруженность процесса, тонн в сутки
Минимальная
Максимальная
№ 1

Результаты

Смежные научные разделы

Метод анализа иерархий представляет собой междисциплинарную область науки.

Обоснование вычислительных процедур метода проводится с помощью теории неотрицательных матриц.
Основным инструментом для сбора данных, благодаря которому метод практически не имеет аналогов при работе с качественной информацией, является процедура парных сравнений. Психологические обоснования шкал сравненийRules_PsychologicBasis основаны на результатах исследований стимулов и реакций.
Анализ структуры моделиMethodUse_Analize, которой оперирует метод анализа иерархий, проводится с помощью процедур, разработанных в теории графов.
При проведении процедуры согласованияMethodUse_Coordination и при решении обратной задачиMethodUse_InversTask используются методы оптимизации (нелинейного программирования).

Сопутствующие проблемы

Задача принятия решенияCommonInf_TaskDefination и сопутствующие задачиCommonInf_SatelliteTask содержат ряд проблем, справиться с которыми позволяет метод анализа иерархийCommonInf_Features, в то время как применение других методов поддержки принятия решения может оказаться неэффективным. (См. CommonInf_Valuation, условия обоснованного применения методаCommonInf_UseConsition, эффективность применения методаCommonInf_Effectivity.)
Перечислим ряд типичных проблем.

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

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

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

3) Влияния различных факторов на выбор оптимального решения сложны и запутаны.
В реальных задачах часто имеют место так называемые «обратные связи». Это особенно ярко проявляется, когда принимается решение, требующее значительного времени на воплощение. В таком случае оказывается, что факторы, определяющие значимость решения, сами зависят от принятого решения.

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

Кроме того, некоторые факторы влияют на принятие решения опосредованно (одни факторы влияют на важность других). Из-за этого также возникают затруднения с определением нужного набора факторов.

4) Нет точной количественной информации, необходимой для решения задачи.

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

5) Имеющиеся данные противоречивы.

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

Простым примером являются непоследовательные суждения. Человек, планируя выходные, вполне может рассуждать так, сравнивая последовательно по парам имеющиеся варианты: «Лучше отправиться на рыбалку, чем с семьей в парк развлечений», «В парке с семьей гораздо лучше, чем с друзьями на охоту», «Охота лучше рыбалки». Это нелогично, но довольно естественно.

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

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

7) Нет четкой и универсальной методики составление рейтинга рассматриваемых решений.

Сопутствующие задачи

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

1) Выявить наиболее неясные и противоречивые этапы создания модели для поддержки принятия решенияMethodUse_Create:

     а) является ли рассматриваемый набор решений полным,

     б) учтены ли все группы факторов, влияющих на выбор наиболее приоритетного решения,

     в) определены ли все существенные влияния главного критерия, факторов и альтернатив друг на друга,

     г) известны ли сравнительные оценки того, как сильно влияют главный критерий, факторы и альтернативы друг на друга, имеются ли противоречия в оценках (какова согласованность сравненийRules_Coordination?),

     д) имеются ли альтернативные мнения по рассматриваемой проблеме, насколько они различаются.

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

3) Оценить и минимизировать противоречивость данных, использующихся для определения приоритетов рассматриваемых решений.

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

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

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

6) Учесть, что обычно по рассматриваемой проблеме имеется множество мнений. Это приводит к необходимости выбора решения при наличии нескольких эффективных схем принятия решения и нескольких наборов правдоподобных данных. Т.е. необходима работа при наличии множества данныхAdvice_WorkInGreatlyOption.

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

С необходимостью решения перечисленных выше задач и ряда других связаны возможности метода анализа иерархийCommonInf_Features и особенности реализации метода в системе «Император».

Технологии принятия решений: метод анализа иерархий

ЗАО «НЕЙРОСПЛАВ»
Быть или не быть? Как принять правильное решение? Этот вечный вопрос мы задаём себе на протяжении всей жизни. И как часто принимаем решения в лучшем случае на основе интуиции, а зачастую просто «тыча пальцем в небо».
Хорошо известно, что методами рационального осмысления сложных проблем владеют лишь немногие «самородки», которые и преуспевают в жизни. Но как же быть остальным? Ведь решения надо принимать каждый день! А если задача очень сложна, многогранна, информационно неполна, то здесь на одной интуиции далеко не уедешь.
Как сделать процесс принятия решения комфортным, технологичным, а самое главное, эффективным, если Вы – руководитель предприятия, или аналитик, или просто человек, который львиную долю своего времени должен тратить на это?
В настоящее время существует множество информационных технологий, позволяющих предельно облегчить жизнь и помочь в решении проблем, связанных с процессами принятия решений в различных предметных областях. В частности, очень распространены сейчас системы поддержки принятия решений на основе Метода Анализа Иерархий, разработанного американским ученым Т. Саати.
В данной статье изложены основы этого метода, несколько модифицированного сотрудниками ЗАО «НЕЙРОСПЛАВ».

Технология

Использование сортов нефти, тонн в сутки
Сорт А
Сорт Б
№ 1

Типичные варианты задачи принятия решения

Задача принятия решений чрезвычайно остро стоит перед
§ работниками управления;
§ экономистами;
§ финансистами;
§ социологами;
§ политиками;
§ консультантами;
§ оценщиками;
§ работниками здравоохранения;
§ военными;
§ психологами;
§ работниками социальной сферы;
§ научными работниками,
которые всегда стоят перед выбором наилучшего (наиболее безрискового, дешевого, качественного…) решения из множества существующих альтернатив.
Вот примеры решаемых ими типичных задач.
1. Рейтинг клиентов (какой из клиентов чаще покупает мои товары? кто из потенциальных клиентов является наиболее перспективным?).
1. Анализ рисков (например: вложения в какой из рассматриваемых руководством банка проектов наименее рискованны?).
2. Распределение ресурсов.
Пример.
Руководство завода рассматривает перспективные проекты развития. Для них создается модель рейтингования. В итоге каждому проекту приписывается доля от единицы. Эти доли показывают, какой процент от имеющихся ресурсов (сырья, денег и т.п.) надо вложить в каждый проект.
3. Планирование от достигнутого.
Пример.
Исходя из имеющихся: основных фондов, кадров, сырья, инфраструктуры, партнеров, конкурентов, конъюнктуры, влияния государства, имеющейся финансовой поддержки составляется рейтинг возможных положений предприятия через год, если все останется «как сейчас»: банкротство, бум основного производства, перепрофилирование, увеличение экспорта, захват или потеря рынков и т.п.

Когда рейтинг известен, принимаются меры по поддержанию позитивных тенденций и подавлению негативных тенденций.

4. Планирование желаемого будущего.

Пример.

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

5. Комбинированное планирование для определения приоритетов деятельности, позволяющей сблизить результаты планирования от достигнутого и планирования желаемого будущего.

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

7. Анализ эффективность-стоимость.

Пример. При исследовании возможностей разработки полезных ископаемых региона получены рейтинги: а) по главному критерию «эффективность (высокая) добычи»: уголь – 0,45; железная руда – 0,3; фосфориты – 0,15; известняк – 0,1; б) по главному критерию «стоимость (низкая) добычи»: фосфориты – 0,5; железная руда – 0,3; известняк – 0,1; уголь – 0,1. Тогда, находя отношения относительной оценки эффективности к стоимости, получим рейтинг по критерию «эффективность-стоимость»: уголь – 4,5; железная руда – 1; известняк – 1; фосфориты – 0,3. Принято решение разрабатывать уголь и руду, не разрабатывать известняк и фосфориты.

8. Принятие кадровых решений.

Пример.

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

9. Разрешение конфликтов.

Пример.

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

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

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

11. Диагностика возможных сценариев развития ситуации.

12. Построение зависимостей.

Пример.

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

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

Условия обоснованного применения метода

Важным требованием, обеспечивающим обоснованность применения метода, является квалифицированность экспертов, принимающих участие в создании структуры модели принятия решения, подготовке данныхRules_DatePreporation и в интерпретации результатовMethodUse_ResultInterpritation, т.е. их способность давать правильную непротиворечивую информацию. Во многом обоснованность решения, принятого с помощью иерархического анализа проблемы, связана: 1) с полнотой учета факторов, определяющих рейтинг решений, 2) с полнотой учета связей между целью рейтингования, факторами и возможными решениями, 3) адекватностью формулировок критериев для парных сравненийAdvice_TwineCompareCriterion тем целям, которые преследуются для построения модели.

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

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

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

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

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

Возможности метода анализа иерархий

Задачи принятия решения

Процессы принятия решений в различных сферах деятельности во многом аналогичны. Поэтому необходим универсальный метод поддержки принятия решений, соответствующий естественному ходу человеческого мышления.
Часто экономические, медицинские, политические, социальные, управленческие проблемы имеют несколько вариантов решений. Зачастую, выбирая одно решение из множества возможных, лицо, принимающее решение, руководствуется только интуитивными представлениями. Вследствие этого принятие решения имеет неопределенный характер, что сказывается на качестве принимаемых решений.
С целью придания ясности процесс подготовки принятия решения на всех этапах сопровождается количественным выражением таких категорий как «предпочтительность», «важность», «желательность» и т.п.
Задачи принятия решения можно рассмотреть следующим образом.
Пусть имеются:
1. несколько однотипных альтернатив (объектов, действий и т.п.),
2. главный критерий (главная цель) сравнения альтернатив,
3. несколько групп однотипных факторов (частных критериев, объектов, действий и т.п.), влияющих известным образом на отбор альтернатив.
Требуется каждой альтернативе поставить в соответствие приоритет (число) – получить рейтинг альтернатив. Причем чем более предпочтительна альтернатива по избранному критерию, тем больше ее приоритет.
Принятие решений основывается на величинах приоритетов.
Простой пример.
Руководителю фирмы требуется решить, какую программу для бухучета следует приобрести. Альтернативы – предлагаемые на рынке программы: «1С», «Парус», «С2», «Бухгалтер–3», «программа, изготовленная на заказ».
Главная цель – выбор наилучшей программы для бухучета. Факторы, определяющие выбор, - параметры программы: стоимость, защищенность информации, гибкость настройки, расширяемость, нетребовательность к ресурсам и др.
Составляется рейтинг программ.
Принимается решение - купить программу, которая стоит первой в рейтинге.
Задача принятия решения имеет две главные разновидности:
1. задача выбора (выбрать или отвергнуть несколько вариантов из группы возможных),
2. задача распределения ресурсов (каждый из рассматриваемых вариантов учитывается в соответствии с его приоритетом).
Огромное множество задач сводится к задаче принятия решения в приведенной здесь формулировке (хотя мы порой этого и не подозреваем). Заметим, что у реального процесса принятия решения имеются сопутствующие проблемы CommonInf_SatelliteProblem, которые успешно решаются с помощью метода анализа иерархий.

Архитектура приложения

ВComshare MPC нет привязки к определенной базе данных, поэтому приложение может функционировать как на реляционной БД, так и на многомерных платформах. Фактически модуль Comshare MPC Application Services позволяет выполнять интеграцию с наиболее популярными на сегодняшний день технологиями, такими как Microsoft SQL Server, Microsoft Analysis Services, Oracle RDBMS и Hyperion Essbase. (С января 2003 года Comshare не продает Hyperion Essbase, но по-прежнему поддерживает клиентов, использующих этот продукт).
Независимость от типа базы данных позволяет клиентам Comshare сократить вложения в технологическую инфраструктуру и подготовку специалистов, упрощая поддержку и сводя к минимуму потребность в обучении.

Цикл финансовой обработки

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

Динамическое финансовое хранилище данных

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

Дополнительные модули

Вместе спродуктом предлагается два дополнительных модуля. Модуль Production Reporting (Отчетность по производству) использует продукт Crystal Reports, автоматизирует процесс создания, распространения и поддержки форматированных отчетов. Предоставляются шаблоны отчетов, а с помощью дизайнера Crystal Reports можно создавать свои собственные. Шаблоны связываются с конкретными представлениями данных для создания множественных отчетов, которые затем объединяются в книги. Отчеты генерируются в форматах Crystal Reports, HTML или Excel.
На карманных компьютерах, оснащенных ОС Microsoft Pocket PC, применяется модуль Pocket Analytix (Аналитика для карманных компьютеров), который обеспечивает доступ для записи/чтения, а также передает предупреждения мобильным пользователям. Таким способом, торговый агент может сразу же обновить прогноз, не ожидая своего возвращения в офис. Однако с учетом ограниченных размеров экранов карманных компьютеров практический смысл выполнения анализа на них остается под вопросом.

Гибкое определение форм ипроцессов

Формы можно создавать в соответствии с теми показателями, которые имеют значение для организации.

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

Одно определение формы можно использовать в нескольких процессах.

Импорт данных изразрозненных бухгалтерских книг, баз и других источников

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

Консолидация данных

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

самостоятельное приложение для финансовой консолидации,

Компания Comshare образована в1966 году и является одним из старейших поставщиков OLAP-приложений на рынке управления эффективностью бизнеса (BPM, business performance management). Основные продукты Comshare ? это:

FDC ( самостоятельное приложение для финансовой консолидации, подготовки обязательной внешней и управленческой отчетности);

Decision (среда разработки для создания пользовательских Web-приложений Business Intelligence, обеспечивающая интерфейс к Comshare MPC);

MPC ? главный продукт Comshare для управления эффективностью бизнеса. MPC версии 5.0 (вышедший в октябре 2002) поддерживает полный цикл управления эффективностью бизнеса. Основные нововведения продукта: бюджетирование по сотрудникам и ресурсам, расширение возможностей финансовой консолидации, а также более четкая интеграция с продуктами платформы Microsoft Business Intelligence.

Модульный подход

Традиционно, BPM-решения составляются из нескольких приложений, использующих различные базы данных, в том числе и собственной разработки («фирменные»). Однако Comshare MPC представляет собой единое модульное приложение, работающее на централизованной базе. Благодаря такому уровню интеграции продукт оставляет целостное впечатление, что выделяет его на фоне разработок конкурирующих фирм, как-то: Hyperion Solutions (Hyperion Planning и Hyperion Financial Management) и Oracle (Oracle Financial Analyzer), которые либо делают то же самое, но с использованием нескольких приложений, либо решают лишь часть задач управления эффективностью бизнеса.
Comshare MPC состоит из пяти взаимозависимых модулей.
Planning (Планирование). Этот модуль предназначен для финансового планирования и обеспечивает ряд дополнительных функций для поддержки процесса стратегического планирования. Для того чтобы разносторонне оценить деятельность компании (с точки зрения юридического лица, продукта, рынка, времени и т. п.) используются бизнес-модели. С их помощью можно проводить анализ возможностей: варьируя различные предпосылки (входные данные), можно, например, выяснить, как 10?15%-ый рост валовых доходов повлияет на доходность акций. Результаты подобных анализов передаются в централизованную базу (но могут быть также сохранены и на локальной машине).
Кроме того, есть специальная функция Goal Seeking (Поиск цели), которая, зная результат расчета какого-то показателя, позволяет определить входные параметры, т.е. позволяет определить условия достижения некоторой цели. Таким образом, можно выполнять планирование «сверху-вниз» для всех подразделений и сравнивать их с планами, разработанными по методу «снизу-вверх» в процессе бюджетирования.
Budget (Бюджет). Модуль предназначен для поддержки итерационного процесса бюджетирования («снизу-вверх»).

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

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

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

В состав модуля входят два дополнительных компонента. Первый, Salary Planning (Планировщик зарплат), предназначен для планирования на уровне отдельного сотрудника и позволяет распределять расходы на сотрудника по отделам или ЦФО (центров финансовой ответственности), а также по дополнительным измерениям, таким как проект или операция. Таким образом, Comshare MPC поддерживает анализ эффективности проектов. Кроме того, можно рассчитать амортизацию и балансовую стоимость на основе предопределенных профилей ресурсов. Эти показатели можно использовать для второго компонента модуля бюджетирования ? Asset Budgeting (Бюджетирование основных средств).

Consolidation (Консолидация). Модуль предназначен для сведения бухгалтерских книг. Обеспечивает все необходимые функции: конвертацию валют, исключения внутри компании, аудиторские проверки. Модуль консолидации содержит инструмент отображения данных, предназначенный для преобразования данных из различных исходных систем, а также поддерживает загрузку и консолидацию данных для разрозненных организаций, которые работают с разными планами счетов, бухгалтерскими книгами и временными структурами.

Такой инструмент отображения может использоваться для загрузки данных из других источников, таких как системы управления взаимодействием с клиентами (Customer Relationship Management, CRM) и системы управления ресурсами предприятия (Enterprise Resource Planning, ERP) и традиционных (legacy) систем.

Forecasting (Прогнозирование). В модуле реализован ряд технологий временного прогнозирования, в том числе метод Хольта-Уинтерса (Holt-Winters), экспоненциальное сглаживание, метод Бокса-Дженкинса (Box-Jenkins), которые можно применить к статистическим данным для генерации достоверных прогнозов на основе выявленных тенденций. Одновременно для каждого набора статистических данных можно прогнозировать несколько комбинаций измерений (единица, продукт, канал распространения и т. п.). Приложение Comshare MPC автоматически выбирает технологию, которая даст наиболее статистически достоверный прогноз. Таким образом, модуль прогнозирования можно использовать для создания индивидуальных бюджетов для всех участников процесса бюджетирования на основе данных за прошлые периоды. Кроме того, можно создавать автоматические «скользящие» прогнозы, по мере загрузки фактических данных и сравнения их с планом.

Management Reporting/Analysis (Управленческая отчетность/анализ). Модуль доступен из всех других компонентов и позволяет пользователю анализировать данные и текстовую информацию в виде специальных представлений данных и диаграмм. Обычно для представления данных используется OLAP-технология, в том числе операции углубления, вращения, цветового кодирования, возможность сортировать представления по определенному столбцу, выполнять вычисления непосредственно на экране и сохранять индивидуальные версии. Кроме того, представления конфигурируются так, чтобы выполнялась детализация до уровня транзакций, например до записей в главной бухгалтерской книге.

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

Также разработано два дополнительных метода визуализации: OverView (Общий обзор) и Exception Alerts (Предупреждения об исключениях), которые отличают продукт Comshare MPC от лежащей в его основе технологии Decision.

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

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

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

Обеспечение множества перспектив бизнес-модели

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

Определение бюджетных критериев

Исходя изстратегических планов организации, администратор бюджета распределяет цели и задает критерии бюджетирования, как-то:

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

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

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

Определение назначений иправ доступа

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

Планирование ибюджетирование фирмы SAS

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

Задавать несколько процессов планирования и добиваться согласованности данных между ними.

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

Автоматически использовать исторические данные для создания более точных и своевременных бюджетов и планов.

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

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

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

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

Быстро вносить изменения, которые происходят на рынке или внутри организации, а также распространять информацию о «факторах развития бизнеса» (business drivers) среди подразделений и внутри циклов планирования.

Проводить анализ в иностранной валюте, удовлетворять требованиям к отчетности.

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

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

Продукты SAS Financial Management представляют собой не просто набор приложений (главную бухгалтерскую книгу, дебиторские и кредиторские счета, платежные ведомости). В них интегрируются данные из транзакционных систем и объединяются в унифицированную корпоративную структуру. SAS Planning обеспечивает аналитические возможности для планирования и бюджетирования, просмотра информации в различных разрезах, модификации и создания сценариев, быстрой адаптации к изменениям в организации или на рынке.

Приложения SAS Financial Management реализованы в клиент-серверной архитектуры и используют Web-технологии. При работе с продуктом SAS Planning имеются следующие возможности:

Администрирование и управление процессом планирования на всех уровнях.

Совместное использование форм подготовки бюджета различными пользователями.

Разработка удобных для пользователя форм для держателей бюджета.

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

Простой анализ бюджетов в разных аналитических разрезах.

Подготовка данных для анализа иотчетности

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

Проверка работы пользователей

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

Распределение (аллокации) расходов

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

Создание форм ввода данных

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

Финансовые и нефинансовые данные за прошлые периоды, являющиеся основой для нового финансового плана.

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

Расчеты, которые отражают ключевые бизнес-факторы.

Ссылки, которые автоматически отражают изменения, которые происходят между взаимосвязанными элементами.

Текстовые комментарии, которые проясняют суть элементов формы или подсказывают пользователю возможные действия.

Вход всистему и ввод данных

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

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

Comshare MPC ? корпоративное приложение, которое обычно внедряется профессиональной службой поддержки фирмы Comshare или другими фирмами, занимающимися консалтинговыми услугами. Продолжительность процесса внедрения может колебаться от нескольких недель до нескольких месяцев, в зависимости от сложности бизнес-процесса, который необходимо реализовать, а также от набора используемых модулей. Для выбора модулей и данных, доступных каждой из групп пользователей, администратор пользуется инструментом View Manager. Например, оперативное руководство отвечает за ввод бюджета своего отдела, поэтому ему предоставляется доступ к модулям Budget и Reporting/Analysis. Современный продукт с широкими возможностями
Comshare MPC ? хорошо продуманный программный продукт с удобным пользовательским интерфейсом, предоставляющим множество функций для решения задач финансового управления, планирования и контроля в рамках предприятия. Компании, ищущие интегрированное приложение с гибким подходом к выбору сервера базы данных, с успехом могут применить его в своей практике.
Компания Geac Computer Corporation Limited, поставщик ПО для управления эффективностью бизнеса, приобрела компанию Comshare летом 2003-го года. (Прим. переводчика.)

Выполнение отчетности ианализа

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

бюджетирования требуют очень больших временных

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

Характеристики BI-среды

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

Доступность данных

Интеграция данных

Простота интерпретации данных

Стабильность данных

Совместное использование информации

Доступность данных: В BI-среде должны быть доступны данные по всем видам деятельности компании. Это очень важно, так как большинство необходимых пользователю приложений будут обращаться к нескольким источникам данных. Обычно требуются сведения об агентах, агентствах, «третьих фирмах», отдельных продуктах, кодах схем и транзакциях, операциях с претензиями, о выплатах вознаграждений агентам и целях продаж.
Интеграция данных. Здесь подразумевается возможность объединять различные выборки данных в единое представление. Например, письменные контракты по страхованию жизни обычно хранятся в отдельной системе, а их администрированием занимается другая. Управление контрактами с постоянной и переменной премиями могут также относиться к разным приложениям. Тем не менее, в BI-среде должна поддерживаться интеграция для всех типов данных.
Простота интерпретации данных. BI-среда должна быть удобной для пользователя, помогая ему легко интерпретировать данные и получать на их основе новую информацию.
При оценке простоты интерпретации данных можно использовать следующие показатели:

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

возможность получить детальные данные (можно ли финансовые транзакции по контракту на аннуитет отследить по конкретному событию или временному интервалу?);

изолированность от физического представления данных (можно ли сформировать запрос без детальных знаний относительно форматов файлов и методов доступа?);

единственное определение отдельных элементов данных (гарантирует ли BI-среда, что оплаченные страховые услуги рассчитываются и интерпретируются одинаково, независимо от использования?).

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

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

Как поступить: купить готовое Хранилище или разработать собственное?

Проблему выбора между покупкой готового Хранилища и разработкой собственного можно сравнить с ситуацией, которая имела место раньше, при внедрении учетных систем. Действительно, в середине 80-х— начале 90-х клиент-серверные приложения приходилось, как правило, разрабатывать под конкретны нужды. Но сейчас, по ряду важных причин (стоимость, поддержка, доступность), большинство компаний предпочитают покупать готовые продукты.
Последние десять был только один путь к внедрению BI-среды на основе Хранилища — создание ее с нуля, своими силами. Поэтому многие Хранилища были разработаны с помощью собственных инструментов. Сейчас происходит такой же переход к готовым решениям, какой в свое время претерпели приложения учета и поддержки транзакций в середине и в конце 90-х.
При покупке готового Хранилища есть ряд преимуществ, которые перечислены в таблице 2.
Таблица 2. Преимущества готового Хранилища

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

В качестве примера рассмотрим вымышленную

В качестве примера рассмотрим вымышленную страховую компанию Full Life Services (FLS), предлагающую полный спектр услуг страхования жизни. С помощью примерно 1000 агентов фирма обслуживает 2 млн. клиентов, ее активы составляют 15 млн. долларов. Перед компанией возникла перспектива серьезной конкуренции со стороны нового европейского филиала гораздо более крупной страховой компании E-Life (тоже вымышленной).
После проведения маркетингового исследования было выяснено, что конкурент предлагает лучшие премии по определенному классу продуктов страхования жизни с переменной страховой суммой (variable life insurance), а также, что он разработал некоторую маркетинговую кампанию, направленную на клиентов FLS. Кроме того, E-Life использует более активный канал распространения, обеспечивающий непосредственное взаимодействие с клиентом. Прямой доступ через Internet уже налажен в E-Life и контракты подписываются через службу 1-800.
Руководство компании FLS пришло к выводу, что для сохранения своей доли рынка в ближайшие 12 месяцев необходимо выбрать тактику предложения новых разновидностей продуктов и провести дополнительное обучение торгового персонала. Стратегия разработки новой разновидности продукта (новая схема (plan) для старой услуги) — наиболее эффективный подход, так как на продвижение совершенно нового продукта потребовалось бы довольно много времени.
Для решения этой задачи необходима следующая информация:

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

Менеджерам по продажам требовалась информация о квалификации 20% лучших агентов, которые продвигали эти продукты последние 18 месяцев (по агентствам и регионам).

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

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

Данные по продукту и коду схемы страхования (plan code): первые поступают из системы, работающей под Windows NT, а вторые ? из файлов с мейнфрейма.

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

Данные по клиентам: необходимы для формирования четкого представления о клиентах, которые покупают страховые услуги данного типа. Здесь потребуются демографические показатели (доход, возрастная категория, средний семейный доход и т.п.). Эти сведения поступают частично из Dbase-базы под Windows NT, а частично из мейнфрейма.

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

Профили агентов: необходимы для того, чтобы установить профиль (квалификацию и образование) агентов, продвигавших продукт в течение последних 18 месяцев. Информация поступает из системы управления человеческими ресурсами, написанной под Unix на Oracle.

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

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

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

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

Решение проблемы— Хранилище данных

Рассмотрим подходы, применявшиеся ранее для решения проблемы доступа к данным.

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

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

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

Решение проблемы

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

В этой статье рассматривались проблемы,

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

[1]1-800 service ? служба специальных бесплатных номеров 1-800.

Алгоритмы планирования

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

Время доступа. Время ожидания пользователем ответа на запрос. Состоит из двух компонентов — времени настройки и времени ожидания.

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

Время ожидания. Период времени, в течение которого клиент ожидает появления в канале запрашиваемого пакета-дескриптора. В этот период клиентский сетевой интерфейс на клиенте отключен, и канал не прослушивается.

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

Время обслуживания (service time) — время, необходимое серверу для завершения передачи таблицы в канал нисходящей связи в режиме без приоритетного прерывания.

Относительная длительность запроса (stretch) — отношение времени отклика (доступа) на запрос к времени обслуживания.

Доступность (fairness) — среднеквадратичное отклонение для значений параметра stretch.
Время обслуживания зависит от размера таблицы, и, следовательно, за счет параметра stretch удается нормализовать значение времени доступа относительно размера таблицы. Низкое значение стандартного отклонения указывает на правильно выбранную методику планирования задач трансляции, а высокое значение говорит о том, что для некоторого класса таблиц трансляция ведется не в оптимальном режиме.

Рассмотрим подробнее пять основных алгоритмов-планировщиков:

Первым прибыл — первым обслужен (First ComeFirstServed, FCFS),

Первый — с наименьшим временем обслуживания (ShortestServiceTimeFirst, SSTF),

Первыми — самые популярные запросы (Most RequestsFirst, MRF).

RxW,

STOBS-?.

Первым прибыл — первым обслужен (ПППО). Этот простой метод планирования предполагает, что запросы обслуживаются и транслируются по мере их поступления.

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

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

RxW. В этой схеме используются преимущества ПСПЗ и ПППО. В каждом цикле трансляции сервер выбирает некоторый элемент с максимальным значением параметра R×W, где R — количество запросов на этот элемент, W — максимальное время ожидания ответа на запрос.

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

Особенности доступа к сводным OLAP-таблицам следующие:

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

Асимметричный доступ: запросы с OLAP-клиентов часто образуют некоторый «горячий участок» внутри решетки куба данных. Большинство запросов относится к таблицам небольшой размерности, а затем выполняется углубление в более детальные.

Зависимость извлечения: использование детальных таблиц для извлечения более абстрактных.

Планировщик трансляции сводных таблиц по запросу (Summary Tables On-DemandBroadcastScheduler,STOBS-?)

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

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

R — количество запросов на TX. Эта величина увеличивается с поступлением каждого запроса на эту таблицу.

A — промежуток времени, затраченный запросом QX в ожидании таблицы TX.

S — размер таблицы TX.

При решении какую таблицу отправить следующей сервер выбирает запрос с максимальным значением параметра (RхA)/S.

Параметр ? определяет меру гибкости при передаче сводной таблицы и ликвидирует из очереди трансляции несколько зависимых от нее таблиц. Например, если ? = 2 и сервер выбирает для трансляции таблицу TX, то из очереди удаляются все запросы на любую таблицу TY, которая в решетке поиска находится двумя уровнями ниже и может быть выведена из TX (см. рис. 2 — таблица, которую можно вывести из другой, всегда находится ниже последней).

Формально, TY может и не транслироваться в случае передачи TX, если Y

X и |X| – |Y| ?? . Следовательно, клиент может использовать таблицу TX, включающую изначально запрашиваемую им таблицу TY, если Y

X и |X| – |Y| ??.

Значение a меняется в диапазоне от нуля до максимального размера куба данных — MAX. Если ?= 0, то никакой гибкости в использовании сводных таблиц нет, и доступ клиента возможен только при точном соответствии. Если a = MAX, то клиенту передается первая же таблица, включающая его исходный запрос. В случаях, когда 0 < ? < MAX, транслируется первая таблица, включающая исходную и расположенная в решетке куба на a уровней выше.

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

При этом, значение ? известно серверу и клиентам (оно может входить в дескриптор таблицы).

В качестве примера рассмотрим решетку, показанную на рис. 3 (в ее узлах расположены сводные таблицы). QX — запрос на четырехмерную таблицу (d1, d2, d3, d4). Допустим, что узлы решетки, показанные на рисунке — это таблицы, на которые есть по крайней мере один запрос. Пусть ? = 2. Также предположим, что для трансляции выбрана таблица TX, соответствующая запросу QX. Тогда клиенты, запросившие таблицы (d1, d2), (d1, d3), (d1, d2, d3) и (d1, d2, d4) будут удовлетворены таблицей TX, а запросившие таблицы (d1), (d2), (d3) и (d4) будут ждать следующего цикла трансляции.

Рис. 3 Гибкость алгоритма.

Параметр (RхA)/S учитывает все факторы, влияющие на время доступа, параметр aопределяет меру гибкости алгоритма. Преимущество гибкого подхода к трансляции состоит в том, что удовлетворяется запрос клиента не только в случае точного соответствия. Недостаток — лишнее время, которое тратит клиент, прослушивая в канале детальную, а не сводную таблицу. Выбрав разумное значение ?, можно найти приемлемый баланс между сокращением времени ожидания и увеличением времени прослушивания.

Беспроводная OLAP-модель

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

Рис.1. Беспроводная OLAP-система
Например (см. рис. 1), зафиксировав значение по измерению «Клиент» из детализированной таблицы («Поставщик – Клиент») можно получить абстрактную таблицу («Поставщик»).
Таким образом, идея использования сводных таблиц для выведения одних таблиц из других используется довольно широко. Ее смысл состоит в выборе надлежащего набора таблиц для хранения, чтобы повысить скорость обработки запросов, учитывая пространственные ограничения.
Для упрощения процесса выбора используется решетка поиска, которая представляет собой направленный граф, отображающий пространство подкубов, между которыми фиксируются зависимости извлечения. Например на рис. 2 показана решетка для схемы «Поставщик (ПС) – Продукт (ПР) – Клиент (К)».

Рис.2. Решетка Кубов Данных
Зависимость извлечения сводных таблиц и идея решетки поиска применяется при выборе таблиц при трансляции в беспроводных каналах для минимизации времени ожидания ответа на запрос пользователя.

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

в режиме настройки (tune), прослушивая канал трансляции;

в режиме ожидания ответа (wait).

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

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

Период передачи таблицы называют циклом трансляции (broadcast cycle): каждая таблица передается в течение определенного цикла, который начинается с момента трансляции пакета-дескриптора. Длительности циклов для разных таблиц при этом могут различаться.

Пусть запрос в восходящий канал связи Q характеризуется набором Group-By атрибутов D. Тогда запрос представим как QD, а соответствующую ему таблицу как TD. Сводная таблица TD1 включает в себя таблицу TD2, если D2

D1, или, другими словами, TD2 зависит от TD1. Обозначим количество атрибутов (измерений) в множестве D как |D|.

Посылая в канал восходящей связи запрос на некоторую таблицу TR, клиент сразу же настраивается на нисходящий канал в поиске пакетов-дескрипоторов.

Обнаружив такой пакет, клиент классифицирует содержащуюся в нем таблицу (пусть это будет TB) следующим образом:

Точное соответствие: измерения в сводной таблице TB совпадают с измерениями в таблице TB (т.е. R = B).

Включающее соответствие: TB включена в TR, но TB в точности не соответствует TR (т.е., R

B и R ? B).

Нет соответствия: R

B.

Например: пусть R = («Поставщик – Продукт»), тогда B1 = («Поставщик – Продукт – Клиент») включает R, а для B2 = («Продукт») и B3 = («Поставщик – Клиент») не имеется соответствия. В зависимости от типа соответствия клиент будет либо настраиваться на получение дальнейшей последовательности пакетов для чтения таблицы TB, либо ожидать следующего цикла трансляции.

Методы трансляции

В беспроводных сетях трансляция является основным методом функционирования на физическом уровне. Именно она используется для распространения информации в беспроводных каналах и гарантирует масштабируемость при передаче большого объема данных. Особенно эффективно рассылку данных можно осуществлять, комбинируя две схемы — push- и pull-трансляцию. Этот подход основан на асимметрии в беспроводных коммуникациях и позволяет сократить энергопотребление в режиме приема. Предполагается, что клиентские устройства — небольшие, портативные, а в качестве источников питания обычно используют аккумуляторы. Что же касается серверов, то у них производительность канала связи и мощность для передачи больших объемов данных намного больше, чем у клиентских устройств.
В режиме push-трансляции сервер многократно посылает информацию без опроса клиентов. Любое число клиентов может прослушивать канал трансляции и извлекать информацию. Если данные подстроены точно под нужды клиентов, то такая схема эффективно использует низкую пропускную способность беспроводного канала и идеальна для достижения максимальной масштабируемости.
В режиме pull-трансляции клиенты посылают конкретные запросы. Если на одни и те же данные приблизительно в одно и то же время поступает несколько клиентских запросов, то сервер может их агрегировать и передать данные только один раз. Такая схема также позволяет эффективно использовать канал с низкой пропускной способностью и очевидно повышает эффективность приема информации пользователем.

Мобильные клиенты

Особая ситуация возникает, когда клиентские места представляют собой мобильные устройства. В данном случае самое главное — экономия энергии. Как уже говорилось, мобильные компьютеры работают от аккумуляторов, которые располагают ограниченным ресурсом мощности. Поэтому сокращение энергопотребления является одним из основных условий, которое должно быть учтено при разработке алгоритма трансляции.
Решением этой проблемы являются методы индексирования для запросов с одним или множеством атрибутов. Основная их идея состоит в том, чтобы обеспечить на клиенте достаточную информацию по индексации, при этом характер доступа к потоку данных мобильного устройства может меняться от «спящего»(doze) режима ожидания до активного (active), когда прослушиваются все поступающие данные. Очевидно, что в спящем режиме потребляемая мощность в десятки раз меньше, чем в активном.
Описанная выше модель соответствует условиям для мобильного доступа. Напомним, что в каждом заголовке пакета есть указатель, задающий временной шаг для следующего пакета-дескриптора в трансляции. Послав запрос, компьютер-клиент прослушивает нисходящий канал и настраивается на первый пакет-дескриптор. Если ему подходят следующие пакеты данных, он остается в активном режиме и скачивает транслируемую таблицу, если нет — переходит в спящий режим, экономя энергопотребление. Переключение в активное состояние происходит согласно прочитанному временному сдвигу только перед началом следующего цикла трансляции (то есть перед получением пакета-дескриптора для очередной передаваемой таблицы). Активизировавшись, клиент получает дескриптор и повторяет проверку на соответствие.

Сравнение алгоритмов

Все описанные выше алгоритмы сравнивались в соответствие с упомянутыми показателями эффективности. Превосходство схемы STOBS-? наблюдается как в отношении времени доступа, так и в отношении равнодоступности и сокращения энергопотребления.
В таблице 1 для каждого алгоритма указано среднее время доступа и среднее потребление энергии на запрос в сети, состоящей из90 клиентов.
Таблица 1. Сравнение алогоритмов-планировщиков.

Алгоритм	Среднее время доступа (сек)	Среднее потребление энергии (Дж)
ПСВО	9,5	0,64
ПППО	10,1	0,66
RxW	7,2	0,53
STOBS-0	4,9	0,43
STOBS-2	2,9	0,40

В статье проведен краткий обзор

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

Рассмотрен новый способ объединения запросов, основанный на зависимости извлечения (derivation dependencies) между сводными таблицами, в сравнении с методом, основанным на точном соответствии запросу.

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

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

Data Mining на службе у таможни

17.10.2002

Развитие корпоративных баз данных в сжатом во времени виде повторяет общую историю развития ИТ. Корпорации начинают с небольших разрозненных баз, работающих под управлением скромных СУБД, постепенно переходя к централизованным базам на основе полномасштабных СУБД. Однако, накопив огромное количество данных, корпорации осознают, что само по себе обладание данными еще не дает им преимуществ. В статье излагается опыт использования технологий «поиска знаний» применительно к задачам, стоящим перед Государственным таможенным комитетом РФ.
Для того чтобы база данных работала эффективно, необходимо как минимум обеспечить экспертам оперативный доступ к информации, который не требовал бы от них навыков программирования и позволял представлять данные в привычном для экспертов виде. За последние пять лет мы реализовали несколько систем OLAP. К сожалению, в рамках технологий OLAP основная тяжесть анализа по-прежнему ложится на плечи человека. Более того, встречаются задачи, в которых либо объем информации слишком велик, либо решение зависит от множества факторов, что делает невозможным анализ данных вручную. На сегодняшний день многие поставщики программного обеспечения, в том числе Oracle, выпустили ряд продуктов, реализующих алгоритмы Data Mining и позволяющих автоматизировать процесс анализа данных.

с анализом ставок таможенных пошлин

Анализ электронных копий ГТД, в совокупности с анализом ставок таможенных пошлин и агрегированных данных статистики внешней торговли Евросоюза и Российской Федерации, проведенный средствами технологии Data Mining позволил определить корреляции между товарными группами, сделать обоснованные предположения по определению «товаров риска» и «товаров прикрытия», а также дать оценку возможных потерь таможенных платежей.
Таким образом, проведенное исследование показало, что технологии Data Mining могут успешно применяться для выявления скрытых тенденций во внешнеторговой деятельности. При этом следует отметить, что в отличие от других методов поддержки принятия решений технологии Data Mining обладают гораздо более высокой степенью интеллектуальности и хорошей масштабируемостью, позволяя в значительной степени автоматизировать анализ данных.
Андрей Майоров () — сотрудник компании «РДТех».

Oracle Data Mining

Компания Oracle выпустила два программных продукта, реализующих алгоритмы поиска знаний: Oracle Data Mining Suite (Darwin) и Oracle 9i Data Mining (server option). Первый доступен уже в течение нескольких лет и, хотя степень его интегрированности с другими продуктами Oracle низка, предлагает достаточно мощный набор алгоритмов (классификационные и регрессионные деревья, нейронная сеть, кластеризация по ближайшим соседям). К безусловным достоинствам Darwin надо отнести наличие ряда утилит для подготовки входных данных, позволяющих объединять наборы, рандомизировать и трансформировать данные в соответствии с заданной функцией. Чрезвычайно полезной является наличие утилит предварительного анализа, в том числе построение гистограмм. Darwin интегрирован с MS Excel, что расширяет его возможности особенно в плане графики. Наличие графического пользовательского интерфейса делает доступным весь цикл работы с моделью для аналитиков, не имеющих достаточного опыта в программировании.
Oracle 9i Data Mining — сравнительно новый продукт и его первая версия включала лишь два алгоритма: простейший классификатор (Naive Bayes) по методу Байеса и поиск ассоциативных правил. Оба алгоритма хорошо известны и, несмотря на свою простоту, в ряде областей применений зарекомендовали себя как чрезвычайно успешные. Отличительной чертой Oracle 9i Data Mining является его интегрированность с Oracle Server причем не только при доступе к данным — алгоритмы реализованы как пакеты, хранимые в базе. Программный интерфейс реализован на Java, что делает взаимодействие с продуктом более гибким. Однако, в отличие от Darwin, графический пользовательский интерфейс полностью отсутствует. В последнем выпуске (Oracle Server 9.2) опция Data Mining была обогащена новыми алгоритмами. В частности, был добавлен адаптивный Байесов классификатор и O-кластеризация.

Сравнение статистических данных ЕС и РФ

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

ошибки ввода;

округление веса до целого значения в тоннах (в базе EC);

округление стоимости до целого значения в долл. (в базе РФ);

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

разница курсов валют в момент вывоза и ввоза товара;

различия в классификации ТНВЭД и ГС в РФ и EC, в результате чего некоторые товары могут быть учтены по разным группам ТНВЭД/ГС в статистике РФ и EC.
В то же время не могут быть непосредственно использованы оригинальные переменные: вес нетто и стоимость, так как различные группы товаров характеризуются различной ценой и характерными объемами перемещаемых товаров. Кроме того, цель анализа — не выявление расхождений между данными ЕС и РФ, а определение величины риска, связанной с данной группой товаров, т. е. величины относительного несоответствия между данными. В связи с этим в качестве основных переменных выбраны относительные разности по стоимости и весу нетто, определяемые как:

COST_RF, COST_ES — статистическая стоимость товаров данной группы по статистике РФ и EC соответственно, NETTO_RF, NETTO_ES — аналогичные показатели для веса нетто. Нормировка на минимальные значения обоснована, поскольку неизвестно истинное значение стоимости и веса, кроме того, это приближает распределение значений переменных к известному статистическому распределению (хотелось бы иметь распределение, хотя бы отдаленно напоминающее гауссово). Сравнить данные по всем группам можно, построив гистограмму для описанных переменных, показывающую, как часто встречается то или иное значение переменной (ось Х — значения переменной, Y — количество случаев, когда переменная принимала данное значение).

Oracle Darwin имеет утилиту для построения одно и двухмерных гистограмм данных, которой мы и воспользовались. На рис. 1 показаны нормированные распределения для относительного отклонения стоимости и веса для экспорта и импорта.

Рис. 1. Распределение относительных отклонений стоимости и веса между данными ЕС и РФ

Если бы различия между данными ЕС и РФ носили «естественный» характер, без фальсификации, то распределения были бы симметричными, а импорт совпадал бы с экспортом. И действительно, график, характеризующий вес, выглядит достаточно симметричным, а распределения для импорта и экспорта практически совпадают. Совершенно иная картина наблюдается в отношении стоимости. Если экспорт более или менее симметричен, то в случае импорта мы имеем гораздо больше случаев с заниженной по сравнению с данными ЕС стоимостью ввозимых товаров (отрицательные значения переменной dcost): вес груза легко проконтролировать, в то время как измерить стоимость невозможно. Кроме того, для большинства товарных групп таможенная пошлина взимается именно со стоимости. Однако при более подробном анализе становится ясным, что подозрительные аномалии наблюдаются и в поведении переменной netto. На рис. 2 показано совместное распределение относительных отклонений по стоимости и весу.

Рис. 2. Совместные распределения относительных отклонений стоимости веса. Слева — экспорт, справа — импорт

Поскольку выбранные нами переменные не являются полностью независимыми (стоимость = цена х вес), то ожидаемое распределение должно выглядеть как наклоненный на 45 градусов эллипс. Именно так выглядит распределение для экспорта. В случае же импорта вновь видны характерные фальсификации. Встречаются группы товаров, для которых при небольшом отклонении веса стоимость занижена на порядок. И есть товарные группы, в которых присутствует завышение веса при относительно правильной стоимости импортируемого товара. На первый взгляд это кажется странным. Зачем завышать вес ввозимого товара?

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

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

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

Основное отличие новых переменных — ограниченный диапазон принимаемых значений:

Распределение, аналогичное приведенному на рис. 2, в новых переменных показано на рис. 3.

Рис. 3. Совместное распределение относительных отклонений по стоимости (dCOSTmean) и весу (dNETTOmean) для случаев импорта

В данном случае налицо как минимум три кластера, а применение алгоритма Darwin Match позволило легко выделить 4 кластера (рис. 4).

Рис. 4. Кластеры совместного распределения относительных отклонений по стоимости (dCOSTmean) и весу (dNETTOmean) для случаев импорта

Интересно, что последний из кластеров (кластер 4) не идентифицируется «глазом» как отдельный кластер (рис. 3), в то время как ему соответствует наиболее насыщенная недостоверно оформленными декларациями область, что хорошо видно, если найденные кластеры представить в наших первоначальных координатах (рис. 5).

Рис. 5. Найденный с помощью Darwin Match кластер в переменных netto-cost

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

Товар риска — товар прикрытия

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

Первый критерий основной и означает, что один из товаров вероятнее всего сопутствует другому. Выбор условных вероятностей, вместо, например, коэффициента корреляций, обуславливается их большей чувствительностью. Коэффициент корреляции близок к единице лишь в случае, если оба товара все время ввозятся одновременно. Мы же налагаем гораздо более слабое условие: лишь один из товаров постоянно сопутствует другому, поскольку один из товаров может ввозиться в больших объемах без всякого сопровождения. Использованный критерий известен в литературе как алгоритм ассоциированных правил и, в частности, реализован в Oracle Data Mining 9i. К сожалению, использованные данные находились в базе Oracle Server 8, в связи с чем пришлось использовать собственную реализацию алгоритма.
Впрочем, высокая корреляция одного из товаров с другим еще не означает, что товар обязательно прикрывается другим: множество людей ежедневно покупают одновременно хлеб и молоко без всякого злого умысла. И при импорте товаров существуют случаи естественной корреляции между товарами. Чтобы очистить отобранные пары от таких случаев, мы наложили дополнительные условия: прикрытие должно быть экономически выгодно, а сравнительный анализ статистических данных должен подтверждать факт прикрытия.
Анализ предоставленных ГТК данных выявил значительное количество пар, удовлетворяющих выбранным критериям. Безусловно, не все они являются парами «товар риска — товар прикрытия». Эффективность реализованного алгоритма может быть подтверждена только в ходе дополнительных проверок на таможенных постах. Однако следует отметить, что число подобных пар существенно меньше, нежели общее число товарных групп, и их список вполне может быть использован как рекомендация по более тщательному досмотру определенных грузов.

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

Как видно из , на протяжении всего 2000 года вероятность ввоза шин вместе с заготовками очень высока — в среднем 95% за год. Случаев ввоза только заготовок практически не было. При этом коэффициент корреляции не столь велик, поскольку достаточно большой объем импорта шин не сопровождается заготовками. Сам по себе факт корреляции между этими группами товаров достаточно естественен, однако ставка таможенной пошлины в 2000 году на заготовки была в 5 раз ниже, нежели для шин — 5% и 25% соответственно. Более того, сравнительный анализ данных РФ и ЕС показал, что импорт заготовок согласно российским данным почти в 200 раз выше, чем по данным ЕС, а импорт шин ниже в 3,5 раза, если сравнивать объемы импорта по весу. При этом суммарный вес импорта по этим двум группам совпадает по данным РФ и ЕС с точностью до 20% ().

Похожая картина наблюдается и в стоимостном выражении. Стоимость ввезенных в РФ заготовок в 30 раз выше, чем вывезенных из стран ЕС, в то время как шин, если судить по декларированной стоимости, ввезено в 2,7 раза меньше вывезенного количества. Т. е., судя по приведенным данным, с большой вероятностью протекторные заготовки в 2000 году использовались рядом импортеров как прикрытие для ввозимых шин. Потери государства на таможенных пошлинах составили предположительно около 7 млн. долл.

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

Товары риска

Одна из основных задач, стоящих перед таможенными органами, состоит в выявлении преднамеренного искажения грузовых таможенных деклараций. В силу ограниченных ресурсов полная проверка всех перемещаемых через границу грузов невозможна. Однако ГТК собирает подробные базы данных по грузовым таможенным декларациям. Анализ этих данных может быть использован для выявления тенденций во внешней торговле РФ и по группам товаров, наиболее подверженных фальсификации при прохождении таможни — «товарам риска». Имея данные о таких товарах, таможенные посты могли бы более тщательно проверять прохождение соответствующих грузов и уменьшить потери от фальсификации таможенных документов.
Одной из особенностей задачи стало отсутствие «тренировочного» набора данных — данных, для которых было бы априори известно, какие из них являются попыткой фальсификации грузовой таможенной декларации, а какие представляют собой добросовестно задекларированные товары. Это существенно ограничивало круг алгоритмов, которые можно было использовать: например, популярные методы типа классификаторы Байеса, деревья решений, нейронные сети и т.п. требуют предварительного обучения на тренировочном наборе данных. В нашем распоряжении оставались лишь алгоритмы кластеризации и ассоциативных правил.
Предметом анализа является база данных Европейского Союза по внешней торговле с Россией и база грузовых таможенных деклараций (ГТД) Единой Автоматизированной Информационной Системы ГТК России. ГТД может оформляться одновременно на несколько перемещаемых вместе товаров. База данных ЕС содержит только агрегированную до уровня одного месяца и восьми знаков товарную номенклатуру внешнеэкономической деятельности. ТНВЭД — это десятизначный классификатор товаров, используемый таможенными органами. В 2000 году он содержал более 12 тыс. групп товаров, а также информацию об объеме и стоимости перемещаемых товаров. В российскую же декларацию заносится детальная информация о каждом грузе. В своем анализе мы использовали лишь часть информации, содержащейся в декларации: направление перемещения (импорт/экспорт); объем (вес); стоимость в долл.; дата оформления.

Автоматизация построения диаграмм.

Использование библиотек (репозитариев) УФО-элементов и формальных правил сборки конфигураций из этих элементов позволяет автоматизировать процесс построения диаграмм взаимодействия (УФО-моделей). Для формального обеспечения (т.е. автоматизации) процедур УФО-анализа (системно-объектного моделирования) применен математический аппарат теории паттернов Гренандера.
На основании результатов исследований [15] в настоящее время осуществляется реализация модуля автоматического построения диаграмм взаимодействия. Данный модуль решает задачу автоматической сборки УФО-модели из библиотечных УФО-элементов в соответствии с заданным контекстом.

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

В целях автоматизации применения метода УФО-анализа спроектирован и реализован CASE/ BI -инструмент анализа и моделирования «UFO-toolkit» (АС №7941) [11, 12]. Хотя название данного инструмента легко ассоциируется с аббревиатурой УФО (как и было задумано), в данном случае « UFO » – есть сокращение словосочетания «User Familiar Object» из английского компьютерного словаря, означающего «знакомый пользователю объект» (что также полностью соответствует сути дела).
Первой задачей, решаемой с помощью данного инструмента, в соответствии с методологией УФО-анализа, является построение классификации внешних (функциональных) и внутренних (поддерживающих) связей моделируемой системы путем специализации (итеративной) базовой иерархии связей. На основе данной классификации UFO-toolkit обеспечивает представление любой бизнес-системы (подсистемы и т. д.) в виде УФО-элемента, т.е. трехэлементной конструкции «Узел – Функция – Объект».
Суть алгоритма УФО-анализа, т.е. функционирования UFO-toolkit, может быть представлена следующими основными шагами:
- выявление узлов связей в структуре моделируемой системы на основании функциональных связей системы в целом (соответствующих классификации);
- выявление функциональности, поддерживающей (обеспечивающей, балансирующей) обнаруженные узлы;
- определение объектов, соответствующих выявленной функциональности, т.е. ее реализующих.
При этом первый шаг может быть отождествлен с этапом собственно анализа системы, второй – с этапом ее проектирования (моделирования), а третий – с ее реализацией.
УФО-элементы, собранные в различные конфигурации, образуют диаграммы взаимодействия, которые позволяют визуализировать функциональность УФО-элемента более высокого уровня. Таким образом, моделируемая система представляется в виде иерархии УФО-элементов, начиная с контекстной модели. Данное представление позволяет учесть различные аспекты (структурные, функциональные, объектные) этой системы в одной модели.
Однажды разработанные УФО-элементы могут храниться в специальных библиотеках для обеспечения компонентного подхода к моделированию бизнеса.

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

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

На логическом уровне библиотеки представляют собой фасетные классификации УФО-элементов, основанные на классификации связей. UFO-toolkit строит эти фасетные классификации автоматически, используя заданные диаграммы взаимодействия. Автоматическое построение библиотек на основе модели системы в значительной степени упрощает повторное использование УФО-элементов.

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

Для наглядности диаграмма декомпозиции контекстной модели нового программного инструментария моделирования UFO - toolkit на функциональные узлы, соответствующие его функциональным модулям выполнена с помощью самого этого инструмента (рис. 7).

Рис. 7. .

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

- Значительное снижение трудоемкости проектирования, за счет увеличения степени автоматизации аналитической деятельности.
- Повышение объективности анализа и адекватности моделирования.
- Использование при анализе и моделировании компонентной технологии, автоматизирующей процесс создания моделей, путем использования готовых (алфавитных) функциональных объектов, представленных в базе знаний в виде УФО-элементов.
- Обеспечение интеллектуального взаимодействия с пользователем, в частности, путем «узнавания» готовых компонент (УФО-элементов).

UFO - toolkit может быть применен в следующих случаях:

- Построение моделей существующего и планируемого бизнеса (со структурной, функциональной/процессной и объектной точек зрения) при проведении реинжиниринга бизнес-процессов.
- Моделирование бизнеса (организаций и предприятий) при выполнении консалтинговых проектов.
- Разработка распределенных информационных систем с применением средства бизнес-объектов CORBA (BOF).
- Разработка технических систем с применением CALS-технологии и системы стандартов STEP.

Общее представление об интерфейсе UFO - toolkit отображено на экранной форме (рис. 8), показывающей вариант декомпозиции узла купли и продажи товара (УКП) АООЗТ «Рога и копыта».

Рис. 8.

Имитационное моделирование.

Поддержка в перспективе имитационного моделирования позволит эффективно решать проблемы, возникающие при моделировании больших систем, и позволит обеспечить как точный анализ, так и визуальное представление альтернативных вариантов. Кроме того, проведение экспериментов с имитационными моделями позволит проводить не только анализ их характеристик, но и решать задачи синтеза таких систем, т.е. эффективнее решать задачи автоматизации построения моделей, используя количественные оценки альтернатив, полученные в ходе имитации.
Задача имитации функционирования системы на ее объектной модели приводит к необходимости моделирования различных функциональных (аналитических, логических и т.д.) зависимостей. Для решения данной задачи в рамках проекта по созданию инструмента UFO - toolkit разработан специальный язык сценариев ( scripting language ), а также компилятор и интерпретатор для него [16]. Данный язык позволяет описывать и визуализировать поведение УФО-элементов на этапе имитационного моделирования.

Эволюция CASE -средств моделирования

Представление о Business Intelligence отечественных специалистов, например [1], позволяет рассматривать программный CASE -инструментарий моделирования бизнес-систем и бизнес-процессов как разновидность BI -инструментария при условии, если он:

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

При этом в работах [2, 3] отмечается необходимость разработки «CASE - инструментария, ориентированного на рассматриваемую предметную область», а также то, что такой инструментарий должен обеспечивать:

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

Хорошо видно, что реализация при разработке CASE -инструментария требований 1) – 7) приводит к удовлетворению условий b ) и c ) его соответствия Business Intelligence .
Кроме того, в статье [4] отмечается, что наименьший вред организации принесет инструментарий моделирования, «лишающий разработчика той части «творческих» возможностей, которые ведут к разнообразию представления организационных моделей». При этом степень соответствия этому требованию инструментария, использующего нотацию SADT ( IDEF 0), оценивается как крайне низкая. Последнее требование непосредственным образом связано с тем, что инструментарий моделирования должен быть средством поддержки принятия решений, а не художественного творчества. Таким образом, реализация этого требования при разработке CASE -инструментария приводит к выполнению условия a ) его соответствия Business Intelligence .
Следовательно, можно утверждать, что в настоящее время происходит эволюция части CASE -средств, предназначенных для анализа и моделирования. И в результате этой эволюции CASE -инструментарий моделирования бизнес-систем становится средством для Business Intelligence , т.е. BI -инструментарием.
Рассмотрим инструментарий моделирования бизнеса, олицетворяющий этот эволюционный процесс на практике.

Методология, положенная в основу нового инструментария моделирования.

Фактические возможности инструментария визуального графо-аналитического моделирования бизнеса ограничиваются потенциальными возможностями метода моделирования, положенного в основу данного инструментария. Поэтому претензии к существующим инструментам и рекомендации по их усовершенствованию вполне обоснованы. Дело в том, что методы, положенные в их основу (DFD , STD , SADT / IDEF 0, IDEF 3, а также UML , а также ARIS), методами, по сути дела, не являются. Это только нотации, нормативные системы, языки (если у Вас большие претензии). На это обстоятельство уже неоднократно обращали внимание соответствующие специалисты (например, [5]). Кроме того, например, в [6] объясняется, что «метод – есть система правил и приемов достижения определенных результатов, исходящая из знания закономерностей исследуемого предмета, помогающая исследователю выбрать существенное, наметить путь восхождения от известного к неизвестному». Совершенно очевидно, что системы правил, используемые в рамках перечисленных выше нотаций, абсолютно никак не исходят «из знания закономерностей исследуемого предмета» и никак не помогают «выбрать существенное». А вот перспективный CASE -инструментарий, эволюционирующий в BI -инструментарий, в соответствии с требованиями [2 - 4] должен это делать. Следовательно, такой инструментарий должен основываться на реальном методе моделирования бизнес-систем и бизнес-процессов.
В связи с тем, что любая бизнес-система представляет собой социальную, хозяйственную (следовательно открытую, сложную) систему целесообразно для ее анализа и моделирования использовать системный подход. Но, так как системный подход существует не в единственном варианте, необходимо сделать правильный выбор среди множества этих подходов.
Грубо говоря, существует два вида системного подхода. «Традиционный» системный подход рассматривает систему как разновидность множества. Этот подход получил широкое распространение для исследования и проектирования технических и технологических устройств и процессов в рамках так называемой системотехники.

Этот подход в данном случае совершенно бесполезен по следующим причинам. Он не способен использовать категорию «цель» для объектов произвольной природы; в качестве первичной категории рассматривает «часть» («структуру» и «состав»), а не «целое» и его функцию; не учитывает иерархическую структуру внешней среды; не использует понятия адаптации системы к требованиям системы более высокого яруса. «Ноосферный» системный подход (или системология) рассматривает систему не как множество, а как функциональный объект, функция которого обусловлена функцией объекта более высокого яруса (надсистемы) [7]. Данный подход специально предназначен для исследования целенаправленного взаимодействия систем любой природы, связи между которыми рассматриваются как потоки элементов глубинных ярусов связанных систем. Это обеспечивается путем учета функционального характера целостности системы, иерархической природы внешней среды и процесса адаптации системы к запросу надсистемы. Концептуальный аппарат системологии позволяет единообразно описывать понятия теории организации, логистики, инжиниринга бизнеса, а также объектно-ориентированной методологии создания информационных систем [8 - 10].

Применение системологии к анализу и моделированию бизнеса позволяет создать эффективный метод моделирования бизнес-систем, удовлетворяющий требованиям [2 - 4, 6].

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

Интеграция этих трех аспектов позволяет представить любую бизнес-систему как элемент Узел–Функция–Объект (УФО-элемент, рис.1), формализующий три очевидных факта:

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

Рис.1. УФО-элемент с узлом (У) – перекрестком потоков o, g, f; функцией (F) – процессом преобразования потоков g, f в поток o; объектом (О) – материальным образованием, физически выполняющим данный процесс.

Узловая характеристика бизнес-системы это качественная характеристика входных и выходных потоков/связей. Она характеризует бизнес целостно как структурный элемент (подсистему) системы более высокого яруса (вышестоящей организации, рынка в целом и т.д.). При этом вышестоящей организации или рынку конкретная бизнес-система представляется перекрестком, т.е. узлом связей, по которым что-либо поступает к ней («втекает») от других и что-либо поступает от нее («вытекает») к другим. Если связи отсутствуют, то данную систему вообще нет смысла рассматривать. Таким образом, любая бизнес-система обязательно является и потребителем каких-то видов ресурсов (материальных и информационных) других систем и поставщиком каких-то видов ресурсов для других систем. Каждая бизнес-система характеризуется определенными видами связей с другими системами, категориальная классификация которых в зависимости от видов «протекающих» по ним ресурсов представлена на рис.2.

Функциональная характеристика бизнес-системы это абстрактная характеристика ее потенциальных способностей. Она характеризует бизнес целостно как функциональный элемент, способный обеспечить баланс «притока» и «оттока» по связям узла путем преобразования входных ресурсов в выходные. При этом баланс одного и того же узла может быть обеспечен, в принципе, разными наборами функциональных способностей (наборами процессов), т.е. разными функциональными зависимостями выхода от входа.

Рис. 2.

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

Например, АООЗТ (акционерное общество очень закрытого типа) «Рога и копыта» может быть представлено как УФО-элемент следующим образом.

В целом, как узел, АООЗТ является перекрестком связей/потоков представленных на рис.3 (в наименованиях связей через буквенно-цифровые обозначения показано, как эти связи вписываются в базовую классификацию связей на рис.2).

Рис. 3.

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

АООЗТ «Рога и копыта» в целом, как функция, в самом общем виде может быть представлена в виде процесса, изображенного на рис.4.

Рис. 4.

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

Как объект АООЗТ «Рога и копыта» в целом может иметь, например, следующие общие характеристики, которые также могут изменяться и дополняться (рис. 5):

Правило присоединения: элементы должны присоединяться друг к другу в соответствии с качественными характеристиками присущих им связей.
Правило баланса: при присоединении элементов друг к другу (в соответствии с правилом №1) должен обеспечиваться баланс «притока» и «оттока» по входящим и выходящим функциональным связям.
Правило реализации: при присоединении элементов друг к другу (в соответствии с правилами №1 и №2) должно быть обеспечено соответствие интерфейсов и количественных объектных характеристик функциональным.

Описанный кратко метод анализа «Узел-Функция-Объект» (УФО-анализ) дает в руки аналитика формально-семантический аппарат, который резко снижает «разнообразие представления организационных моделей». С другой стороны, он позволяет создавать предметно-ориентированные модели, обеспечивая сохранение и использование знаний об элементах бизнеса, которые могут отобразить любой бизнес с необходимой степенью адекватности, точности и подробности.

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

входные связи :

производственные,

обеспечивающие (вещественные, энергетические и информационные),

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

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

Таким образом, можно утверждать, что метод УФО-анализа является знаниеориентированным, а также системным и объектным одновременно.

Преимущества UFO-toolkit в сравнении с BPwin .

Как знаниеориентированный, системно-объектный CASE / BI -инструмент нового поколения, UFO - toolkit обладает рядом преимуществ в сравнении, например с BPwin , поскольку позволяет накапливать, систематизировать и использовать в дальнейшем знания о предметных областях, а также полноценно использовать результаты системного анализа бизнеса в ходе объектно-ориентированного проектирования информационной системы.
Сравнение BPwin и UFO - toolkit (с использованием данных о SADT и DFD нотациях из работ [13, 14]) представлено в таблице.

UFO-toolkit	BPwin
Использование формализованных средств (правил) для построения и модификации визуальных графоаналитических моделей, что существенно сокращает разнообразие представления организационных систем (бизнес-систем).	Отсутствие правил и методических рекомендаций по построению моделей организационных систем (бизнес-систем), которые бы сокращали разнообразие получаемых результатов.
Возможность поддержки содержательной классификации связей, что позволяет сориентировать инструмент на любую конкретную предметную область. Модели являются формально-семантическими.	Не имеется средств ориентирования на конкретную предметную область. Модели имеют совершенно формальный характер.
Поддержка компонентной технологии моделирования и проектирования вследствие наличия репозитария/библиотеки, что обеспечивает возможность учета, систематизации и передачи знаний о предметной области.	Отсутствует возможность применение компонентной технологии моделирования, а также возможность учета, систематизации и передачи знаний о предметной области.
УФО-анализ и инструмент UFO - toolkit согласуются с требованиями объектно-ориентированной технологии проектирования информационных систем и позволяют упростить начальные технологические процессы разработки объектных приложений.	Результаты, полученные при моделировании бизнес-процессов в BPwin малопригодны для использования при создании объектно-ориентированного программного обеспечения.
Структурные, функциональные и объектные (субстанциальные) аспекты рассмотрения бизнес-системы объединены в одной системно-объектной УФО-модели.	Все системно-структурные методы, реализованные в BPwin , требуют построения двух или трех моделей одного и того же объекта: функциональной (активностной), информационной (данных), а также динамической.
УФО-анализ обеспечивает автоматизацию построения диаграмм взаимодействия УФО-элементов (декомпозиции) с использованием библиотек по заданной контекстной УФО-модели.	Не существует перспектив автоматизации декомпозиции моделей.
Динамическая модель есть результат активизации (анимации) статической модели взаимодействия объектов системы; привлечения других средств не требуется.	Для создания динамических моделей требуется использование дополнительных специальных расширений или других средств, с которыми технологии, реализованные в BPwin , плохо согласуются.