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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как правило, структурирование корпоративного бюджета предусматривает наличие двух групп планов - функциональных бюджетов и основного бюджета (иногда его называют мастер-бюджетом). Типовая структура бюджета схематично может быть представлена так, как показано на рис.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-й степени, в крайнем случае, система алгебраических уравнений.

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

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

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

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

За рубежом появилось огромное количество современных систем имитационного моделирования (симуляторы). Коммерческие симуляторы специализированы по отраслям промышленности: 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:

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

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

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

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

Во всех случаях создавать имитационные модели без предварительного анализа бизнес-процессов не всегда представляется возможным. Действительно, не поняв сути бизнес-процессов предприятия, бессмысленно пытаться оптимизировать конкретные технологические процессы. Поэтому функциональные и имитационные модели не заменяют, а дополняют друг друга, при этом они могут быть тесно взаимосвязаны. Имитационная модель дает больше информации для анализа системы. В свою очередь, результаты такого анализа могут стать причиной модификации модели процессов. Наиболее целесообразно сначала создать функциональную модель, а затем на ее основе построить модель имитационную. Для поддержки такой технологии инструментальное средство функционального моделирования 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База знаний - это совокупность единиц знаний, которые представляют собой формализованное с помощью некоторого метода представления знаний отражение объектов проблемной области и их взаимосвязей, действий над объектами и, возможно, неопределенностей, с которыми эти действия осуществляются [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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим применение аппарата нечеткой логики на примере оценки надежности поставщика, в котором кроме фактора финансового состояния учитывается и фактор формы собственности (рис.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.4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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