Многообразие

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

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

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

Обще многообразие в поведении СУ	>=	Многообразие возмущений
		Многообразие управлений

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

Другими словами – многообразие может быть разрушено только многообразием. Это кибернетический аналог второго закона термодинамики.

Уровни взаимодействия. Относительная сила взаимодействия между различными компонентами СУ и уровнями иерархии.

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

Динамическая сложность

Рассмотрим некоторые аспекты сложности, которые проявляются в динамическом поведении системы.

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

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

Пример

Рассмотрим процесс, который является структурно простым, будучи в то же время динамически сложным

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

Приписывание каждой точке слева от середины основания треугольника число “0”, а каждой точке справа – “1”, получим последовательность чисел 0,0,1,0,0,1,…, порожденную этой детерминированной процедурой и математически неотличимую от последовательности, получаемой в распределении по закону Бернулли с параметром p=1/2 (другие значения p могут быть получены использованием прямых, отличных от диагонали квадрата).

Этот результат имеет определенное методическое и теоретическое значение. Действительно, если считать последовательность 0 и 1 выходом некоторого процесса, то не существует математического метода, позволяющего определить, является ли внутренний механизм, преобразующим вход в выход (последовательность 0 и 1), детерминированным или стохастическим. Иными словами, если не заглядывать внутрь “чёрного ящика”, то никакие математические операции не могут помочь определить, является базисный механизм стохастическим или нет.

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

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

Шкалы времени

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

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

Проблема различных шкал времени напоминают проблему интегрирования “жестких” систем ДУ или когда имеем дело с некорректной проблемой.

Пример не корректности представляет линейная система

X’’-25*x=0, x(0)=1, x’(0)=-5.

Теоретическое решение: X(t)=e^-5t.

Однако при решении этой задачи численными методами в вычисления выйдет дополнительный член X(t)=e^-5tс малым множителемe. Т.о. в действительности вычисляется X*(t)=e^-5t+ee^5t.

Если t (или e) достаточно мало, то всё в порядке; однако когда ошибка округления слишком велика (большоеe) или когда желательно найти решение на большом интервале t, то преобладающим в решении будет член x(t).

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

X₁’=x₁+2x₂,x₁(0)=0,

X₂=-10X₂,X₂(0)=1

Имеет решение:

X₁(t)=-2/11[e^-10t-e^-t],

X₂(t)=e^-10t.

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

Это явление “жёсткости” в системах, очевидно, оказывает влияние на динамическую сложность системы, так как точное предсказание поведения системы требует дополнительных затрат на вычисление.

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

Пример

Пусть имеется совокупность из nэлементов. Если они изолированы, не связаны между собой, то этиnэлементов не являются системой. Для изучения этой совокупности достаточно провести не более чемnисследований с каждым элементом. В общем случае в системе со взаимными связями между компонентами необходимо исследоватьn(n-1) связей. Если состояние каждой связи охарактеризовать в каждый момент времени наличием или отсутствует или отсутствует, то общее число состояний системы будут равно 2^n(n-1).

Например, если n=10, то число связейn(n-1)=90, число состояний 2⁹⁰»1,3*10²⁷.

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

Модели сложных систем управления (по Вавилову А.А)

В соответствии с определением, введенным А.А. Вавиловым, сложная система управления (ССУ) S^Sпредставляет собой множество взаимосвязанных и взаимодействующих между собой подсистем управленияS^m, выполняющих самостоятельные и общесистемные функции и цепи управления.

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

Цепи управления определяет необходимый закон изменения заданных переменных или некоторых характеристик подсистемы управления S^mв условиях ее функционально-целевого причинно следственного взаимодействия с внешней средой и другими подсистемами.

Принципиальных особенность модели ССУ – кроме причинно следственнойинформации модель ССУS^Sсодержит дополнительнуюфункционально-целевуюинформацию о подсистемеS^mи комплексахZ^p, интеграцией которых образована сложная система.

На рис. представлена модель комплекса Z^pССУ, образованного на моделяхM¹_FSF,M²_FSF, M³_FSFподсистемS¹,S²,S³посредством связей между ними.

Такая упорядоченная многоуровневая функционально-структурная интеграция элементов (звеньев) {Fi}. {Wi}, подсистемS^mи комплексовZ^pобеспечивает высокий уровень организации ССУ.

Нулевому (L=0) уровню интеграции ССУ соответствует причинно-следственная модель с максимальной топологической определенностью, например, обычный сигнальный графG^S.

Первому (L=1) уровню функционально-стрктурной интеграции соответствует выделение подсистем, которые обладают всеми системными свойствами с другими подсистемами обеспечивают коллективное поведение, направленное на достижение целей всей системы.

Второму (L=2) уровню соответствует интеграция некоторых подмножеств подсистем {S^m;m=1,2,…,M} и множества их взаимосвязей

{F^mn_rg;m,kÎ1,…,M;m!=k;r=1,…,n^k_f}

в комплексы: Z^p=<{S^p;m=1,…,M};{F^mn;m;kÎ1,…,M;m!=k}>

p=1,2,…, и т.д.

Необходимым условием образования комплекса L-ого уровня интеграции Z^p_Lявляется включение в него хотя бы одного комплекса (L-1)-го уровня интеграции.

Вычислительная сложность

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

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

Временная и пространственная сложности

Теория сложности вычислений возникла из потребности сравнивать быстродействие алгоритмов, чётко описывать их поведение (время исполнения и объём необходимой памяти) в зависимости от размера входа и выхода.

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

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

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

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

Примеры

* «пропылесосить ковер» требует время, линейно зависящее от его площади (Θ(A)), то есть на ковер, площадь которого больше в два раза, уйдет в два раза больше времени. Соответственно, при увеличении площади ковра в сто тысяч раз, объем работы увеличивается строго пропорционально в сто тысяч раз, и т. п.

* «найти имя в телефонной книге» требует всего лишь время, логарифмически зависящее от количества записей (O(log2(n))), так как открыв книгу примерно в середине, мы уменьшаем размер «оставшейся проблемы» вдвое (за счет сортировки имен по алфавиту). Таким образом, в книге, толщиной в 1000 страниц, любое имя находится не больше чем за N=log₂1000, примерно 10 раз (открываний книги). При увеличении объема страниц до ста тысяч, проблема решается заN=log₂100000, примерно 17 заходов. (См. Двоичный поиск.)

ОСНОВНАЯ ЛИТЕРАТУРА

[Клир] Клир Дж. Системология. Автоматизация решения системных задач. – М.: Радио и связь, 1990. – 544 с.

[Спицнадель] Спицнадель В. Н. Основы системного анализа: Учеб. пособие. — СПб.: «Изд. дом «Бизнесс-пресса», 2000 г. — 326 с.

[Сурмин] Сурмин Ю. П. Теория систем и системный анализ: Учеб. пособие. — К.: МАУП, 2003. — 368 с

[Красов]Красов А.А. Теория информационных процессов и систем.

http://www.studfiles.ru/dir/download/14036.html

[Агошкова]Е.Б. Агошкова, Б.В. Ахлибининский. Эволюция понятия системы. //Вопросы философии, 1998, № 7, с.170-178.

[Корнилов] Основы теории систем и системного анализа. Лекции. - Кривой Рог: ИДА, 1996. //http://victor-safronov.narod.ru/systems-analysis/lectures/kornilov.html

[Ерохина] Ерохина Е.А. Теория экономического развития: системно-синергетический подход // http://www.infoslon.com/library/details.php?id1=1&id2=22&f=10000120

9. Лекция: Экономические информационные системы: версия для печати и PDA  Информационную инфраструктуру любой организации можно представить в виде нескольких иерархических уровней, каждый из которых характеризуется степенью агрегированности информации и своей ролью в процессе управления. В частности, можно выделить такие укрупненные уровни, как уровень трансакционных систем, уровень систем бизнес-интеллекта и уровень аналитических приложений.

