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

Школа № 67 открыта 30 августа 1994 года. До 1997 года она носила статус школы – новостройки. На момент открытия школы (в 1994 году) в ней обучалось 1800 учащихся, что превышало объемные показатели в 3,5 раза. Только в начальной школе было укомплектовано 30 классов.
В настоящий момент присвоен статус муниципального автономного общеобразовательного учреждения: МАОУ «СОШ № 67» города Магнитогорска. Имеет опыт работы в сфере образования: Всероссийская научно-практическая конференция работников вузов кафедр педагогики и методики начального образования «Современные подходы к преподаванию в начальной школе», на которой был одобрен опыт по внедрению информационных и здоровье сберегающих технологий в учебный процесс [4, 5, 6]. Наиболее успешным примером с ИТ стало, использование проектного метода в обучении технологии и защиты проекта, как формы итоговой аттестации учащихся по технологии; метод круговой тренировки как способ организации самостоятельной деятельности учащихся; проведение организационно-деятельностных игр. Является участником в федеральном эксперименте по обновлению содержания образования. Приступила к реализации Программы «Организация самостоятельной деятельности учащихся как условие качественного образования». В рамках Приоритетного национального проекта «Образование» школа получила грант Президента. Благодаря Российской Академией образования и науки, Ведущим институтом развивающих технологий, образовательным центром «Школьный университет» за участие в международной исследовательской программе «Будущее за ИКТ» МАОУ «СОШ № 67» присвоен статус «Базовая школа по формированию ИКТ-компетентности школьников [7, 8, 9]. Выступает в качестве Центра образовательной робототехники.
Функциональные обязанности Диспетчера определены на основе должностных инструкций, указанных в уставе Школы.
Диспетчер:

