CC BY
109
УДК 681.3.06:519.876
Е. П. Моргунов
СИСТЕМА ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ПРИ ИССЛЕДОВАНИИ ЭФФЕКТИВНОСТИ СЛОЖНЫХ СИСТЕМ: ПРИНЦИПЫ РАЗРАБОТКИ, ТРЕБОВАНИЯ И АРХИТЕКТУРА
Сформулированы принципы разработки и требования к системе поддержки принятия решений при исследовании эффективности сложных систем. Предложена архитектура такой системы и обоснован выбор программных средств ее реализации.
Управление сложными системами предполагает, в том числе, и управление их эффективностью. «Эффективность
- это наиболее общее, определяющее свойство любой целенаправленной деятельности, которое объективно выражается степенью достижения цели с учетом затрат ресурсов и времени» [1. С. 59]. В работе [2. С. 71-72] обобщенный показатель эффективности большой системы в наиболее общей форме предлагается строить как некоторую функцию или функционал вида
ж=Ф(УК, Ув, ик, ив),
где Y - возможный или фактически достигнутый полезный эффект (конечный результат) функционирования и развития системы; Y - целевой полезный эффект (необходимый конечный результат) функционирования и развития системы; и - возможные или фактические затраты количества труда (живого и прошлого) для получения Yк; ин - минимальные необходимые затраты количества труда (живого и прошлого) для получения Y.
Если (У^, иЮ рассматриваются как возможные величины, то речь идет о прогнозировании эффективности, а в случае когда (Y, и)фактически полученные, то показатель W будет отражать фактически достигнутую эффективность за некоторый период функционирования системы.
Применяемые методы оценки эффективности систем отличаются большим разнообразием. Среди них есть как детерминированные методы, так и стохастические. В технических системах часто применяются стохастические методы. Например, в работе [2] предлагается формула обобщенного показателя эффективности
ж = (Ж, ж, ж),
где W, W, W - комплексные показатели, соответственно.
н п э ’
целевой надежности системы, целевой производительности системы и целевой экономичности системы.
Определять, например, показатель эффективности W предлагается по формуле
ж =]иёЕк (и),
0
где и - переменная, выражающая возможные значения расхода ресурсов и на получение конечного результата Y; ^к(и) - функция распределения случайной величины ик.
Задача получения аналитических выражений для подобных функций решается на основе аналитических и статистических подходов. Однако выбор вида функциональной зависимости является неформализуемым шагом.
В экономических исследованиях часто используются производственные функции [3], характеризующие максимально возможный объем выпуска у продукта в зави-
симости от используемого объема ресурсов X = (Xi, хт):
У = f (X).
Такая функция позволяет описывать только однопродуктовые технологии. В литературных источниках предложены различные виды производственных функций [3].
Одним из наиболее распространенных методов оценки эффективности систем является метод, известный в России под названием «анализ среды функционирования» (АСФ) [4]. Он был разработан в 1978 г. в США [5] и с тех пор завоевал широкую популярность на Западе. Там он известен как Data Envelopment Analysis (DEA). Метод АСФ (DEA) применяется для оценки эффективности функционирования однородных объектов в таких областях, как экономика, социальная сфера, административное управление и даже спорт.
Метод АСФ (DEA) основан на построении так называемой границы эффективности в многомерном пространстве входных и выходных переменных, описывающих исследуемые объекты. Эта граница строится по реальным данным и представляет собой, по сути, оценку производственной функции для случая, когда выход является векторным. Степень эффективности зависит от расстояния между объектом и границей эффективности.
В качестве иллюстрации приведем описание одной из моделей метода. Пусть требуется определить показатель эффективности каждого из n объектов (это могут быть предприятия, организации, университеты, банки и т. д.). Для описания каждого объекта oj, j = 1, n, служит пара векторов (x,yj). При этом вектор Xj = (xj1,..., xjj,..., xjm)T содержит входные показатели (входы) для объекта oj, а вектор yj = (yj1,..., yjr,..., yjs)T содержит выходные показатели (выходы) для объекта о.. Тогда матрицаX = (xj), имеющая размерность m n, содержит вектор-столбцы с входными данными для всех n объектов, а матрица Y= (у), имеющая размерность s ’” n, содержит вектор-столбцы с выходными данными для всех n объектов. Модель имеет следующий вид [6. С. 43]:
min е,Х (9),
-yj + YX> 0,
9 Xj - XX > 0,
X> 0. (1)
Скаляр и и является мерой эффективности j-го объекта. Важно отметить, что и0(0; 1]. Критерием эффективности объекта является условие и=1. Объекты, имеющие такое значение показателя и, считаются эффектив-
ными и находятся, как принято говорить, на границе эффективности. Аналогичная задача решается для каждого объекта, т. е. n раз.
Для объектов, имеющих и < 1, предлагаются рекомендуемые (целевые) значения показателей, достигнув которых, эти объекты также окажутся на границе эффективности. Определение целевых значений переменных для неэффективного объекта производится путем проецирования данного объекта на границу эффективности. Проецирование обеспечивается за счет присутствия в модели (1) коэффициента и при векторе x. и наличием ограничения X >0. Вектор констант X = (X1,..., Xj,..., Xn)T позволяет сформировать неотрицательную линейную комбинацию объектов, которая и будет являться гипотетическим (и при этом эффективным) целевым объектом для того реального объекта, который оказался неэффективным.
Граница эффективности в данном случае будет иметь вид выпуклого конуса в пространстве входных и выходных переменных Rm+s. Она определяется эффективными (крайними) точками. Модель (1) называется ориентированной на вход. Это объясняется тем, что коэффициент и оказывает влияние на вектор входных переменных. Модель, ориентированная на выход, может быть построена аналогично [6. С. 58].
Еще одним граничным методом, но использующимся не столь часто, как метод АСФ (DEA), является метод оценки стохастической производственной границы -Stochastic Frontier Analysis (SFA). Его предложили
D. J. Aigner и S.F. Chu [7. С. 184]. Отличительной чертой метода является вероятностный характер производственной границы, что позволяет учесть наличие случайных ошибок в значениях входных переменных. Однако метод позволяет работать только со скалярным выходом.
В реальных задачах зачастую исследуются сложные системы с большим числом подсистем и элементов (объектов). Для решения подобных задач необходимо программное обеспечение (ПО), реализующее те или иные методы исследования эффективности систем.
Большинство широко доступных программных продуктов, предназначенных для оценки эффективности систем, реализуют именно метод АСФ (DEA). Есть ПО, реализующее метод SFA [7]. Программных продуктов, реализующих другие методы оценки эффективности и спроектированных в расчете на широкое применение, нам не известно. Детальный обзор существующего зарубежного ПО, реализующего метод АСФ (DEA), представлен в работе [8]. Известны и две разработки российских специалистов: EffiVision и KonSi-DEA. Основные инструменты, применяемые для разработки подобных программных продуктов, - это языки программирования Fortran, C/C++, Visual Basic.
Существующие программные продукты имеют целый ряд достоинств в том, что касается разнообразия реализованных моделей метода АСФ (DEA) и интерфейса пользователя. Однако им присущи и недостатки, в частности, эти программные продукты:
- не являются комплексными в плане набора реализованных методов (все они реализуют только какой-то один метод исследования эффективности);
- не являются комплексными и в плане реализации всех стадий исследования эффективности. Такими ста-
диями можно считать оценку достигнутого уровня эффективности, объяснение достигнутого уровня эффективности, прогнозирование будущего уровня, выдачу рекомендаций по способам достижения требуемого уровня эффективности (за счет перераспределение ресурсов между подсистемами). Существующие программные продукты ограничиваются, в основном, оценкой текущего уровня эффективности и выдачей рекомендуемых значений входных и выходных показателей системы;
- не позволяют описать структуру сложной системы и, проведя исследование эффективности всех подсистем, интегрировать полученные оценки в единую оценку (или группу оценок) эффективности сложной системы, что было бы наглядно для пользователя (системного аналитика или лица, принимающего решения);
- не используют «большие» системы управления базами данных (СУБД), такие как Oracle, PostgreSQL, MySQL и другие, для хранения данных и манипулирования ими. Это снижает надежность операций с данными, а также лишает пользователя всех других преимуществ, которые дает использование СУБД.
Таким образом, есть необходимость в разработке системы поддержки принятия решений (СППР), которая могла бы служить в качестве аналитического и советующего инструмента при проведении комплексных исследований эффективности сложных систем. На данном этапе нами предложены основные принципы, которых следует придерживаться при разработке СППР, а также сформулированы конкретные требования, которые должны предъявляться к СППР, чтобы эти принципы были реализованы на практике (отметим, что четкой границы между принципами и требованиями нет). Предложена также архитектура программного продукта, в которой показаны основные подсистемы СППР и отражены взаимосвязи между ними.
К числу потенциальных пользователей СППР относятся [9]:
- руководитель предприятия (подразделения), заинтересованный в наличии инструментария, который может помочь в выявлении резервов повышения эффективности, в прогнозировании эффективности при проведении организационных изменений;
- исследователь-практик (системный аналитик), которому в дополнение к функциям программного продукта, требующимся руководителю, может быть очень полезным также наличие в СППР типовых сценариев для исследования эффективности систем в типичных ситуациях. Такие сценарии - это совокупности процедур (функций) программного продукта, активизируемые минимальными действиями пользователя и позволяющие решать типовые задачи без больших затрат времени и усилий;
- ученый, которому необходима возможность выполнения исследовательских задач, например, проведения многовариантных расчетов на основе сгенерированных искусственных наборов данных;
- студент, которому нужен инструмент, позволяющий освоить теорию и практику методов исследования эффективности сложных систем.
Предлагаемые принципы разработки СППР служат в качестве главного регулятора всего процесса проектиро-
вания [9]. Следование им позволит, на наш взгляд, получить действительно полезный инструмент поддержки принятия решений при исследовании эффективности сложных систем.
1. Реализация подхода «описание - объяснение -предсказание - рекомендации». Описание означает получение оценок эффективности исследуемой системы. Для объяснения полученных результатов необходимо провести исследование эффективности на уровне подсистем. Прогнозирование эффективности - предсказание
- предусматривает, в частности, анализ тенденций изменения эффективности в подсистемах. Рекомендации должны включать в себя не только указание целевых (конечных) значений показателей для неэффективных систем и подсистем, но также и возможную траекторию перевода системы из неэффективного состояния в эффективное.
2. Включение в СППР средств для структуризации процесса проведения исследования в соответствии со структурой исследуемой системы и задачами исследования. Очевидно, что эффективность сложной системы зависит от эффективности функционирования ее подсистем. При этом эффективность подсистемы может быть рассмотрена с различных позиций (как с точки зрения вышестоящей системы, так и с точки зрения самой исследуемой подсистемы) и в различных сферах ее деятельности (например, эффективность кафедр в вузе может быть оценена как в сфере научной деятельности, так и в сфере образовательной деятельности).
3. Реализация идеи многовариантных расчетов. Пользователь должен иметь возможность использовать различные методы (модели) для получения оценок эффективности исследуемых объектов, варьируя при этом наборы и значения переменных и параметров. Сопоставление полученных многовариантных результатов должно производиться в автоматизированном режиме.
4. Обеспечение возможности настройки СППР в соответствии с потребностями пользователя и уровнем его квалификации.
5. Реализация широкого спектра методов исследования эффективности, возможность расширения СППР путем добавления новых методов, методик, моделей. Важно отметить, что все дополнительные методы, методики и модели должны органично встраиваться в архитектуру СППР по единой схеме.
На основе анализа потребностей потенциальных пользователей и в соответствии с заявленными принципами можно сформулировать следующие требования к СППР [9].
1. Предоставление пользователю возможности описания структуры сложной системы. Структуру системы необходимо хранить в базе данных в виде матрицы, описывающей связи элементов. При этом необходимо хранить и информацию о характеристиках каждой такой связи: направленность связи (от первого элемента ко второму, от второго к первому, двусторонняя связь); сила связи (в обоих направлениях); тип связи (связь управления, информационная связь и др.); влияние этой связи на достижение глобальной цели всей системы и т. д.
2. Использование иерархического подхода при структуризации этапов исследования. За основу формирова-
ния логики работы с программным продуктом предлагается принять понятие «исследование». Это понятие означает всю совокупность действий по обработке информации в процессе проведения исследования эффективности сложной системы. При этом необходимо учесть, что в рамках одного исследования может быть более одной системы. Аналогично, одна и та же система может быть объектом более одного исследования. Каждое исследование может быть разделено на этапы, структура которых отражает исследуемую систему и учитывает цели и задачи исследования. У каждого этапа может быть этап-родитель. Для объединения этапов в связанные группы следует использовать этапы-контейнеры. С этапом-контейнером непосредственно не связывается выполнение каких-либо вычислительных операций. Например, этап-контейнер «Исследование эффективности факультетов» может содержать рабочие этапы «Научная работа на факультетах» и «Учебно-методическая работа на факультетах».
Для реализации идеи многовариантных расчетов необходимо предоставить пользователю возможность формировать для каждого этапа различные варианты исполнения. Такие варианты могут различаться наборами объектов и переменных, а также параметрами моделей. Анализ влияния вариаций на оценку эффективности должен выполняться в автоматизированном режиме (это должно делать ядро программного продукта).
3. Следование принципу «один этап - один метод». Все варианты конкретного этапа должны выполняться на основе одного и того же метода. Если требуется исследовать какую-то подсистему различными методами, то необходимо создать этап-контейнер и включить в него рабочие этапы, реализованные на основе требуемых методов. Данный подход позволит упростить реализацию механизма автоматизированного сравнения результатов многовариантных расчетов.
4. Использование концепции репозитория. Репозиторий содержит всю информацию, необходимую для проведения конкретного исследования: описания объектов (в том числе и гипотетических объектов, предложенных при реструктуризации системы); описания переменных; описания структуры системы (или систем, если их больше одной); исходные данные (возможно, за несколько временных периодов); описания временных периодов.
Предлагается следующая иерархия уровней репозитория по степени детализации: уровень исследования; уровень этапа исследования; уровень варианта этапа исследования.
С точки зрения степени обобществления информации должен существовать глобальный репозиторий (доступ к нему должен быть открыт для всех пользователей, выполняющих другие исследования); локальный репозиторий (доступен только для пользователей, проводящих конкретное исследование).
Данные, содержащиеся в репозитории исследования, должны быть представлены в оригинальном виде, т. е. без каких-либо преобразований. Преобразования данных целесообразно выполнять уже непосредственно при работе с данными в рамках проведения этапа (варианта этапа) исследования.
5. Разработка языка описания сценариев работы с СППР Такой язык должен позволять пользователю описывать взаимосвязи элементов системы в терминах теории эффективности. Он должен использоваться для написания сценариев работы СППР в тех случаях, когда требуется проведение многовариантных расчетов, а также для реализации высокоуровневых методик, построенных на основе одного или нескольких методов оценки эффективности (подобные методики предлагались, например, в работах [10; 11]). В этом языке должны быть предусмотрены соответствующие типы данных и операторы. Пользователь должен иметь возможность сформировать сценарий работы согласно методике и сохранить его описание в базе данных с тем, чтобы затем воспроизводить написанный сценарий на различных наборах данных (на различных системах).
6. Организация коллективной работы. Коллективное использование программного продукта может быть организовано через локальную сеть или на одном компьютере. При этом необходимо обеспечить раздельный доступ к данным, принадлежащим различным пользователям.
7. Наличие средств гибкого конфигурирования СППР. При этом следует использовать иерархический подход: конфигурирование на уровне всей СППР, конфигурирование на уровне исследования, конфигурирование на уровне конкретного пользователя.
8. Различная степень детализации результатов и форм их представления. Должны быть предусмотрены возможности для представления как детализированной, так и агрегированной информации о результатах. Результаты должны сохраняться и визуализироваться в виде таблиц базы данных, текстового файла-отчета, графиков и диаграмм.
В соответствии с вышеизложенными принципами и требованиями предлагается архитектура СППР [9] (рису-
нок). Главной подсистемой, которая управляет работой СППР, является ядро (диспетчер). Оно принимает запросы от интерфейса пользователя и преобразует их в вызовы процедур, содержащихся в библиотеке методов и моделей. Интерфейсом между ядром и СУБД служит подсистема манипулирования данными. Модули библиотеки методов и моделей не должны содержать вызовов SQL-запросов. Ядро формирует символьные строки команд для работы с базой данных и переадресует их для выполнения в подсистему манипулирования данными. Эта подсистема «знает», где находится база данных: на локальной машине или на другом сервере в локальной сети. Подсистема манипулирования данными выполняет команды и сообщает ядру результат: выполнено успешно или с ошибкой. Результаты запросов на выборку данных подсистема манипулирования данными передает ядру. Ядро готовит данные для передачи их функциям (процедурам), реализующим математические методы. При этом оно формирует необходимые структуры данных в памяти в том виде, в каком требуется для библиотеки методов и моделей. Ядро принимает результаты выполнения математических процедур от библиотеки методов и моделей и передает их для визуализации или формирует строки команд для вставки записей в таблицы базы данных.
Ядро считывает файлы конфигурации и формирует необходимые глобальные структуры данных.
Важным вопросом является выбор средств программной реализации СППР. Используемые средства должны обеспечивать переносимость программного продукта в различные операционные среды: программный продукт (конечно, после перекомпиляции исходных текстов) должен работать не только в среде операционной системы Windows, но также и в среде операционной системы ЦЖХ
Средства 0нтернац0онал0зац00 (118п) 0 локал0зац00 ^10п)
Подс0стема
конф0гар0рован0я
Сч0тыван0е параметров
Данные для расчетов
Б0ал0отека методов 0 моделей
Справочная подс0стема
\ і :
Интерфейс пользователя
\ ч 1 Главное меню 0 меню модолей
1
Резсльтаты
выч0слен0й
Запросы данных 3ап0сь резольтатов выч0слен0й
(д0спетчер)
В0зоал0зац0я резольтатов 0 строктор оаъектов
Вза0модейств0е пользователя с аазой данных
Ввод данных
Подс0стема ман0пол0рован0я данным0
Запрос
Ответ
СУБД
3ап0сь
Выаорка
База данных
Предлагаемая архитектура программного продукта 62
(в частности, Linux и FreeBSD). Исходя из этого, библиотека методов и моделей должна быть написана на языке C, а интерфейс пользователя представляется целесообразным разработать на языке C++ с использованием многоплатформенной библиотеки wxWidgets.
От СУБД зависит удобство выполнения и надежность операций манипулирования данными. В качестве СУБД, на наш взгляд, целесообразно выбрать PostgreSQL. Эта система управления базами данных поддерживает стандарт языка SQL, отличается высокой надежностью и быстродействием.
Немаловажным фактором при выборе инструментальных программных средств является их цена. В этом плане предлагаемые программные средства имеют преимущество: они являются бесплатными и доступны в исходных кодах.
Итак, предлагаемые архитектурные решения позволят создать СППР, которая будет иметь ряд преимуществ по сравнению с программными продуктами, доступными в настоящее время. К главным преимуществам СППР следует отнести:
- возможность комплексного исследования эффективности сложной системы с учетом ее структуры;
- реализацию идеи многовариантных исследований с автоматизированным сопоставлением полученных результатов;
- организацию хранения и обработки данных в соответствии с теорией баз данных и с использованием профессиональной СУБД.
Таким образом, программный продукт, разработанный в соответствии с изложенными принципами и требованиями, мог бы стать полноценной системой поддержки принятия решений в процессе исследования эффективности сложных систем в экономике, социальной сфере, административном управлении.
Библиографический список
1. Надежность и эффективность в технике : справ. / ред. совет: В. С. Авдуевский (пред.) [и др.]. В 10 т. Т. 1. Методология. Организация. Терминология / под ред. А. И. Рембезы. М. : Машиностроение, 1986. 224 с.
2. Соломонов, Ю. С. Большие системы: гарантийный надзор и эффективность / Ю. С. Соломонов, Ф. К. Шахта-рин. М. : Машиностроение, 2003. 368 с.
3. Клейнер, Г. Б. Производственные функции: теория, методы, применение / Г. Б. Клейнер. М. : Финансы и статистика, 1986. 239 с.
4. Анализ эффективности функционирования сложных систем / В. Е. Кривоножко [и др.] // Автоматизация проектирования. 1999. № 1. С. 2-7.
5. Charnes, A. Measuring the Efficiency of Decision Making Units / A. Charnes, W. W. Cooper, E. Rhodes // European Journal of Operational Research. 1978. Vol. 2. P. 429-444.
6. Cooper, W. W. Data Envelopment Analysis: a Comprehensive Text with Models, Applications, References, and DEA-Solver Software / W. W. Cooper, L. M. Seiford, K. Tone. Boston : Kluwer Academic Publishers, 2000. 318 p.
7. Coelli, T. An Introduction to Efficiency and Productivity Analysis / T. Coelli, D. S. Prasada Rao, G. E. Battese. Boston : Kluwer Academic Publishers, 1998. 275 p.
8. Handbook on Data Envelopment Analysis / W. W. Cooper, L. M. Seiford, J. Zhu (Eds.). Boston : Kluwer Academic Publishers, 2004. 608 p.
9. Моргунов, Е. П. Архитектура и принципы разработки системы поддержки принятия решений для исследования эффективности сложных систем / Е. П. Моргунов // XI Международная научно-практич. конф. «Системный анализ в проектировании и управлении», 28-30 июня 2007 г. (г. Санкт-Петербург) : труды. В 3 ч. Ч. 3 / Санкт-Петербургский гос. политехн. ун-т. СПб. : Изд-во Политехн. ун-та, 2007. С. 232-237.
10. Антамошкин, А. Н. Методика исследования эффективности сложных иерархических систем / А. Н. Ан-тамошкин, О. Н. Моргунова, Е. П. Моргунов // Вестник Сиб. гос. аэрокосмич. ун-та / под ред. проф. Г. П. Белякова ; Сиб. гос. аэрокосмич. ун-т. Красноярск, 2006. Вып. 2 (9). С. 9-13.
11. Cook, W. D. Hierarchies and Groups in DEA / W. D. Cook, D. Chai, J. Doyle, R. Green // Journal of Productivity Analysis. 1998. Vol. 10. P. 177-198.
E. P. Morgunov
DECISION SUPPORT SYSTEM FOR EFFICIENCY ASSESSMENT OF COMPLEX SYSTEMS: DESIGN PRINCIPLES, REQUIREMENTS, AND ARCHITECTURE
Basic design principles and requirements for decision support system used for efficiency assessment of complex systems are formulated. Architecture of such a system is proposed and means for programming implementation of this system are justified.