Иерархия информационных систем управления

Трансакционные системы

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

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

Системы бизнес-интеллекта

Понятие систем бизнес-интеллекта (Business Intelligence, BI) является довольно емким и объединяет различные средства анализа и обработки данных масштаба предприятия. Среди BI-систем можно выделить такие составляющие, как хранилища и витрины данных, инструменты оперативной аналитической обработки (OLAP-системы), средства обнаружения знаний, а также средства формирования запросов и построения отчетов.

Важную роль среди BI-систем играют хранилища данных (data ware-house, DW), обеспечивающие сбор, упорядочение и хранение больших объемов информации, полученной из разных источников. Один из авторитетных специалистов в этой области, У. Инмон, определяет хранилища данных как "предметно-ориентированные, интегрированные, стабильные, поддерживающие хронологию наборы данных, используемые для поддержки принятия управленческих решений" [39]. Ценность хранилищ данных заключается в том, что они представляют собой крупные базы данных масштаба предприятия, которые содержат определенную информацию и обеспечивают ее оперативное представление в виде, удобном для пользователя или для дальнейшей обработки другими аналитическими системами.

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

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

Еще одним элементом BI-платформы, который часто выделяют в отдельную категорию, являются средства обнаружения знаний (data mining). Один из ведущих экспертов в данной области, Г. Пиатецкий-Шапиро, определяет деятельность таких систем как процесс обнаружения в сырых данных ранее неизвестных, нетривиальных, практически полезных и доступных интерпретации знаний, необходимых для принятия решений в различных сферах человеческой деятельности [40]. В деятельности систем обнаружения знаний используются такие методы анализа данных, как фильтрация, деревья решений, ассоциативные правила, генетические алгоритмы, нейронные сети, статистический анализ.

Наконец, к числу BI-систем относятся средства формирования запросов и построения отчетов (query and reporting tools). Такие системы обеспечивают построение запросов к информационно-аналитическим системам в пользовательских терминах, с возможной интеграцией данных из разных источников, а также просмотр информации с возможностью ее детализации и агрегирования, построение отчетов и их печать.

Аналитические приложения

Аналитические приложения (analytic applications) кардинально отличаются от трансакционных систем, поскольку они ориентированы не на обработку отдельных операций, а на анализ агрегированной информации. Для того чтобы информационная система могла считаться аналитическим приложением, она должна удовлетворять следующим критериям [41]]:

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

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

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

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

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

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

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

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

9. Лекция: Системы управления ресурсами предприятия (ERP-системы):

Информационные системы, охватывающие управление всеми видами ресурсов предприятия (материальными, трудовыми, финансовыми), получили название ERP-систем (Enterprise Resource Planning). Именно такие системы позволяют объединить в единый управленческий контур функции текущего планирования и учета, а также соответствующие службы предприятия - маркетинг, продажи, производство, снабжение, учет, финансы [43].

Сущность ERP-систем

В соответствии с определением Американской ассоциации по управлению запасами и производством (American Inventory and Production Control Society, APICS) термин "ERP-система" может употребляться в двух значениях. Во-первых, это информационная система для идентификации и планирования всех ресурсов предприятия, которые необходимы для производства, закупки, отгрузки и учета в процессе выполнения клиентских заказов. Во-вторых (в более общем контексте), это методология эффективного планирования и управления ресурсами предприятия, которые необходимы для производства, закупки, отгрузки и учета при исполнении заказов клиентов в сферах производства, дистрибуции и оказания услуг.

Практически все ERP-системы построены по модульному принципу, что дает предприятию возможность выбора и внедрения лишь тех модулей, которые ему действительно необходимы. Модули разных систем могут отличаться как по названиям, так и по содержанию. Тем не менее, есть некоторый набор функций, который может считаться типовым для всех программных продуктов класса ERP. Рассмотрим основные функции ERP-систем, условно подразделив их на функции управления запасами и производством, функции учета и управления финансами и функции управления персоналом [44].

Управление запасами и производством

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

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

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

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

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

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

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

Планирование операций

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

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

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

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

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

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

Управление продажами

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

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

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

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

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

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

Управление запасами

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

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

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

Функции управления запасами ERP-систем, как правило, дополняются набором стандартных отчетов. К их числу относятся отчеты по складским операциям, отчеты о запасах по местам складирования, отчеты о транзитных запасах и другие.

Управление закупками

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

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

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

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

Управление производственными процессами

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

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

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

Сущность финансового и управленческого учета

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

Финансовый учет (financial accounting) ориентирован, прежде всего, на внешних пользователей экономической информации, он обязателен по закону и ведется в соответствии с официально утвержденными стандартами.Управленческий учет (management accounting) ориентирован, прежде всего, на внутренних пользователей экономической информации. Он не является обязательным, ведется по решению руководства предприятия, а принятые методы, подходы и формы управленческой отчетности определяются из соображений полезности для принятия управленческих решений.

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

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

Главная книга

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

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

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

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

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

Расчеты с дебиторами

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

Расчеты с кредиторами

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

Основные средства

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

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

Денежные средства

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

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

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

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

Расчеты с персоналом

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

Налоговый учет

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

Бухгалтерская отчетность

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

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

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

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

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

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

Управление персоналом

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

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

Ограниченность ERP-систем

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

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

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

В результате одного из исследований, посвященных перечисленным проблемам, были выделены несколько причин ограниченности ERP как систем управления [41].

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

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

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

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

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

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

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

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

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

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

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

11. Лекция: Системы бизнес-интеллекта (BI-системы): версия для печати и PDA  Типичная ситуация, характерная для практически любой достаточно крупной организации, - наличие множества систем автоматизации для решения разных задач, разрозненное хранение данных и, как следствие, - отсутствие единого взгляда на управленческую информацию.

Сущность систем бизнес-интеллекта

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

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

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

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

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

Функциональность

Напомним определение У. Инмона: хранилища данных - это "предметно-ориентированные, интегрированные, стабильные, поддерживающие хронологию наборы данных, используемые для поддержки принятия управленческих решений"[39].

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

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

В качестве основы хранилища данных, как правило, используется реляционная модель хранения данных, что существенно облегчает дальнейшее развитие такого хранилища. Впрочем, существует и другой путь - применение оптимизированных структур, например, многомерных (по этому пути пошли разработчики компании SAP в своем продукте SAP BW). Однако, по мнению ряда исследователей (например, У. Инмона [46]), такой подход имеет целый ряд недостатков, не являясь достаточно гибким и универсальным. В самом деле, если данные из хранилища поступают лишь в ограниченное количество витрин данных и аналитических приложений, то от хранилища вовсе не требуется поддерживать специализированные запросы. В этом отношении использование реляционных баз данных экономичнее (без потери функциональности), а следовательно, - предпочтительнее.

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

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

OLAP-системы

Функциональность

Идея обработки многомерных данных восходит к 1962 году, когда К. Айверсон опубликовал свою работу "Язык программирования" (A Programming Language, APL) [47]. APL - это математически определенный язык с многомерными переменными и изящными, но довольно абстрактными операторами. В 70-е и 80-е годы он активно использовался во многих деловых приложениях, функционально схожих с современными OLAP-системами.

В 1993 году вышла в свет статья Е. Ф. Кодда, в которой впервые было дано формальное определение OLAP-технологии [48]. Эта работа получила большой резонанс и привлекла внимание к возможностям многомерного анализа. В статье были описаны двенадцать правил OLAP, к которым чуть позже (в 1995 году) были добавлены еще несколько. Все эти правила были разделены на четыре группы и названы "характеристиками" (features).

К правилам OLAP относятся:

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

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

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

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

