Содержание к диссертации
Введение
ГЛАВА 1. Анализ информационных процессов в деятельности ИТК 12
1.1. Анализ процессов деятельности ИТК 12
1.1.1. Исследование характеристик информационных процессов 17
1.1.2. Анализ данных по продолжительности обслуживания заявок 22
1.1.3. Анализ интервалов времени между заявками 25
1.2. Анализ содержания заявок и процессов обслуживания 26
1.2.1. Типы и характеристики проектов 26
1.2.2. Проектные задачи 28
1.2.3. Распределение задач 32
1.2.4. Схемы обслуживания заявок
1.3. Анализ организационных ресурсов 37
1.4. Формализация и постановка задач исследования 41
1.5. Анализ моделей процесса обслуживания 47
1.5.1. Анализ свойств СМО и СемО 48
1.5.1.1. Разновидности СМО 51
1.5.1.2. Сети массового обслуживания 53
1.5.1.3. Модели, используемые для анализа процессов в ИТК 56
1.5.2. Анализ свойств имитационных моделей 57
1.5.2.1. Разновидности имитационных моделей 57
1.5.2.2. Многоподходное имитационное моделирование 59
1.5.2.3. Современные инструментальные средства для создания имитационных моделей 60
1.5.3. Выбор средств имитационного моделирования 62
Выводы по главе 1 66
ГЛАВА 2. Исследование вопросов применения моделей и методов теории массового обслуживания для анализа деятельности ИТК 68
2.1. Применение моделей одноканальных и многоканальных СМО для анализа процессов обслуживания в ИТК 68
2.1.1. Одноканальная СМО с очередью 70
2.1.2. Многоканальная СМО с очередью 72
2.2. Применение моделей СМО с диспетчеризацией 76
2.2.1. Модель с централизованным распределением и перераспределением заявок 80
2.2.2. Модели для анализа процессов обслуживания заявок-проектов 83
Выводы по главе 2 88
ГЛАВА 3. Разработка имитационных моделей для оптимизации организационных ресурсов ИТК 90
3.1. Разработка имитационных моделей процессов обслуживания 90
3.1.1. МИМ, 11 90
3.1.2. МИМ, m1 91
3.1.3. МИМ, m+11 92
3.1.4. МИМ, 1m 93
3.1.5. МИМ, mm 94
3.1.6. МИМ, m+1m 94
3.1.7. МИМ, 1m+1 95
3.1.8. МИМ, mm+1 96
3.1.9. МИМ, m+1m+1 97
3.1.10. Имитационная модель в среде AnyLogic 6 98
3.2. Исследование свойств имитационной модели 122
3.2.1. Проверка адекватности модели 124
3.2.2. Верификация имитационной модели 127
3.3. Планирование и проведение модельных экспериментов 130
3.3.1. Планирование эксперимента 130
3.3.2. Анализ зависимости способа распределения заявок от процента новых сотрудников 133
3.3.3. Решение оптимизационных задач 135
3.3.4. Исследование и сравнение организационных структур 137
Выводы по главе 3 141
ГЛАВА 4. Концепция построения интегрированной многопользовательской системы управления организационными ресурсами с использованием многоподходных имитационных моделей 143
4.1. Структура (архитектура) СППР для управления организационными ресурсами 145
4.2. Вариант реализации СППР с использованием имитационных моделей 147
4.3. Варианты использования имитационной СППР 150
4.4. Разработка сценария использования автоматизированной системы для решения задач управления организационными ресурсами 152
4.5. Разработка требований к автоматизированной системе управления организационными ресурсами 155
4.6. Разработка концепции построения автоматизированной системы управления организационными ресурсами. Информационная модель БД 163
4.7. Функции разработанного программного обеспечения «Монитор» 166
Выводы по главе 4 171
Перечень принятых сокращений 174
Список литературы 175
- Анализ интервалов времени между заявками
- Многоканальная СМО с очередью
- МИМ, m+11
- Варианты использования имитационной СППР
Анализ интервалов времени между заявками
Процесс функционирования и результаты деятельности ИТК зависят от содержания и характеристик потока заявок клиентов и потоков данных от контрагентов. Содержание заявок на обслуживание клиентов включает в себя информацию, влияющую на содержание и характеристики процесса обслуживания: 1) тип проекта АИС; 2) стадия жизненного цикла АИС; 3) требования к продолжительности работ (для рассматриваемой деятельности, как правило, указывается дата, до которой должны быть выполнены работы по заявке); 4) содержание производственной задачи, для решения которой должны быть созданы средства автоматизации; 5) сложность (трудомкость) процесса обслуживания; 6) масштаб АИС (количество и типы автоматизированных рабочих мест (АРМ) в составе системы); 7) статус выполняемых работ; 8) степень оригинальности проекта; 9) требуемая квалификация специалистов. Кроме того, должны регистрироваться следующие сведения: - дата и время поступления заявки; практика деятельности ИТК показывает, что время поступления заявки может использоваться для установления приоритета обслуживания, а плановый момент окончания работ по заявке определяется указанной выше датой (см. п. 3); - идентификационные данные клиента - заказчика работ.
Типы и характеристики проектов «Тип проекта» в данной предметной области обозначает создание новой системы (проект внедрения) или выполнение тех или иных работ, связанных с сопровождением процесса эксплуатации существующей автоматизированной системы (проект сопровождения). По первому типу проектов от заказчиков поступают комплексные заявки, т.е. заявки, требующие выполнения комплекса работ, выполняемых группой специалистов. При этом проект может находиться на одной из стадий жизненного цикла (ЖЦ)), начиная с предпроектного анализа объекта автоматизации (стадия формирования требований пользователя) или стадии технического задания и заканчивая стадией внедрения (состав стадий и этапов процесса создания АИС зависит от принятой модели ЖЦ). Например, на основе данных заявки, относящейся к стадии «Инициация», ответственному менеджеру датся поручение на проведение переговоров с заказчиком; на этапе «Сопровождение» -задача на оказание консультационных услуг по работе с отдельным модулем системы; на этапе «Проектирование» - выполнение проектных работ в соответствии с разработанным техническим заданием, выполняемое группой специалистов. Количество и сложность (доработки) задач в проектах внедрения зависит от возможности использования типовых конфигураций прикладного ПО: возможность использования части типовых подсистем снижает трудомкость процесса внедрения; при необходимости кардинальной переработки типовых и/или разработке новых компонентов трудомкость процесса внедрения существенно возрастает. При этом блоки последовательных подзадач, как правило, могут выполняться параллельно группой специалистов, а отдельные задачи выполняются одним специалистом.
Большинство активных проектов составляют проекты сопровождения, для которых характерно периодическое поступление простых заявок с относительно невысокой трудоемкостью. Проект сопровождения начинается на этапе «Сопровождение».
Характеристики проектов сопровождения: - степень отклонения системы от типовых конфигураций прикладного ПО (определяет сложность проведения обновлений ПО); частота заявок на доработку (заявки на доработку представляют собой требования к доработке или разработке недостающих компонентов системы: справочников, документов, отчетов); - частота обращений по линии консультаций определяется степенью сложности вопросов: часть вопросов пользователей может решаться оперативно в рамках горячей линии консультаций; нерешенные вопросы в зависимости от требуемой оперативности решения либо накапливаются в очереди, либо сразу передаются специалистам по консультационным услугам; - частота заявок на консультационные услуги зависит от потребностей клиентов в получении консультаций на рабочем месте пользователя (при выезде специалиста к заказчику) либо в офисе компании, когда не представляется возможным решить вопрос по линии консультаций.
Содержание автоматизируемой производственной задачи определяет требуемые компетенции специалистов, трудомкость и характер работ; в зависимости от содержания задачи (планирование, учт, формирование аналитических данных и др.) требуются специалисты соответствующей компетенции. При этом может быть установлен требуемый уровень квалификации специалиста (минимально допустимый). С содержанием производственной задачи связаны типовые проектные решения в форме типовых конфигураций прикладного программного и информационного обеспечения, в частности, в рамках системы «1С» такими конфигурациями являются «Бухгалтерия», «Зарплата и кадры», «Управление торговлей», «Управление производственным предприятием» и другие. Соответственно, специалист ИТК, имеющий компетенции в области определенных производственных задач, должен иметь компетенции в области соответствующих конфигураций прикладного ПО.
Принято распределять выполняемые по заявкам работы по типам, который обозначает характер работ, например: консультирование, доработка, обучение, сервис (установка программного продукта или технического обеспечения, тестирование программного продукта и т.п.). Тип работ определяет требуемую для обслуживания специализацию исполнителя, в соответствии с которой исполнитель может принимать участие при выполнении различных работ (таблица 1.7).
Многоканальная СМО с очередью
Когда заняты обслуживанием все п каналов, может выполняться перераспределение заявок между исполнителями, что показано на графе переходов в виде дуг между состояниями Sn+\, Sn+2 и 5 +4 (рисунок 2.11); при этом значения интенсивностей переходов можно определить следующим образом:
В отличие от предыдущей модели (рисунок 2.9) в связи с наличием очередей у каналов и возможностью выполнения функции перераспределения заявок значение интенсивности выходного потока для каждого состояния будет индивидуальным (32, з, …, г+и ,…), следовательно, для получения выражений, позволяющих оценить значения характеристик данной СМО, можно использовать обобщнный подход на основе системы уравнений Колмогорова. Задавая значения интенсивностей переходов можно получить ряд частных решений, соответствующих стационарному режиму обслуживания.
В принципе, в многоканальной СМО с очередями (рисунок 2.10) возможна организация процесса обслуживания с центральным перераспределением и при частичной занятости каналов; в этом случае:
Граф переходов для многоканальной СМО с диспетчером и центральным перераспределением заявок при частичной занятости исполнителей определение состояния Sn+4 должно быть следующим: «Sn+4 - прием и анализ внутренней заявки на перераспределение обслуживания между исполнителями»; граф переходов дополняется переходами из состояний S2, S3, …, Sn+b Sn+2, в состояние Sn+4 и обратно (рисунок 2.12). 2.2.2. Модели для анализа процессов обслуживания заявок-проектов В рамках выполнения проектных работ количество этапов обработки заявок определяется жизненным циклом (ЖЦ) проекта. В частном случае возможны следующие этапы ЖЦ (см. гл.1 и табл. А.1): 1) инициализация – начало нового проекта, связанное с поступлением соответствующей заявки от клиента; 2) подготовка проекта – выявление требований, определение границ проекта, предпроектный анализ; 3) подготовка документации по проекту – подготовка ТЗ, акты приемки и сдачи, подготовка договоров и дополнительных соглашений, отчеты о выполненных работах; 4) разработка – организация команды и процесса разработки, проектирование и планирование, программирование, тестирование, подготовка инструкций пользователей; 5) внедрение – установка и настройка ПО и ТО в инфраструктуре заказчика, перенос данных, тестовая эксплуатация; 6) обучение пользователей.
Возможно повторное возвращение к отдельным этапам (например, подготовка отчетной документации производится после каждого выполненного этапа), пропуск отдельных этапов (например, отсутствие обучения при сохраненном типовом функционале или незначительных методологических изменениях). Состав этапов и начальный этап (проект может начинаться с различных этапов в зависимости от требований заказчика) определяются на этапе инициации, заполняются соответствующие параметры заявки.
Для моделирования непоследовательных и сложных переходов между этапами целесообразно использование сетей массового обслуживания (СеМО), представляющих собой последовательно-параллельные соединения отдельных СМО (рис. 2.13). Init
Процесс выполнения проекта можно представить в виде последовательного процесса, абстрагируясь от исключительных случаев и объединив выполняемые работы в этапы, подобные указанным выше.
Упрощенная модель, отражающая каскадный процесс выполнения проекта, представляет из себя многофазную СМО (рис. 2.14), состоящую из последовательно соединенных многоканальных СМО с ограниченным временем пребывания заявки в очереди (рис. 2.2).
Каждая частная СМО Pi моделирует прохождение проектом этапа i, а каждое обслуживающее устройство Cij – работу j-го специалиста, привлеченного на этапе i.
Многофазная СМО При использовании СеМО в качестве модели деятельности коллектива специалистов под управлением руководителей проектов отдельные группы специалистов, в т. ч. и менеджеры, представляются многоканальными системами массового обслуживания (C1, C2, …, Cn), рисунок 2.15. Работа менеджеров моделируется СМО C1, работа отдельных групп специалистов (разработчики, консультанты, сервис-инженеры) представлена соответствующими СМО C2, C3, …, Cn, где n–1 – количество групп специалистов. В зависимости от количества сотрудников в каждой группе указанные СМО могут быть одно- или многоканальными.
Заявки, выходящие из одних СМО, поступают на обслуживание в другие СМО в соответствии с жизненным циклом проекта; переход заявки из одной СМО (Ci) в другую (Cj) характеризуется вероятностью pij. Такая сеть СМО представляется взвешенным орграфом, вершины которого представляют отдельные СМО (Ci), а дуги указывают направление перехода заявок. Веса дуг равны вероятностям перехода pij. Сети, изображенной на рис. 2.15, соответствует граф, представленный на рис. 2.16. Источник входных заявок представляется отдельной фиктивной СМО С0 [84].
МИМ, m+11
Из очереди на обслуживание inWork заявки передаются объекту delay, который моделирует их обработку. Время обработки заявок зависит от объема работ по данной заявке (параметр value класса Request) и коэффициента за держки, который распределен согласно треугольному закону (параметры рас пределения задаются в соответствии со значениями параметров HandlingDelayFactorMin, HandlingDelayFactorMax, HandlingDelayFactorMode класса Main). Т.е. время обработки заявки в сред нем равно объему работ, но возможно как более быстрое решение задачи, так и превышение сроков.
После обработки заявки (delay) производится освобождение ресурсов (release) и возвращение заявки в родительский процесс через выход exitFinished. В случае если время ожидания заявки в очереди (seize, inWork) превышает установленные нормативы (параметр WaitingTimeout класса Main), то заявки отмечаются как упущенные и покидают процесс через выход exitLost.
Переход из состояния «Свободен» в состояние «Загружен» выполняется в случае если процент занятости специалиста больше 0 (BusyRate() 0). Процент занятости определяется функцией BusyRate. Обратный переход из состояния «Загружен» в состояние «Свободен» производится при нулевой загрузке специалиста (BusyRate()==0).
В случае, если специалист полностью загружен (нет свободных ресурсов в пуле resourсe) и очередь задач на обработку превышает критическое значение (параметр CriticalQueueSize), то агент переходит в состояние «Перегружен». Обратный переход из состояния «Перегружен» в состояние «Загружен» производится при условии, что загруженность специалиста не полная ( 100%) или количество задач в очереди не превышает критического значения.
Находясь в состоянии «Перегружен» специалист с заданной интенсивностью пытается передать задачу из своей очереди другому специалисту. Задачи передаются по правилу LIFO. Таким образом, обеспечивается равномерное распределение задач между специалистами.
Интенсивность попыток передачи заявок определяется функцией ForwardingRate, и зависит от значения параметра ForwardingRate класса Main. Выбор процедуры передачи заявки зависит от выбранного типа перераспределения заявок (параметр DistribType класса Main). В случае если выбран типа перераспределения «Через центр» (DistribType==1) заявка передается функциональному руководителю (процедура ПередатьМенеджеру); в противном случае специалист передает заявки самостоятельно (процедура Передать-Задачу, которая реализует последовательность предложений другим специалистам принять заявку (рисунок 3.19).
Желание специалиста принять передаваемую заявку определяется с помощью функции СогласенНаПрием. Если специалист не загружен (Загружен-ность.isStateActive(Перегружен)==false), имеет необходимую компетенцию (request.systemType==competence) и желание принять задачу, то заявка покидает очередь перегруженного агента и встает в очередь на обслуживание свобод 114 ного агента. Вероятность согласия на принятие передаваемой задачи зависит от параметра ChanceOfConsent класса Main.
Процедура ПередатьЗадачу реализует алгоритм передачи заявки для случая, когда каждый исполнитель имеет право передачи своих задач другим специалистам без согласования данных действий с руководством (Org 115
Type==false). При моделировании данная ситуация реализуется с помощью создания связей между всеми парами агентами в модели.
При использовании иерархической организационной структуры (OrgType==true) возможен алгоритм передачи заявок в два этапа: 1) перегруженный агент передает необработанную заявку диспетчеру (функциональному руководителю или руководителю проекта в зависимости от организационной структуры); 2) диспетчер распределяет необработанные заявки между связанными с ним исполнителями.
Передача заявки от специалиста менеджеру (диспетчеру) выполняется с помощью процедуры ПередатьМенеджеру, которая передает выбранную заявку экземпляру класса Manager (ссылка на данный класс хранится в параметре Manager класса Specialist). Заявка передается на вход enterFromSpec.
Заявка передается функциональному руководителю (менеджеру) с помощью процедуры ПередатьМенеджеру в случае если: 1. Выбран тип перераспределения заявок «Через центр» (DistribType==1); 2. Выбран тип перераспределения заявок «Смешанная схема» (DisribType==3) и специалисту не удается самостоятельно передать заявку (все коллеги дали отрицательный ответ на предложение). Деятельность менеджеров ИТК (диспетчеров, менеджеров проектов, руководителей функциональных подразделений), выполняющих функции приема и перераспределения заявок, моделируется с помощью объектов класса Manager.
Класс Manager является агентом, что позволяет моделировать произвольное децентрализованное поведение отдельных экземпляров объектов и их взаимодействие. Процесс обработки заявки менеджером моделируется с помощью инструментария дискретно-событийного моделирования и объектов библиотеки Enterprise Library (рис. 3.20).
Варианты использования имитационной СППР
Вариант использования «Управление файлами (проектами)» позволяет пользователю сохранять параметры моделей и результаты экспериментов в отдельные файлы, что обеспечивает возможность продолжения работы с ними после перезапуска программы. Файл проекта содержит следующие данные: значения переменных модели; настройки системы; настройки модели; результаты последних экспериментов.
Вариант использования «Редактирование сведений о ресурсах» позволяет пользователю редактировать (создавать, записывать, просматривать, удалять) данные об имеющихся у организации ресурсах, их количестве, типе, доступности и т.п.
Редактируются следующие данные: типы ресурсов; список ресурсов; характеристики ресурсов; доступность ресурсов, статус.
Вариант использования «Калибровка модели» применяется после того как завершена работа по формализации модели и построению ее структуры, и позволяет узнать, при каких значениях параметров модель будет работать наиболее близко к реальной системе, которую она моделирует. То есть такие значения параметров, при которых результат на выходе модели будет наиболее близок к известному (измеренному в реальной жизни). Эксперимент ка 159 либровки производит несколько повторных запусков модели с разными значениями параметров и находит с помощью встроенного оптимизатора такие значения параметров модели, при которых результаты моделирования наиболее точно соответствуют заданным данным.
Вариант использования «Расчет показателей эффективности» предназначен для расчета показателей эффективности на основе результатов имитационного моделирования.
Вариант использования «Сравнение наборов параметров» предназначен для сравнительного анализа различных вариантов построения экономической системы. Например, данный функционал может использоваться при сравнении различных вариантов организационных структур, вариантов пакетов проектов, привлекаемых специалистов и т.п.
Вариант использования «Оценка влияния параметров на показатели эффективности» предназначен для определения зависимости показателей эффективности от выбранных параметров модели. Вариант использования позволяет вычислить, как изменятся показатели эффективности при изменении отдельных параметров (структуры управления, исключения отдельных ресурсов и т.п.). Вариант использования применяется при необходимости принятия решения о целесообразности тех или иных организационных мероприятий.
Вариант использования «Определение оптимальных параметров» предназначен для определения параметров модели, при которых достигается максимум целевой функции при заданных ограничениях – максимальная эффективность моделируемой экономической системы.
Вариант использования «Формирование отчетности» расширяет функциональность вариантов использования, связанных с выполнением экспериментов с имитационной моделью, и позволяет пользователю формировать отчеты по результатам экспериментов, компонуя необходимым образом итоговые данные, настраивая сортировки и отборы.
Простой эксперимент позволяет выполнить единичный прогон имитационной модели при заданных параметрах и получить результаты выполнения эксперимента в виде итоговых показателей и собранной статистики. Именно эксперимент этого типа используется в большинстве случаев. Другие эксперименты нужны в тех случаях, когда важную роль играют значения параметров модели, и нужно проанализировать, как они влияют на поведение или эффективность моделируемой системы или если нужно найти оптимальные параметры модели [90]. Данный вид эксперимента применяется в варианте использования «Расчет показателей эффективности».
Тип эксперимента «Сравнительный прогон» используется при необходимости сравнить результаты различных вариантов наборов параметров модели. При выполнении данного типа эксперимента производится последовательный запуск модели с различными наборами параметров, заданными пользователем, а в конце эксперимента выдается сравнительная оценка результатов, на основе которой пользователь может сделать необходимые выводы. Данный тип эксперимента применяется при использовании варианта «Сравнение наборов параметров».
Анализ чувствительности заключается в выполнении нескольких «прогонов» модели, варьируя значения одного из параметров и показывая, как результаты моделирования зависят от этих изменений. Данный вид эксперимента применяется в варианте использования «Оценка влияния параметров на показатели эффективности».
Оптимизационный эксперимент позволяет найти значения параметров, при которых достигается наилучший результат моделирования системы, а также изучить поведение модели при заданных условиях. Процесс оптимизации модели заключается в выполнении нескольких прогонов модели с различными значениями параметров и нахождении оптимальных (с учетом заданных ограничений) значений параметров (при которых достигается оптимальное значение заданной целевой функции). Данный вид эксперимента применяется в варианте использования «Определение оптимальных параметров». Проведение имитационного эксперимента включает в себя как подготовительный этап ввод параметров имитационной модели. Ввод параметров состоит из формирования потока заявок и ввода параметров внутренней среды экономической системы, обрабатывающей поступающие заявки.
Формирование потока заявок, в зависимости от условий проведения исследования, может производиться двумя способами: 1. Фиксированный список заявок (работ) при оценке эффективности экономической системы (ЭС) при выполнении заданного объема работ. При выполнении данного вида анализа влияние внешней среды не учитывается, поток заявок является детерминированным. 2. При оценке эффективности ЭС в условиях неопределенности, поток заявок формируется на основе параметров (факторов) внешней среды, задаваемых пользователем. При данном виде анализа поток заявок является стохастическим. Пользователь задает параметры внешней среды непосредственно перед выполнением эксперимента.