• Осуществляет с использованием средств вычислительной техники, коммуникаций и связи оперативное регулирование хода производства и других видов основной деятельности предприятия или его подразделений в соответствии с производственными программами, календарными планами и сменно-суточными заданиями.
• Контролирует обеспеченность подразделений необходимыми материалами, комплектующими изделиями, оборудованием.
• Осуществляет оперативный контроль за ходом выполнения операций, обеспечивая максимальное использование производственных мощностей, бесперебойную работу Аппаратного обеспечения, выполнение работ (услуг.
• Обеспечивает соблюдение установленных норм по Технике безопасности.
• Принимает меры по предупреждению и устранению нарушений хода работы отделов, привлекая, при необходимости, соответствующие службы предприятия.
• Выявляет резервы производства по установлению наиболее рациональных режимов работы технологического оборудования, более полной и равномерной загрузке оборудования и производственных площадей, сокращению длительности цикла.
• Осуществляет внедрение и обеспечивает рациональное использование технических средств оперативного управления.
• Ведет диспетчерский журнал, составляет отчетные рапорты и другую техническую документацию о ходе работы Технического отдела.
• Участвует в работе по анализу и оценке деятельности подразделений, выявлению резервов [10, 11, 12].

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

Модель “Диаграмм бизнес-процессов верхнего уровня” – VAD является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Дополнительным отличием данной и других процессных моделей является то, что информационные и материальные потоки на схеме VAD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. На модели VAD методологии ARIS в отличие от классического подхода также используется логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ [1, с. 180].
Существующий способ учета приема заявок связан с большой трудоемкостью, разрозненностью сведений, что с большей вероятностью ведет к их утере или неправильной интерпретации. На сегодняшний день невозможно получить сведения об общем количестве заявок, провести анализ основных причин возникновения проблемных вопросов у клиентов и проанализировать причины обращения [13, 14, 15]. Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы за определенный период, что очень затруднительно. Основной причиной возникновения проблем по работе с выполнением заявок выступает затяжной характер выполнения заявки, представленный на рисунке 2.

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

Для оценки значимости факторов создана экспертная группа из двух человек – системные администраторы двух школ. Произведем экспертную оценку используя метод ранжирования для этого составим матрицы обратных рангов (ai,j/(nmax+1)-ai,j) для таблиц 1-11 и найдем весовой показатель (W), где (a) экспертная оценка по (i-ому) критерию (j-го) эксперта [3].

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

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

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

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

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

Общей чертой BPwin и Arena являются блоки моделирования (модули) и операций (сущности). Таким образом, с помощью средств имитационного моделирования создадим Систему обслуживания клиентов ИТ-отдела МАОУ «СОШ№67». Смоделируем данную систему изначально задав параметры: поток клиентов имеет пуассоновское распределение со средним значением 30 минут (обозначается POIS (30)), а время обслуживания заявки составляет от 2 до 10 минут с наиболее вероятным значением 3 минуты (используется распределение Triangular). Какое среднее время ожидания покупателей в очереди, если длительность моделирования составляет 8 часов? Пояснение: мастер может проводить диагностику только одной заявки в каждый момент времени; если мастер занят, запросы от клиентов встают в очередь и ждут, пока он освободится.

На этапе функционального моделирования будут рассмотрены особенности проектирования систем для дальнейшего экспорта в Arena. Запустим программу BPwin, в появившемся окне укажем имя файла и тип диаграммы Process Flow (IDEF3).

Рассмотрим пример построения IDEF3 модели «Диагностика заявок, поступающих от клиентов» для дальнейшего экспорта в Arena. При построении процессной модели используются ряд особенностей:

• Для задания начальных и конечных блоков процессной модели используется Referent tool.
• Названия блоков указываются на английском языке или транслитом, т.к. Arena не распознает кириллицу.
• Стрелки от начальных и к конечным блокам задаются в стиле Referent.

Наша модель принимает вид (рис. 1)

Поскольку имитационная модель Arena должна содержать дополнительные параметры по сравнению с моделью IDEF3, в BPwin используются свойства User-Defined Properties (UDP), импорт которых предварительно осуществляется из файла ArenaBEUDPs.bp1.

Дальнейший порядок действий для работы с диаграммой:

• Необходимо открыть модель Program Files / Computer Associates / BPwin / Samples / Arena / ArenaBEUDPs.bp1 и, находясь в только что созданной модели с примером «Диагностика заявок, поступающих от клиентов», импортировать настройки командой Model/Merge Model Dictionaries/.
• Устанавливаем UDP настройки для каждого блока. Блок School Arrival
• Блок School Arrival соединяется с блоком Diagnostics
• В конечном блоке School Output указывается только галочка о сборе статистики
• После указания UDP на каждом блоке появляется скрепка
• Добавим ресурс (люди, оборудование), который проводит диагностику. Стрелка «механизм», присоединенной к нижней стороне блока работы. Стрелка имеет стиль Relational.
• На вкладке UDP Values зададим название ресурса и его количество -один мастер по диагностике

Перед экспортом в Arena модель в IDEF3 примет вид:

Полученную модель необходимо экспортировать в Arena с помощью команды File/Export/Arena. В результате экспорта получим модель в пакете Arena:

Немного подробнее о самом процессе моделирования нашей системы. Для начала необходимо настроить параметры моделирования командой Run/Setup. Установим длительность моделирования, равную 100 ч (рис. 5). Запустим модель и посмотрим результаты имитационного моделирования с помощью средств автоматических отчетов (таблица 2).

Таблица 1. Результаты моделирования модели

Заключительным этапом проектирования нашей системы является Сравнительный анализ результатов имитационного моделирования и аналитического решения.  Представим задачу на диагностику заявок, поступающих от клиентов в терминах теории СМО. СМО имеет один канал обслуживания (мастер по диагностике). Входящий поток запросов на обслуживание – простейший пуассоновский поток с интенсивностью λ=1 . Интенсивность потока обслуживания равна μ. Длительность обслуживания – случайная величина, подчиненная показательному закону распределения со средним значением 0,7 часа. Рассчитаем характеристики одноканальной СМО с ожиданием, без ограничения на длину очереди:

, т.е. условие стационарности СМО выполняется.

Среднее число заявок в системе:

Средняя продолжительность выполнения заявки в системе:

Среднее число запросов в очереди:

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

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

Таблица 2. Сравнительный анализ

Показатели	Результаты имитационного моделирования				Результаты аналитического решения
	100 ч	300 ч	1000 ч	1500 ч
1. Среднее число заявок в системе	2,8	2,76	2,4	2,3
2. Средн. продолжительность выполнения заявок	2,96	2,7	2,4	2,31
3. Среднее число запросов в очереди	2,02	2,03	1,76	1,66
4. Средн. продолжительность выполнения заявок в очереди	2,1	1,98	1,71	1,63

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

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