Универсальным критерием определения OLAP как аналитического инструмента является тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации). Рассмотрим детально каждую из составляющих этой аббревиатуры [49].

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

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

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

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

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

Обсуждая тему OLAP, следует упомянуть и о разновидностях многомерного хранения данных. Дело в том, что информационные массивы, логически упорядоченные по аналитическим направлениям и, таким образом, являющиеся многомерными с точки зрения конечных пользователей, не обязательно являются многомерными по их технологической реализации. Как правило, выделяют три разновидности хранения данных [45]:

• многомерный OLAP (multidimensional OLAP, MOLAP) - "OLAP в чистом виде", т.е. технология, основанная на хранении данных под управлением специализированных многомерных СУБД;

• реляционный OLAP (relational OLAP, ROLAP) - технология, основанная на хранении многомерной информации в реляционных базах данных, на основе одной или нескольких схем типа "звезда" или "снежинка";

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

Выбор способа хранения зависит от нескольких факторов, таких как объем и структура данных, скорость выполнения запросов, частота обновления OLAP-кубов.

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

Функциональность

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

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

10. Лекция: Аналитические приложения: версия для печати и PDA Подробно рассмотрен ряд примеров аналитических приложений.

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

В качестве примеров аналитических приложений, расположенных на вершине "аналитической пирамиды" рассмотрим:

• системы, реализующие методологию сбалансированных систем показателей (BSC-системы);

• системы корпоративного планирования и бюджетирования;

• системы формирования и анализа консолидированной финансовой отчетности;

• BI-приложения и другие аналитические приложения.

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

Системы управления эффективностью бизнеса (BPM-системы)

Сущность концепции BPM

90-е годы прошлого века ознаменовались интенсивным развитием аналитических систем, включая BI-системы и аналитические приложения. На определенном этапе была признана необходимость их интеграции - и методологической (функциональной), и технологической. Так появилось новое направление, получившее название Business Performance Management (BPM), что на русский язык обычно переводится как "управление эффективностью бизнеса" (хотя такой перевод представляется не вполне корректным). В общих чертах, BPM - это целостный, процессно-ориентированный подход к принятию управленческих решений, направленный на улучшение способности компании оценивать свое состояние и управлять эффективностью своей деятельности на всех уровнях, путем объединения собственников, менеджеров, персонала и внешних контрагентов в рамках общей интегрированной среды управления [50].

Приведем определение, разработанное группой по стандартизации BPM.

Business Performance Management (BPM) - это методология, направленная на оптимизацию реализации стратегии и состоящая из набора интегрированных циклических аналитических процессов, которые поддерживаются соответствующими технологиями и имеют отношение как к финансовой, так и к операционной информации. BPM позволяет предприятию определять, измерять и управлять эффективностью своей деятельности, направленной на достижение стратегических целей. Ключевые финансовые и операционные процессы BPM включают планирование, консолидацию и отчетность, анализ ключевых показателей эффективности и их распространение в рамках организации [51].

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

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

• управление эффективностью бизнеса (Business Performance Management, BPM);

• управление эффективностью деятельности предприятия (Enterprise Performance Management, EPM);

• управление эффективностью деятельности корпорации (Corporate Performance Management, CPM);

• стратегическое управление предприятием (Strategic Enterprise Management, SEM).

Также нельзя не отметить досадное совпадение: аббревиатура BPM имеет и другую расшифровку - Business Process Management (управление бизнес-процессами). Этот термин используется, в частности, компанией IDS Scheer - одним из мировых лидеров в области управления бизнес-процессами и разработки соответствующего программного обеспечения.

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

Функциональность BPM-систем

В соответствии с документом, разработанным Группой по стандартизации BPM, в качестве основных процессов, охватываемых BPM-системами, можно выделить следующие [51].

• формализация стратегии (strategize);

• планирование (plan);

• мониторинг и анализ (monitor and analyze);

• корректирующие воздействия (take corrective actions).

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

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

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

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

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

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

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

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

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

Управление по ключевым показателям

Balanced Scorecard и другие методики управления по ключевым показателям

Развитие теории управления привело к появлению методологии сбалансированных систем показателей (Balanced Scorecard, BSC), которую ее создатели, Р. Каплан и Д. Нортон, определяют как инструмент, позволяющий трансформировать миссию и стратегию организации в исчерпывающий набор показателей эффективности, которые служат основой для системы стратегического управления и контроля [52]. Именно эта теория на сегодняшний день получила всеобщее признание и, несмотря на наличие целого ряда аналогичных методик, все чаще воспринимается как "стандарт де-факто".

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

Дальнейшее развитие методологии Balanced Scorecard характеризуется переходом от простой оценки показателей эффективности к управлению стратегическим развитием компании. Для этого Капланом и Нортоном была разработана карта стратегии (strategy map), которая дает визуализированное представление стратегии в виде стратегических целей, показателей и причинно-следственных связей.

В карте стратегии Каплана и Нортона выделяются четыре аспекта (перспективы):

• финансы (финансовое положение и финансовые результаты деятельности);

• клиенты (то, как предприятие выглядит с точки зрения своих клиентов);

• внутренние процессы (ключевые процессы, в значительной мере определяющие эффективность деятельности компании);

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

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

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

Наконец, необходимым элементом Balanced Scorecard являются стратегические инициативы (strategic initiatives), представляющие собой конкретные действия и/или программы действий по реализации стратегии и достижению стратегических целей. По сути дела, стратегические инициативы - это перечень усилий, которые следует предпринять для достижения стратегического результата. Иначе говоря, стратегические инициативы представляют собой не что иное, как тактические мероприятия, позволяющие реализовать стратегию.

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

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

Balanced Scorecard по праву можно назвать наиболее популярной среди методик стратегического управления. Но это не означает отсутствия других методов и подходов, многие из которых также получили достаточно широкое распространение и признание. Примерами таких разработок могут служить методика управления стоимостью компании (Value Based Management, VBM), а также методика tableau de bord, разработанная и получившая распространение во Франции.

Функциональность BSC-систем

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

В конце 90-х годов при участии Р. Каплана и Д. Нортона были разработаны стандарты функциональности BSC-систем, которые содержали минимальные требования, необходимые для формирования сбалансированных систем показателей [54]. Документация по функциональным стандартам BSC-систем включает четыре раздела:

• построение системы;

• стратегическое образование и коммуникации;

• практическая реализация;

• обратная связь и обучение.

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

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

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

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

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

Корпоративное планирование и бюджетирование

Основы корпоративного планирования и бюджетирования

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

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

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

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

Рис. 12.1.  Типовая структура бюджета предприятия

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

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

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

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

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

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

Функции формирования и анализа бюджетов (как функциональных, так и основных), реализуются при помощи специализированных информационных систем планирования и бюджетирования. Рассмотрим основные функции таких систем [50], [55], [53].

Многомерное хранение информации

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

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

План счетов

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

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

Календарь планирования

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

Мультивалютность

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

Бизнес-правила

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

Описание финансовой структуры предприятия

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

Описание пользователей

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

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

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

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

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

Сценарии и версии

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

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

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

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

Управление процессом планирования

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

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

Формирование и анализ консолидированной финансовой отчетности

Сущность консолидированной финансовой отчетности

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

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

Чтобы консолидированная отчетность разных групп компаний обладала свойством сопоставимости (что необходимо для анализа), она нуждается в стандартизации. Поэтому в системе Международных стандартов финансовой отчетности (МСФО) правилам формирования консолидированной отчетности уделяется особое внимание [57].

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

В соответствии с МСФО, выделяются три метода консолидации: полная консолидация, пропорциональная консолидация и метод долевого участия.

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

