Читайте также:
|
Создадим следующие типы объектов: Inform query - вопросы (информационный запрос); Registration Docs - Заявление на страхование; Declaration post - Заявление на возмещение, высланное по почте; Declaration person - Заявление на возмещение, поданное лично.
Следует отметить, что названия объектов должны быть записаны латинским шрифтом. Русский она не понимает. Но текстовые надписи на схеме можно делать русскими.
Зададим Начальную картинку для каждой сущности. Она задается описанием, которое можно выбрать из типового ниспадающего списка. При запуске модели, в ходе анимации, эти картинки будут отображать прохождение объектов по нашей модели. Например, вопросы будут выглядеть как желтые листочки, заявления, как синие.
Далее следуют стоимостные характеристики, которые в нашей модели не рассматриваются. Лично мне они непонятны и требуют специального изучения.
2. Создадим используемые ресурсы. Для этого откроем в навигаторе раздел Basic Process, щелкнем на Resource и заполним следующую таблицу.
Name - имя ресурса. Ресурсами у нас будут должностные лица: Chief - руководитель; Cashier - кассир; Inform operator - оператор справочной; Registrator - регистратор; Insurer - страхователь; Doc Operator - оператор работы с документами.
Type - зададим тип путем выбора из ниспадающего списка одного из двух: фиксированное количество (Fixed Capacity) или может меняться по расписанию (Based on Schedule). Всех служащих мы сделаем фиксированными, а начальник будет работать по расписанию. Это значит, что он будет подписывать документы в определенное время (1 час в конце рабочего дня), а служащие будут заняты постоянно. Остальные его дела находятся вне рамок нашей модели.
Capacity - количество. Зададим его.
3. Создадим расписания. Для этого откроем в навигаторе раздел Basic Process, щелкнем на Schedule и заполним следующую таблицу.
- Schedule Sign - расписание для подписи документов начальником. Format Type (Тип формата) - Duration (отрезок времени). Type (тип) - Capacity (количество). Задается для блока процесса. Scale Factor -масштабный множитель зададим равный 1. Durations (продолжительность) определяет график расписания. Если в этой ячейке щелкнуть дважды, то появится окно для создания графика. Для задания установок нажимаем кнопку Options. Там устанавливаем шаг по шкале Х (Time slot duration) равный 1 часу. Получится всего 8 шагов в сутки, т.к. в модели установлен 8-ми часовой рабочий день (Run - Setup - Replication Parameters - Hours Per Day = 8). Задаем интервал (Range) равным 30 временных шагов. Это означает, что на диаграмме будет отображаться 30 делений. Скорость движения календаря (Calendar speed) устанавливаем равной 1 шаг на клик (slots per click). Это означает, что при нажатии кнопки " > " календарь будет сдвигаться на одно деление. По оси Y задаем максимальное количество подписей, которое может сделать начальник за отведенный на это час, равное 100. Минимальное - 0. Когда расписание заканчивается (When at end of Schedule) оно должно начаться сначала (Repeat from beginning). На графике расписания щелкаем мышью внутри нужного отрезка времени и протягиваем до необходимого значения. Установим его равным 100. Можно было бы сделать подпись документов два раза в день по 0,5 часа. Тогда необходимо сделать шаг равным 0,5 часа, а значения в графике два раза по 50. Если щелкнуть правой кнопкой мыши в позиции Durations, то возникнет контекстное меню, из которого можно редактировать расписание через диалог или дополнительную таблицу значений.
- Schedule Post - расписание доставки почты. Для него тип будет Arrival (поступление). Он задается для блока инициирования.
Теперь приступим к созданию модели.
4. Сначала создадим блок инициирования (Create), который будет генерировать начальные события. Для этого перетянем пиктограмму Create из навигатора в поле модели. Щелкнув на нем заполним размещенную внизу таблицу. То же самое можно сделать щелкнув два раза на блоке и заполнив возникшее окно.
Name - имя блока: A1.2. Это будет генератор потока заявлений на страхование. Entity Type - Тип сущности выберем из ниспадающего списка уже созданных: Registration Docs - Заявление на страхование. Type - Random (Expo), т.е. распределение потока событий подачи заявлений будет определяться экспоненциальным законом. Его мы выберем из ниспадающего списка. Интенсивность поступления заявлений примем 0,2 ед. в час. Entities per Arrival - количество объектов, которые будут поступать в момент одного события равно 1. Это значит, что в каждом конверте (или у каждого заявителя) будет одно заявление. Теоретически может быть и по другому. Например, каждый заявитель может приносить несколько заявлений, скажем, по всем машинам своей фирмы.
Блок A2.2 будет определять поток вопросов (Inform query). Распределение потока будет также определяться экспоненциальным законом с характеристиками 0,8 вопроса в час.
Блок A1.1 будет определять поток заявлений на выплату страхового возмещения, поданных по почте. Тип сущности выберем из ниспадающего списка уже созданных: Declaration post. Type - Schedule (Расписание). То есть, почта будет приходить по расписанию, которое мы уже создали: Schedule Post. Entities per Arrival - количество объектов, которые будут поступать в каждый приход почтальона, равно 0,4. Это значит, что интенсивность поступления почты будет 0,4 заявления при каждой доставке. Реально это означает, что заявления почтальон будет приносить не всегда. За 10 приходов он будет приносить в среднем 4 заявления. В ходе моделирования это будут случайные события.
5. Далее создадим блок процесса "Оформление документов". Для этого перетянем пиктограмму прямоугольника (Process) из навигатора в поле модели. Щелкнув на нем заполним размещенную внизу таблицу.
Name - имя процесса: PM1. Имя здесь означает, что он будет выполнять функции оформления документов на рабочем месте № 1.
Type - тип процесса выбираем из ниспадающего списка. Он может быть стандартный (Standard) или представлять субмодель (Submodel). Субмодель позволяет внутри него разместить вложенную модель. В нашей модели мы ограничимся стандартными процессами.
Action - действие (операция). Возможны следующие виды действий: Delay - задержка, ресурсов не требует, а просто процесс длится определенное время. Seize Delay - сцепленная задержка: ресурс используется определенное время, а после использования не освобождается. Seize Delay Release - ресурс используется, а после использования освобождается. Для нашего процесса оформления документов выберем Seize Delay Release, поскольку ресурсом будет страхователь (Insurer), и он после использования освобождается (в отличие, например, от бутерброда, который повторно использовать невозможно).
Priority - приоритет, выберем средний (Medium(2)). Смысл выбора приоритета заключается в том, что если ресурс назначен для использования в нескольких процессах, то очередность его применения будет определяться приоритетом.
Resources - используемые ресурсы. Если два раза кликнуть на процессе, то возникнет окно свойств, в котором можно добавлять ресурсы. Добавим (add) из ранее созданного перечня страхователя (Insurer). В принципе на один процесс можно добавлять много ресурсов, но мы ограничимся одним (1 rows).
Delay Type - тип задержки. Будем считать, что задержка (т.е. время выполнения процесса с одним объектом - заявление) определяется треугольным законом с характеристиками: Min = 0,5; Value = 0, 75; Max = 1. На русском языке это означает, что время оформления документов случайным образом будет меняться от 0,5 до 1 часа. Вообще, выбор закона распределения случайной величины тема для отдельного разговора и относится больше к теории вероятностей. Поэтому, будем считать, что читателям известны ее основы. Arena предоставляет возможность выбора наиболее употребительных законов: нормального, треугольного, равномерного, экспоненциального и целого ряда других.
Allocation - распределение. Определяет, как время и стоимость процесса будут относиться к сущности. Возможно: Value added - добавляющие стоимость; Non-Value added - не добавляющие; Transfer - передаваемые. Не очень понятно, да?
Аналогичным образом создадим и опишем остальные процессы согласно схеме.
Для того чтобы связать блоки между собой используем Связь (Connection). Задать ее можно двумя способами. 1) Нажимаем кнопку Connect в верхней панели (или выбираем в меню Object - Connect) и проводим связь от одной точки привязки блока к точке другого. 2) Можно делать это автоматически при создании блока. Для этого выделим уже существующий (исходящий) блок. Тогда при перетаскивании из навигатора нового блока между ними автоматически образуется связь.
6. Проиллюстрируем создание и использование блока принятия решений (Decide)
Необходимость в блоке принятия решений возникает, когда потоки объектов разделяются. В нашем случае необходимо разделить ответы на заявления, поданные лично и пришедшие по почте. Блок Decide2 на нашей схеме будет определять каким образом мы будем передавать заявителю документы: пересылать по почте или выдавать лично. Эти характеристики задаются в таблице.
| Name | Type | If | Entity Type |
| Decide2 | 2-way by Condition | Entity Type | Declaration person |
Выбираем тип блока 2-way by Condition. Это означает, что на выходе блока будут две ветви, а потоки будут распределяться по условию. Условие определяет, что если типом сущности (Entity Type) будет Личное Заявление на возмещение (Declaration person), то оно пойдет по ветке "да" (True). Значит Заявление по почте пойдет в другую ветвь (False).
Другими вариантами разветвлений могут быть: N-way by Condition - N-ветвей по условию; 2-way by Chance - две ветви случайно, т.е. надо указать процент случайного распределения; N-way by Chance - N-ветвей случайно.
7. Выходной блок (Dispose) используется для подсчета количества объектов на выходе. По завершении моделирования процесса рядом с ним возникнет число, показывающее, сколько объектов скопилось на выходе. У нас это будет количество страховых выплат по заявлениям, поданным лично и присланным по почте.
ПРИМЕР №3.
Дата добавления: 2015-11-14; просмотров: 27 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Добавление графиков | | | Постановка задачи 1 |