Пропорциональная консолидация (proportional consolidation) отличается от полной тем, что консолидации подлежат лишь те чистые активы, которыми инвестор реально владеет, при этом доля меньшинства в балансе не отражается. Метод применяется для консолидации отчетности по совместной деятельности.

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

Информационные системы консолидации финансовой отчетности

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

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

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

Рассмотрим подробнее основные функции специализированных систем формирования и анализа консолидированной финансовой отчетности [50] , [56] , [56].

Аналитические направления

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

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

Сбор и структурирование исходной информации

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

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

Мультивалютность

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

Бизнес-правила

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

Журналы

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

Организация процесса консолидации

Функции управления процессом консолидации предназначены для контроля обработки информации, в случае если процедура консолидации выполняется централизованно. Элементарный блок процесса представляет собой комбинацию сценария, года, периода, предприятия и вида значений.

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

Процедуры консолидации

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

Отчеты

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

BI-приложения

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

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

Системы финансового моделирования

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

Система Oracle Hyperion Profitability and Cost Management позволяет решать ряд задач, так или иначе связанных с анализом и управлением затратами и доходами организации. К числу таких задач, в частности, относятся определение прибыльности того или иного сегмента бизнеса или принятие решений в области ценообразования.

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

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

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

Системы имитационного моделирования

Определения и термины

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

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

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

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

Имитационный процесс - проведение расчетного эксперимента с помощью имитационной модели реального объекта.

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

Имитационные модели разделяют на дискретные и непрерывные [59].

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

Непрерывные модели предполагают развитие имитационной ситуации в модели как в непрерывной (аналоговой) среде.

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

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

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

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

Имитационные модели также подразделяются на статические и динамические.

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

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

Здесь возможны два варианта развития: динамика изменения схемы имитационного эксперимента известна и динамика изменения модели является целью имитационного исследования.

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

Области применения имитационных моделей

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

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

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

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

К недостаткам систем имитационного моделирования можно отнести следующие:

• сложность описания;

• сложность проведения экспериментов;

• слабость средств моделирования конфликтов за общие ресурсы;

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

Существующие имитационные модели можно условно разделить на три группы.

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

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

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

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

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

• ряд авторов считает, что составление и решение описывающих процесс аналитических уравнений или исследование характеристик системы управления методом частотных характеристик является моделированием математическим, но не имитационным и не статистическим. Соответственно, входящий в состав MatLab'a Simulink никакого отношения к двум последним видам моделирования не имеет [60];

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

• вычисление многомерного интеграла методом Монте-Карло - это статистическое, но не имитационное моделирование;

• моделирование задач теории очередей на GPSS и других языках является одновременно имитационным и статистическим.

За рубежом появилось огромное количество современных систем имитационного моделирования (симуляторы). Коммерческие симуляторы специализированы по отраслям промышленности: eMPlant (машиностроение), DELMIA(судостроение), NETRAC (телекоммуникации и связь). Но среди них имеются и пакеты общего применения, прежде всего - специализированные языки имитационного моделирования GPSS, Simula, и программы, использующие ту же транзакт-парадигму, что и GPSS: Arena, Extend, ProMоdel, SimProcess, LabView, Crystal Ball 2000 [61].

Решение задач с преобладанием логистических аспектов может быть получено с помощью таких симуляторов, как AutoMod, AnyLogic, Proсess Model, QUEST, SIMFACTORY, Taylor ED, WITNESS, объектно-ориентированного моделирования информационных процессов Natural Engineering Workbench, имитационного моделирования бизнес-процессов ReThink [62].

Несколько особняком стоит система BPsim [63] - она опирается на аппарат динамических экспертных систем. В ней определены следующие классы объектов: операции, ресурсы, средства, процессы, источники и приемники ресурсов, перекрестки, параметры. Отдельно выделены информационные типы ресурсов: сообщения и заявки на выполнение операций. Параметры процесса задаются функцией от характеристик объектов и классифицируются на производные (свертка различного типа характеристик) и консолидированные (свертка одноименных характеристик операций процесса). Описание причинно-следственных связей задается специальными объектами.

Имитационное моделирование все шире внедряется в практику исследования производственных (в самом широком смысле слова) процессов, стратегического и оперативного управления ими. В настоящее время встал вопрос о сплошном применении цифровых моделей (Digital Factory) [64] в процессе проектирования и эксплуатации производственных систем. Люди, участвующие в такой деятельности, получают возможность наблюдать статические объекты, как правило, в виде трехмерных изображений (виртуальная реальность - VR). Наличие имитационной модели и обоснование с ее помощью выбранного варианта в западных странах являются обязательными в комплекте документов, подаваемых на рассмотрение для проектирования или модернизации нового производства либо технологического процесса.

Имитационные модели используются и для обучения персонала. Эта концепция называется e-manufacturing. Убежденными сторонниками ее выступают, в частности, ведущие автомобильные компании Daimler-Chrysler, Mercedes-Benz, BMW, Audi, Toyota. Этот подход применяется и на сборке аэробусов А-380 в Гамбурге [64].

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

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

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

• модель платежного баланса России предназначена для моделирования внешнеэкономической деятельности России;

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

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

Такой комплекс моделей дает возможность получать адекватное представление о будущем сбалансированном состоянии экономики государства.

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

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

• "Рынок труда" - моделируется межотраслевое движение рабочей силы в зависимости от потребности, уровня скрытой и структурной безработицы, размера оплаты труда;

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

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

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

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

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

• "Планирование производственных показателей" - рассчитывается ввод производственных мощностей в зависимости от инвестиций на плановый период, с учетом фондоотдачи определяются плановые показатели объемов производства готовой продукции и транспортных услуг;

• "Планирование экономических показателей" - рассчитываются плановые объемы реализации в зависимости от спроса, изменения запасов готовой продукции, планируются выручка от реализации (в том числе на экспорт в зависимости от курсов валют) и производственные затраты с учетом индексов роста, рассчитываются себестоимость производства и реализации, прибыль (убытки), планируются начисленные налоги при заданных ставках;

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

• "Планирование активов" - рассчитывается состояние внеоборотных активов, запасов, денежных средств, дебиторской задолженности на конец планового периода;

• "Планирование пассивов" - рассчитывается состояние капитала и резервов, заемных средств, кредиторской задолженности на конец планового периода.

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

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

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

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

• постановка задачи моделирования;

• представление результатов моделирования;

• интерпретация результатов моделирования;

• выдача рекомендаций по оптимизации режима работы реальной системы.

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

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

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

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

Этап 2: выбор средств описания реального объекта, методов проектирования, среды программирования.

Этап 3: разработка и создание программной реализации имитационного расчета для одного шага имитации. Определение функций изменения имитационной модели на шаге. Для динамических моделей разрабатывается алгоритм изменения расчетной модели при переходе от одного шага имитации к другому.

Этап 4: определение среды и условия проведения имитационного эксперимента. Разрабатывается программа управления имитационным процессом и выдачи промежуточных и окончательных результатов эксперимента по заданному сценарию.

Этап 5: анализ вариантов сценариев, принятие решения о путях совершенствования модели, имитационного процесса и выбор новых (или уточнение старых) путей исследования.

Компьютерная реализация имитационной модели

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

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

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

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

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

Система Arena

Одним из наиболее эффективных инструментов имитационного моделирования является система Arena фирмы System Modeling Corporation.

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

Имитационная модель Arena включает следующие основные элементы: источники и стоки (Create и Dispose), процессы (Process) и очереди (Queue).

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

Сток представляет собой устройство для приема информации или объектов.

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

Очередь - это место хранения данных, где они ожидают обработки. Время обработки объектов (производительность) в разных процессах может быть разным. В результате перед некоторыми процессами могут накапливаться объекты, ожидающие своей очереди. Часто целью имитационного моделирования является минимизация количества объектов в очередях. Тип очереди в имитационной модели может быть конкретизирован. Очередь работает по принципу [прим. корр.: здесь название принципа идет сразу за называемым словом, двоеточие не нужно] "первым пришел - первым обслужился" (FIFO: first-in - first-out).

Стек - пришедшие последними к стоку объекты первыми отправляются на дальнейшую обработку (LIFO: last-in - first-out). Альтернативой стеку может быть последовательная обработка в очереди.

Могут быть заданы и более сложные алгоритмы обработки очереди.

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

Другим средством построения компьютерных имитационных моделей на рынке программных продуктов является система MATLAB в сочетании с пакетом визуального моделирования Simulink компании MathWorks [65].

Возможности пакета Simulink:

• визуальное представление логики функционирования компонент сложной системы и их взаимодействия;

• работа во внешнем режиме при использовании раздела PCTagert (универсальных PCI-контроллеров);

• управление и работа с внешними системами в режиме реального времени.

На рынке отечественных разработчиков существует универсальный пакет имитационного моделирования AnyLogic 4.1 российской компании XJ Technologies [66]. В AnyLogic представление модели является визуальным и иерархическим. Простой графический язык моделирования (основанный на UML-RT) оперирует понятиями объектов и связей между ними - дискретными (отправка сообщений произвольной структуры) и непрерывными (отслеживание показателей). Для описания сложного поведения пользователь может применять графические диаграммы переходов и состояний. Такие диаграммы позволяют визуально проектировать сложные бизнес-процессы и многошаговые действия с альтернативами.

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

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

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

• ядро моделирования - планировщик событий, механизм обмена и распределения сообщений в соответствии с графическими свя-зями;

• средства представления результатов моделирования - графики, сбор статистики, анимация;

• средства инспекции модели - отображение всех имеющихся в системе объектов, информации о состояниях объектов, параметров и переменных;

• численные методы решения систем дифференциальных уравнений;

• классы распределений случайных величин;

• библиотеки блоков, аналогичных MATLAB/ Simulink.

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

Во всех случаях создавать имитационные модели без предварительного анализа бизнес-процессов не всегда представляется возможным. Действительно, не поняв сути бизнес-процессов предприятия, бессмысленно пытаться оптимизировать конкретные технологические процессы. Поэтому функциональные и имитационные модели не заменяют, а дополняют друг друга, при этом они могут быть тесно взаимосвязаны. Имитационная модель дает больше информации для анализа системы. В свою очередь, результаты такого анализа могут стать причиной модификации модели процессов. Наиболее целесообразно сначала создать функциональную модель, а затем на ее основе построить модель имитационную. Для поддержки такой технологии инструментальное средство функционального моделирования BPwin 4.0 имеет возможность преобразования диаграмм IDEF3 в имитационную модель Arena (версии 3.6 и выше). Для преобразования диаграммы IDEF3 в модель Arena необходимо, чтобы BPwin 4.0 и Arena были запущены одновременно. В BPwin 4.0 следует открыть диаграмму IDEF3, а затем выбрать меню File/Export/Arena. Далее экспорт производится автоматически.

Поскольку имитационная модель имеет гораздо больше параметров, чем диаграмма IDEF3, в BPwin 4.0 существует возможность задать эти параметры с помощью свойств, определяемых пользователем (UDP, User Defined Properties). В поставку BPwin 4.0 входят примеры моделей с предварительно внесенными UDP для экспорта в Arena (Program Files/Computer Associates/BPwin 4.0/Samples/Arena/) и модель ArenaBEUDPs.bp1, в которой определены все необходимые для экспорта UDP и которую можно использовать в качестве шаблона для создания новых моделей.

Рассмотрим основные элементы интерфейса программы ARENA [67].

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

Рис. 12.2.  Сведения о программе

Это закономерно, поскольку обе программы выполнены с соблюдением стандартов MS Windows. Более того, если рисование в Visio представляется разработчику более легким делом, чем аналогичная работа в ARENA, то он может изобразить логику процесса в Visio, после чего перейти в Arena и импортировать созданную диаграмму. Панели, расположенные в верхней части окна на рисунке, достаточно традиционны. Заметим лишь, что на второй линии пиктографических изображений расположены инструменты для изображения линий, связывающих блоки на диаграммах.

Рассмотрим панель инструментов, расположенную вертикально в левой части окна на рис.12.3. Она называется Project Bar и размещается на экране путем установки галочки в соответствующем пункте меню группы View.

Рис. 12.3.  Открытие панели инструментов

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

Однако каждый блок имеет специфику, которая отражена не только в его названии, но и форме. Эти модули называются Flowchart modules. Как ясно из названия, речь идет о потоках - в первую очередь, заявок и обслуживания. Модули второй группы ориентированы на детальное описание параметров (данных) Flowchart modules. Они так и называются - Data modules.

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

Программа ARENA имеет большое число Flowchart modules и Data modules.

Они объединены в кластеры и могут загружаться в Project Bar из группы File, как показано на рис.12.4, рис.12.5, рис.12.6.

Рис. 12.4.  Открытие панели шаблонов

Рассмотрим более детально процесс загрузки новых кластеров в программу

Первый этап. Для загрузки нового кластера необходимо открыть меню File/ Template Panel/Attach. После этого появится диалоговое окно, в котором необходимо выбрать соответствующий кластер (набор инструментов).

Кластеры можно как подключать, так и отключать. Для выгрузки кластеров необходимо выбрать пункт File/ Template Panel/Detach.

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

Второй этап: выбор необходимого кластера в диалоговом окне Attach Template Panel. Программа ARENA обладает широким набором кластеров для более удобной работы. Как можно увидеть на рис.12.5, в программе представлены около 15 шаблонов. Используя эти наборы, можно значительным образом увеличить скорость и удобство работы.

Изначально в программе открыт кластер Basic Process.

Рис. 12.5.  Выбор шаблона

Все представленные в кластере элементы (Flowchart modules и Data modules) можно применять для создания диаграмм.

Рис. 12.6.  Элементы для создания диаграмм

Третий этап. Загрузка завершена. Как видно на рис.12.6, в меню инструментов добавилась новая вкладка с названием "Advanced Process".

Это напоминает загрузку тематических панелей в Visio. Однако ARENA - не "рисовалка", а мощное средство имитационного моделирования.

Программа ARENA позволяет создавать диаграммы, отражающие функционирование того или иного процесса. Процесс создания диаграмм во многом схож с таковым в MS Visio. Здесь также используется технология Drag and Drop, однако для некоторых процесс "рисования" в MS Visio будет более удобным и предпочтительным.

На рис.12.7 изображена диаграмма основной деятельности системы массового обслуживания с ожиданием на примере системы обслуживания клиентов с применением офисной АТС.

Рис. 12.7.  Диаграмма основной деятельности системы массового обслуживания с ожиданием

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

Данный пример иллюстрирует только системы массового обслуживания с очередью. Существуют и другие системы, например, системы массового обслуживания с отказом, когда клиент не желает ждать. Также выделяют различные СМО в зависимости от того, поступают заявки извне или от элементов самой системы. Все эти модели можно создать и "проиграть" с применением программы ARENA.

Рис. 12.8.  Результаты имитационного моделирования

Экспертные системы

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

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

Экспертная система является инструментом, усиливающим интеллектуальные способности эксперта, и может выполнять следующие роли:

• консультанта для неопытных или непрофессиональных пользователей;

• ассистента в связи с необходимостью анализа экспертом различных вариантов принятия решений;

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

Архитектура экспертной системы

Экспертная система (рис.12.9) включает в себя два основных компонента: базу знаний (хранилище единиц знаний) и программный инструментарий доступа и обработки знаний. Программный инструментарий состоит из механизмов вывода заключений, приобретения знаний, объяснения получаемых результатов и интеллектуального интерфейса [68].

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

Рис. 12.9.  Архитектура экспертной системы

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

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

Если < условие >

То <заключение> CF (фактор определенности) <значение>

В качестве факторов определенности (CF), как правило, выступают либо условные вероятности байесовского подхода (от 0 до 1), либо коэффициенты уверенности нечеткой логики (от 0 до 100).

Примеры правил имеют следующий вид.

Правило 1: если Коэффициент рентабельности > 0.2, то Рентабельность = "удовлетворительна" CF 100.

Правило 2: если Задолженность = "нет" и Рентабельность = "удовлетворительна", то Финансовое состояние = "удовлетворительно" CF 80.

Правило 3: если Финансовое состояние = "удовлетворительно" и Репутация = "удовлетворительна", то Надежность предприятия = "удовлетворительна" CF 90.

Объекты представляют собой совокупность атрибутов, описывающих свойства и отношения с другими объектами. В отличие от записей баз данных, каждый объект имеет уникальное имя. Часть атрибутов отражают типизированные отношения, такие как "род - вид" (super-class - sub-class), "целое - часть" и др. Вместо конкретных значений атрибутов объектов могут задаваться значения по умолчанию, присущие целым классам объектов, или присоединенные процедуры (process).

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

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

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

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

Рис. 12.10.  Прямая цепочка рассуждений

Рис. 12.11.  Обратная цепочка рассуждений

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

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

Объяснительные способности ЭС определяются возможностью механизма вывода запоминать путь решения задачи. Тогда на вопросы пользователя "Как?" и "Почему?" получено решение или запрошены те или иные данные, и система всегда может выдать цепочку рассуждений до требуемой контрольной точки, сопровождая выдачу объяснения заранее подготовленными комментариями. В случае отсутствия решения задач объяснение должно выдаваться пользователю автоматически.

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

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

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

Классы экспертных систем

По степени сложности решаемых задач экспертные системы можно классифицировать следующим образом [71].

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

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

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

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

В соответствии с перечисленными признаками классификации выделяются следующие основные классы экспертных систем (табл. 12.1.).

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

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

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

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

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

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

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

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

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

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

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

Для синтезирующих динамических экспертных систем наиболее применимы следующие проблемные области.

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

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

3. Диспетчеризация - распределение работ во времени, составление расписаний, например, планирование графика освоения капиталовложений.

4. Планирование - выбор последовательности действий пользователей по достижению поставленной цели, например, планирование процессов поставки продукции.

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

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

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

Для многоагентных систем характерны следующие особенности:

• проведение альтернативных рассуждений на основе использования различных источников знаний с механизмом устранения про-тиворечий;

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

• применение множества стратегий работы механизма вывода заключений в зависимости от типа решаемой проблемы;

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

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

Технология создания экспертных систем

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

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

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

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

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

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

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

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

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

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

Рис. 12.12.  Этапы проектирования экспертной системы

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

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

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

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

Описание приемов извлечения знаний инженерами знаний представлено в таблице 12.2.

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

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

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

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

Таблица 12.2. Приемы извлечения знаний
Приемы	Описание
1. Наблюдение	Инженер наблюдает, не вмешиваясь, за тем, как эксперт решает реальную задачу
2. Обсуждение задачи	Инженер на представительном множестве задач неформально обсуждает с экспертом данные, знания и процедуры решения
3. Описание задачи	Эксперт описывает решение задач для типичных запросов
4. Анализ решения	Эксперт комментирует получаемые результаты решения задачи, детализируя ход рассуждений
5. Проверка системы	Эксперт предлагает инженеру перечень задач для решения (от простых до сложных), которые решаются разработанной системой
6. Исследование системы	Эксперт исследует и критикует структуру базы знаний и работу механизма вывода
7. Оценка системы	Инженер предлагает новым экспертам оценить решения разработанной системы

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

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

• обучение и консультация неопытных пользователей;

• распространение и использование уникального опыта экспертов;

• автоматизация работы экспертов по принятию решений;

• оптимизация решения проблем, выдвижение и проверка гипотез.

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

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

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

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

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

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

После предварительного определения контуров разрабатываемой экспертной системы инженеры по знаниям совместно с экспертами определяют:

• класс решаемых задач (прогнозирование, планирование, проектирование, мониторинг, управление);

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

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

• цели решаемых задач;

• подцели (разбиение задачи на подзадачи, для каждой из которых определяется своя цель);

• исходные данные (совокупность используемых факторов);

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

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

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

Хорошая концептуальная модель может только уточняться (детализироваться или упрощаться), но не перестраиваться.

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

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

• функциональная модель отражает действия и преобразования над объектами;

• поведенческая модель рассматривает взаимодействия объектов во временном аспекте.

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

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

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

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

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

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

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

Рассмотрим применение аппарата нечеткой логики на примере оценки надежности поставщика, в котором кроме фактора финансового состояния учитывается и фактор формы собственности (рис.12.13).

Рис. 12.13.  Применение нечеткой логики

Пусть государственное предприятие не имеет задолженности с уверенностью 60% и предполагается, что его рентабельность удовлетворительна с уверенностью 80%. Фрагмент множества правил имеет следующий вид.

Правило 1: если Задолженность = "нет" и Рентабельность = "удовлетворительна", то Финансовое состояние = "удовлетвори-тельно" cf 100.

Правило 2: если Финансовое состояние = "удовлетворительно", то Надежность = "есть" cf 90.

Правило 3: если Предприятие = "государственное", то Надежность = "есть" cf 50.

Результат выполнения первого правила:

Результат выполнения второго правила:

Результат выполнения третьего правила:

Для динамических моделей важны:

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

• обмен данными между различными источниками знаний для достижения нескольких целей,

• изменение стратегий вывода с выдвижения гипотез (прямая аргументация) к их проверке (обратная аргументация).

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

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

В программном средстве GURU подобное правило будет записано следующим образом:

IF: KNOWN ("Поставщик") = true THEN: CONSULT FIN_AN

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

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

Рекомендации по выбору экспертной системы

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

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

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

Использование языков представления знаний, таких как язык логического программирования PROLOG, язык функционального программирования LISP, язык объектно-ориентированного программирования SmallTalk, язык продукционных правил ОPS5 и другие, повышает гибкость разрабатываемой системы и одновременно увеличивает трудоемкость разработки.

Скелетные оболочки. Наиболее распространенными инструментальными средствами для создания экспертных систем являются генераторы или интегрированные среды разработки, например, G2 (фирма Gensym, дистрибьютор фирмаArgusSoft), ART-Enterprise (фирма Inference, дистрибьютор фирма "Метатехнология"), GURU (фирма MDBS, дистрибьютор фирма "ЦПС", Тверь).

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

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

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

Бесспорным лидером в разработке экспертных систем реального времени является фирма Gensym с инструментальным средством G2 (дистрибьютор в России - фирма ArgusSoft), имеющая внедрения в таких компаниях, как IBM,NASA, General Electric, Nissan и др.

На базе G2, в свою очередь, созданы такие проблемно-ориентированные комплексы, как GDA для решения задач диагностики, разработки, ReThink для моделирования бизнес-процессов (бизнес-реинжиниринга), NeurOnline для поддержки нейронной сети, IPS для решения задач динамического планирования, FaultExpert для управления телекоммуникациями и др.

Например, G2 (фирма Gensym, дистрибьютор фирма ArgusSoft), ART-Enterprise (фирма Inference, дистрибьютор фирма "Метатехноло-гия"), GURU (фирма MDBS, дистрибьютор фирма "ЦПС", Тверь), которые позволяют настраивать программные средства на особенности проблемных областей, при необходимости предоставляют возможность программировать на встроенных языках и осуществлять эффективный экспорт/импорт данных с другими инструментальными средствами.

Отечественные экспертные системы. Среди отечественных разработок следует отметить экспертную оболочку ЭКО (ArgusSoft) и программный комплекс SIMER-MIRAGE (Исследовательский центр искусственного интеллекта ИПС РАН), который предоставляет инструментальные средства как автоматизации разработки, так и поддержки экспертных систем.

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

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

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

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

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

Таблица 12.3. Рекомендации по выбору инструментальных средств
Классы решаемых задач	Программные инструментальные средства
Название	ЭКО	GURU	Nexpert Object	LEVEL	ART Enterprise	G2
Интерпретация	3	1	1	1	2	3
Диагностика	1	2	2	2	3	2
Прогнозирование	2	3	4	3	4	3
Проектирование	-	-	3	5	1	5
Планирование			5	4	5	1

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

• наличие экспертов, компетентных в избранном круге вопросов, которые согласны сотрудничать при создании ЭС;

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

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

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

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

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

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

Определение систем поддержки принятия решений

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

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

Выделим специфические особенности СППР:

• позволяют ликвидировать разрыв между аналитиками и лицами, принимающими решения, поскольку их конечными пользовате-лями являются именно специалисты, принимающие решения, а не технические специалисты;

• используют экономико-математические методы и модели для обоснования альтернатив (вариантов управленческих решений);

• содержат базу данных;

• отображают информацию в формате и терминологии, которые привычны ЛПР;

• выборочно предоставляют информацию и избегают избыточности информации.

Характеристика различных систем поддержки принятия решений

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

Таблица 12.4. Сводная таблица систем поддержки принятия решений
НаименованиеСППР	Официальный сайт системы	Характеристика
Экспертнаясистема Поддержки принятия Решений(ЭСППР)	http://82.179.249.12/edss/	Система ориентирована на автоматизацию процедуры анализа проблемных ситуаций и выбора эффективных решений. Относится к классу информационных систем, сочетающих преимущества экспертных систем и систем поддержки принятия решений
Expert Choice	http://www.expertchoice.com	Коммерческий программный продукт, разработанный на основе метода анализа иерархий для поддержки принятия решений различным организациям. Система имеет три варианта поставки: Comparion Core™, Expert Choice 11.5™ и Expert Choice Inside
Super Decisions	http://www.superdecisions.com	Программный продукт, разработанный на основе метода аналитических сетей (Analytic Network Process)
Decision Lens (DecisionLens Web)	http://www.decisionlens.com	Коммерческий программный продукт для поддержки принятия решений организациями, обладающий следующими методологи-ческими особенностями: - теоретические основы системы - методы анализа иерархий и аналитических сетей; - наличие веб-интерфейса; - возможность групповой работы
ImaginatikIdea Central	http://www.imaginatik.com	Коммерческая система, являющаяся веб-приложением для обработки мнений экспертов
UTA PLUS	http://www.lamsade.dauphine.fr/enlish/software.html	Реализует метод UTA, который может быть использован для решения задач многокритериального анализа. Программа имеет на-глядный графический интерфейс
ELECTRE IS	http://www.lamsade.dauphine.fr/enlish/software.html	Система, основанная на многокритериальном методе из семейства ELECTRE, который позволяет использовать псевдокритерии и пороговые значения при принятии решений. В процессе вычислений система строит граф. Искомый набор альтернатив - это ядро этого графа
ELECTRE III-IV	http://www.lamsade.dauphine.fr/english/software.html	Система, реализующая метод из семейства ELECTRE для критериев, которые не имеют оценок относительной значимости. Ме-тод, лежащий в основе системы, позволяет ранжировать альтернативы
ELECTRE TRI	http://www.lamsade.dauphine.fr/enlish/software.html	Система, реализующая метод из семейства ELECTRE для решения проблем, которые требуют сегментации. Процесс сегментации основан на оценке внутренней стоимости альтернатив. В системе существует модуль, способный самообучаться на тестовых ситуаци-ях, определяя параметры модели. ELECTRE TRI успешно применяется в задачах с большим количеством альтернатив
IRIS	http://www4.fe.uc.pt/lmcdias/iris.htm	Система реализует задачу сортировки альтернатив в многокритериальных задачах принятия решений. Допускает задание порого-вых ограничений пользователем для критериев (признаков). Способна оценивать точность вычислений. Выводит результат вычис-лений в виде отчета
Император 3.1	http://www.neirosplav.com	Возможности программы позволяют решать задачи рейтингования, выбора альтернатив, распределения ресурсов, прогнозирова-ния, планирования, учета предпочтений, моделирования ситуаций. В основу системы поддержки принятия решения "Император" положен метод анализа иерархий
СППР "Эксперт"	http://lab12.geosys.ru/pageslab/lab12_expert.htm	Система основана на методе анализа иерархий (МАИ) Т. Саати. Особенности системы: поддержка как числовых значений, так и субъективных вербальных предпочтений пользователя. Возможность анализа данных на предмет согласованности и достоверности, исправление несогласованности. Удобный графический интерфейс, инструменты для формализации проблемы, анализа результатов. Подробные печатные отчеты. Наличие библиотеки типовых иерархий для решения задач прогнозирования и управления в различных сферах деятельности. Наличие библиотеки решений типовых задач в области финансов, экономики, управлении персоналом, предприятием и т.п.
OPTIMUM	http://www.tomakechoice.com/paper/Odessa2009p.pdf	Система поддержки принятия решений основана на методе анализа иерархий (МАИ). В программе реализована возможность настройки пользовательского интерфейса. Каждый пользователь может создать для себя удобное рабочее место в данной программе. Справочная система содержит описание всех инструментов приложения
СППР "Выбор" 5.3	http://www.cirtas.ru/product.php?id=10	Система является простым и удобным средством, которое поможет структурировать проблему; построить набор альтернатив; выделить характеризующие их факторы; задать значимость этих факторов; оценить альтернативы по каждому из факторов; найти неточности и противоречия в суждениях лица, принимающего решение (ЛПР)/эксперта; проранжировать альтернативы; провести анализ решения и обосновать полученные результаты. Может использоваться при решении следующих типовых задач: оценка качества организационных, проектных и конструкторских решений; определение политики инвестиций в различных областях; задачи размещения (выбор места расположения вредных и опасных производств, пунктов обслуживания); распределение ресурсов; проведение анализа проблемы по методу "стоимость-эффективность"; стратегическое планирование; проектирование и выбор оборудования, товаров
MPRIORITY	www.tomakechoice.com/mpriority.html	Система базируется на методе анализа иерархий. Систему "MPRIORITY" от ее аналогов отличает диалоговый интерфейс, адаптированный под особенности МАИ и восприятие пользователя. Программа содержит диалоговые средства, позволяющие получать наиболее полную информацию о проведенных попарных сравнениях и устранять возможные несогласованности в матрицах попарных сравнений. Использование присутствующего в программной системе механизма шаблонов (шаблон - готовая иерархия для одной из задач принятия решений) позволяет пользователю адаптировать программную систему под область своей деятельности
WinEXP+	http://www.teleform.ru/pages/0002/0006/0001/0002.html	В основе системы - метод анализа иерархий (МАИ). Функциональные возможности системы: создание сложных и разветвленных иерархий, вычисление приоритетов альтернативных решений. Достоинства системы: дружественный интерфейс, включающий интерактивную справку. Гибкие цветовые настройки системы. Возможность расширения системы. Универсальность системы в отношении ее применения в различных областях деятельности. Простота и доступность при обучении пользователей

Выделение признаков классификации СППР

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

1. Технические спецификации.

• Наименование системы.

• Тип пользователя.

• IT-составляющая (перечень используемых информационных технологий).

• Совместимость с другими программными продуктами.

Особенности интерфейса.

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

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

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

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

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

6. Наличие базы знаний. База знаний - это набор правил для выбора соответствующих методов принятия решений в зависимости от условий задачи принятия решения. Единственной системой, имеющей базу знаний, является ЭСППР.

7. Наличие базы данных. База данных СППР служит для хранения данных, описания задач и методов принятия решений.

8. Оценка альтернатив.

• Способы задания множества альтернатив. Множество альтернатив (вариантов решений) может быть конечным, счетным, представлено в виде подмножества n-мерного пространства или задано иным способом. В ЭСППР множество альтернатив может быть конечным или представлено в виде подмножества n-мерного пространства.

• Способы задания предпочтений на множестве альтернатив. Существенным преимуществом обладают системы, предоставляющие возможность выбора различных шкал для задания оценок альтернатив. Например, в системе Expert Choice (модуль Comparion™ Suite) предусмотрены следующие варианты:

  • Pairwise - оценки задаются для каждой пары альтернатив;

  • Rating scale - оценки задаются в порядковой шкале;

  • Simple utility curve - оценки проставляются на заранее построенной кривой;

  • Advanced utility curve - оценки проставляются на заранее построенной кривой с расширенными возможностями;

  • Direct Data input - прямой ввод оценок;

  • Step function - прямой ввод оценок в интервале от 0 до 1.

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

• Способы задания относительной значимости признаков (критериев). Большинство СППР позволяют задавать относительную зна-чимость признаков экспертно. Кроме того, существуют системы, в которых предусматривается возможность рассчитывать вес признаков, например, SuperDecisions и Expert Choice.

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

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

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

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

Организация работы с экспертами.

• Возможность привлечения экспертов. Современные СППР обладают возможностью сбора и обработки групповых суждений экспертов. Некоторые системы позволяют присваивать различные роли экспертам, привлекаемым для решения задачи. Например, система Expert Choice (модуль Comparion™ Suite) предусматривает роли администраторов и простых экспертов. Простые эксперты имеют возможность задавать оценки, администраторы - редактировать исходные данные задачи.

• Учет коэффициентов компетентности экспертов. В большинстве случаев предполагается ручной ввод коэффициентов компетентности экспертов.

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

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

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

Информационная система "Экспертная система поддержки принятия решений (ЭСППР)" ориентирована на автоматизацию процедур анализа проблемных ситуаций и выбора эффективных решений.

Выделим особенности ЭСППР:

• обеспечивает проведение расчетов для обоснования альтернатив на основе экономико-математических методов и моделей с ис-пользованием экспертных оценок специалистов;

• содержит множество математических методов и моделей (в конкретной реализации около 50) в отличие от большинства СППР, использующих, как правило, один метод принятия решения;

• включает методы принятия решений в условиях неопределенности и риска, предусматривающие моделирование проблемных си-туаций принятия решений;

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

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

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

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

• не является проблемно-ориентированной: на основе ЭСППР может быть решена задача принятия решения из любой проблемной области;

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

• автоматизирует процедуру формирования отчетов о вариантах решения задачи на основе реляционной базы данных;

• проводит многомерный анализ решаемых задач и формирование аналитических отчетов с использованием OLAP-сервера;

• обеспечивает доступ конечных пользователей к системе с применением технологии "Тонкий клиент" (через интернет-браузер и веб-сервер).

Архитектура ЭСППР

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

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

Рис. 12.14.  Архитектура Экспертной системы поддержки принятия решений

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

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

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

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

Модуль оперативного анализа и генерации отчетности направлен на формирование отчетности по задачам и аналитической отчетности.

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

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

Реализация выбора метода принятия решения в ЭСППР

ЭСППР допускает два варианта выбора метода принятия решения: путем ответа на задаваемые системой вопросы и в явном виде (по названию метода).

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

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

Рис. 12.15. 

Страница выбора метода принятия решений в ЭСППР содержит несколько рабочих областей (рис. 12.15.).

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

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

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

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

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

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

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

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

Характеристика ЭСППР по выделенным признакам

Приведем характерные особенности ЭСППР по выделенным выше признакам.

Таблица 12.5. Особенности ЭСППР по выделенным признакам
1. Технические спецификации
1.1. Наименование системы	ЭСППР
1.2. Тип пользователя	Лицо, принимающее решения
IT-составляющая (перечень используемых информационных технологий)	Программное обеспечение ЭСППР разработано на языке программирования MS Visual C# в среде Microsoft Visual Studio 2005. База данных системы разработана и функционирует в РСУБД Microsoft SQL Server 2005. Аналитическая отчетность системы реализо-вана и функционирует в ProСlarity Analytics Server. Многомерные витрины данных для аналитической отчетности реализованы и функционируют в Microsoft SQL Server 2005 Analysis Services
1.4. Совместимость с другими программными продуктами	В текущей версии системы совместимость не реализована
2. Особенности интерфейса	Обеспечивает доступ конечных пользователей к системе с применением технологии "Тонкий клиент" (через интернет-браузер и веб-сервер)
3. Методы принятия решений, используемые вСППР	Текущая версия системы содержит около 50-ти математических методов принятия решений
4. Особенности ввода исходных данных	Входные данные задаются пользователем вручную либо копируются из существующих в системе вариантов решения задачи
5. Особенности представления результата решения задачи	Выходные данные формируются в виде отчета, содержащего результаты решения задачи с использованием различных математических методов. В ЭСППР реализован модуль аналитической отчетности, характеризующий эффективность использования системы
6. Наличие базы знаний	База знаний содержит набор правил выбора соответствующих моделей и методов принятия решений для обоснования альтернатив в зависимости от конкретной реализации элементов поставленной задачи
7. Наличие базы данных	База данных содержит информацию, необходимую для проведения расчетов; описания задач и методов принятия решений; формирования отчетов; поддержки многоязычногоинтерфейса, добавления новых методов принятия решений без изменения программного кода системы
8. Оценка альтернатив
8.1. Способы задания множества альтернатив	Множество альтернатив может быть конечным или представлено в виде подмножества n-мерного пространства
8.2. Способы задания предпочтений на множестве альтернатив	Могут быть заданы количественные оценки или порядковые оценки альтернатив по каждому критерию (признаку)
8.3. Принципы согласования оценок альтернатив по различным признакам	Принципы большинства; Парето; последовательного рассмотрения критериев. Возможно решение задачи в два этапа: на первом этапе для согласования оценок альтернатив с позиций различных критериев (признаков) применяется принцип Парето, на втором этапе - принцип большинства
8.4. Способы задания относительной значимости признаков (критериев)	Экспертно в 10- или 100-балльной шкале
8.5. Проверка согласованности оценок альтернатив по отдельным признакам	отсутствует
9. Возможность согласования оценок альтернатив в различных проблемных ситуациях
9.1. Принципы согласования оценок альтернатив в различных проблемных ситуациях в условиях неопределенности	Принципы Парето; пессимизма; оптимизма; Гурвица; антагонистического игрока; Сэвиджа; Лапласа
9.2. Принципы согласования оценок альтернатив в различных проблемных ситуациях с учетом вероятности их появления	Принципы большинства; Байеса
10. Организация работы с экспертами
10.1. Возможность привлечения экспертов	Работа с экспертами реализована во всех методах принятия групповых решений
10.2. Учет коэффициентов компетентности экспертов	Коэффициенты компетентности экспертов вводятся в 10- или 100-балльной шкале
10.3. Принципы согласования оценок экспертов	Принципы большинства и Парето. Возможно решение задачи в два этапа. На первом этапе для согласования оценок альтернатив с позиций различных экспертов применяется принцип Парето, на втором этапе - принцип большинства
10.4. Оценка согласованности мнений экспертов	отсутствует

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

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

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

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

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