Исследование и разработка алгоритмов обработки инцидентов в службе технической поддержки судов общей юрисдикции

Шуваева Е.Ю.

Исследование и разработка алгоритмов обработки инцидентов в службе технической поддержки судов общей юрисдикции

09.04.03 Прикладная информатика

Информатика

Дипломы

Вуз: Белгородский государственный университет - национальный исследовательский университет (НИУ «БелГУ»)

ID: 5c1a752e7966e104f6f85a84

UUID: 21b14800-e5db-0136-04cc-525400005860

Язык: Русский

Опубликовано: больше 5 лет назад

Просмотры: 26

Шуваева Е.Ю.

Источник: Федеральное государственное автономное образовательное учреждение высшего образования «Белгородский государственный национальный исследовательский университет»

Комментировать 0

Рецензировать 0

Скачать - 1,9 МБ

Поделиться работой

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» ( Н И У « Б е л Г У » ) ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК КАФЕДРА ПРИКЛАДНОЙ ИНФОРМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ИССЛЕДОВАНИЕ И РАЗРАБОТКА АЛГОРИТМОВ ОБРАБОТКИ ИНЦИДЕНТОВ В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ СУДОВ ОБЩЕЙ ЮРИСДИКЦИИ Выпускная квалификационная работа обучающейся по направлению подготовки 09.04.03 Прикладная информатика очной формы обучения, группы 07001633 Шуваевой Екатерины Юрьевны Научный руководитель к.т.н., доцент Гахова Н.Н. Рецензент заместитель директора филиала ФГБУ ИАЦ Судебного департамента в Белгородской области Ширкин Р.В. БЕЛГОРОД 2018

СОДЕРЖАНИЕ ВВЕДЕНИЕ .................................................................................................................................... 3 1 ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ ......................................................................................................................................... 8 1.1 Общие сведения об инцидент-менеджменте в информационной системе службы технической поддержки ............................................................................................................ 8 1.2 Анализ предметной области в рамках поставленной задачи по материалам отечественных и зарубежных публикаций ............................................................................16 1.3 Постановка задачи управления инцидентами в службе технической поддержки ГАС «Правосудие» ..................................................................................................................20 2 ИССЛЕДОВАНИЕ МЕТОДОВ И РАЗРАБОТКА АЛГОРИТМОВ ДЛЯ ОПТИМИЗАЦИИ ПРОЦЕССА ОБРАБОТКИ ЗАЯВОК В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ ..............................................................................................................................28 2.1 Исследование основных типов инцидентов службы технической поддержки ГАС «Правосудие» и их классификация ........................................................................................28 2.2 Математические методы исследования возможностей оптимизации процесса обработки инцидентов.............................................................................................................30 2.2.1 Моделирование процесса обработки поступающих заявок средствами теории очередей ................................................................................................................................30 2.2.2 Моделирование задач по критерию назначения работ ......................................33 2.2.3 Моделирование задачи об оптимальной замене оборудования .......................38 2.3 Разработка алгоритмов для оптимизации процесса обработки заявок в службе технической поддержки ..........................................................................................................41 3 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ АЛГОРИТМОВ ОБРАБОТКИ ИНЦИДЕНТОВ В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ СУДОВ ОБЩЕЙ ЮРИСДИКЦИИ ..................47 3.1 Программная реализация и апробация алгоритмов обработки инцидентов в службе технической поддержки .............................................................................................47 3.2 Анализ и оценка полученных результатов поставленной задачи ............................65 ЗАКЛЮЧЕНИЕ............................................................................................................................71 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ..................................................................73 ПРИЛОЖЕНИЯ ...........................................................................................................................81

ВВЕДЕНИЕ В настоящее время служба технической поддержки является сервисной структурой и осуществляет поддержку пользователей в ряде услуг, которые помогут устранить неисправности в работе с компьютерными аппаратными средствами, программным обеспечением. Перед службой технической поддержки ставится задача обеспечения доступности поддерживаемых информационных систем и своевременного разрешения прерывания сервиса [3]. Существует определенная модель решения инцидентов, но она недостаточно эффективна при поступлении большого количества заявок. В среднем, каждая 5-я заявка из числа принятых звонков не регистрируется в системе [4]. При управлении инцидентами большое количество заявок не обслуживаются вовремя, возникает проблема нарушения сроков разрешения инцидента. При большом потоке заявок появляются непринятые вызовы, это критично, так как пользователь обращается за помощью тогда, когда возникшая проблема имеет высокую степень значимости для него или для его бизнеса. Наличие проблем говорит о недостаточной степени эффективности функционирования инцидентменеджмента и отсутствии сервис-ориентированного подхода при его организации. Служба технической поддержки является важной функциональной составляющей ITIL (библиотеки инфраструктуры информационных технологий), позволяющая выявить проблемные участки инфраструктуры и оценить эффективность работы ИТ-подразделения [5]. Для ИТ- подразделения большую значимость представляет объем информации, которая у них скапливается. Исходя из объема хранимой, поступающей и обрабатываемой информации накапливаются статистические данные. За счет наличия статистики осуществляется диагностика проблем, производится постоянный мониторинг ошибок, который выявляет проблемы, возникающие при работе. Этим обусловлена необходимость в снижении

количества пропущенных звонков и незарегистрированных заявок в службе технической поддержки. Таким образом, одной из важнейших задач совершенствования ИТинфраструктуры предприятия является повышение эффективности функционирования системы управления инцидентами. Актуальность данного исследования заключается в том, что в настоящее время работа службы технической поддержки в условиях большого потока заявок приводит к потерям зарегистрированных обращений, непринятым звонкам, нарушению сроков. Для решения вышеуказанных проблем в данной работе предложен алгоритм, позволяющий уменьшить количество просроченных заявок, снизить процент пропущенных звонков и незарегистрированных заявок в службе технической поддержки и тем самым повысить эффективность управления инцидентами. В качестве объекта исследования в работе выступает система управления технической поддержкой судов общей юрисдикции и разрешения инцидентов. Предметом исследования являются процессы функционирования системы управления технической поддержки. Целью исследования является оптимизация процесса обработки инцидентов в службе технической поддержки судов общей юрисдикции. Для достижения поставленной цели необходимо решить следующие задачи:  изучить сведения об инцидент-менеджменте в информационной системе службы технической поддержки;  провести анализ предметной области в рамках поставленной задачи по материалам отечественных и зарубежных публикаций;  провести анализ результатов управления инцидентами, полученных в процессе функционирования службы технической поддержки ГАС «Правосудие»; 4

 исследовать методы и выполнить моделирование процессов оптимизации для оптимизации процесса обработки заявок;  разработать алгоритмы на основании математических моделей;  осуществить реализацию и тестирование автоматизированного решения для оптимизации процесса обработки инцидентов в службе технической поддержки судов общей юрисдикции;  провести сравнительный анализ полученных результатов. Научная новизна исследования заключается в следующем:  на основании проведённого статистического анализа данных использованы математические модели состояния и динамики качества процессов технической поддержки и управления инцидентами;  управления разработаны и апробированы алгоритмы качества процессов инцидентами на основании комплексного подхода к применяемым методам математического моделирования;  процессов предложены научно-технические обоснования по оптимизации управления качеством технической поддержки на базе стандартизации. Теоретическую значимость научно-исследовательской работы представляют разработанные алгоритмы, отличающиеся тем, что выполнен комплексный анализ методов оптимизации процессов обработки инцидентов Практическая значимость результатов диссертационной работы заключается в следующем:  выявлена зависимость количества незарегистрированных обращений и длительности разрешения инцидентов от количества каналов обработки заявок, а также закономерности и пропорции в распределении инцидентов между линиями технической поддержки;  разработаны алгоритмы оптимизации длительности разрешения инцидентов используемых при имитационном моделировании бизнеспроцессов технической поддержки в рамках их совершенствования; 5

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

Во введении указана актуальность выбранной темы, объект и предмет магистерского исследования, цель и задачи научного исследования, новизна, теоретическая и практическая значимость исследования. В первом разделе магистерской диссертации проведен анализ существующей модели управления инцидентами, которая используется в большинстве компаний. Проанализирована концепция управления ИТсервисами и анализ информационных систем на базе передового опыта, изложенного в библиотеке ITIL. Выявлены проблемы ухудшения качества предоставления технической поддержки. Проведен статистический анализ результатов управления инцидентами, полученных в процессе функционирования существующей модели управления инцидентами в службе технической поддержки и выполнена постановка задачи. Во втором разделе на основе результатов анализа, проведенного в первом разделе магистерской классифицированы диссертации, систематизированы и существующие инциденты в службе технической поддержки. Применяется математический аппарат теории очередей в системах массового минимального обслуживания, количества каналов и решается обработки задача заявок нахождения при заданных ограничениях. Предложены алгоритмы управления инцидентами. В третьем разделе описана выполненная на тестовых данных программная реализация алгоритмов обработки инцидентов службы технической поддержки. Представлен сравнительный анализ результатов управления инцидентами до применения разработанной методики и после. Проведена оценка целевой эффективности разработанной методики. Выпускная квалификационная работа представлена на 92 листах, из них 81 лист основного текста и 11 листов приложения. Она содержит 5 таблиц и 19 рисунков. 7

1 ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ 1.1 Общие сведения об инцидент-менеджменте в информационной системе службы технической поддержки Служба технической поддержки является важной функциональной составляющей ITIL (библиотеки инфраструктуры информационных технологий), позволяющая выявить проблемные участки инфраструктуры ИТ, оценить эффективность работы подразделения ИТ [6]. Для ИТ-компании большую значимость представляет объем информации, которая у них скапливается. Исходя из объема хранимой, поступающей и обрабатываемой информации накапливаются статистические данные. За счет наличия статистики осуществляется диагностика проблем, производится постоянный мониторинг ошибок, который выявляет проблемы, возникающие при работе. Этим обусловлена необходимость в снижении количества пропущенных звонков и незарегистрированных заявок в службе технической поддержки. Таким образом, одной из важнейших задач совершенствования ИТинфраструктуры предприятия является повышение эффективности функционирования системы управления инцидентами. В настоящее время работа службы технической поддержки в условиях большого потока заявок приводит к потерям зарегистрированных обращений, непринятым звонкам, нарушению сроков, принятых в Соглашении об уровне услуг (SLA), что отрицательно сказывается на бизнесе, отсутствует сервис-ориентированный подход при организации инцидент-менеджмента [7]. Service Desk ориентированная на – специализированная обработку функциональная специфических сервисных единица, событий, поступающих в форме обращений пользователей или сообщений систем мониторинга [8]. Также Service Desk – единая точка контакта (Single Point Of 8

Contact) между поставщиком сервисов и пользователями. В настоящее время Service Desk позволяет адаптировать бизнес к быстро меняющимся условиям рыночной среды за счет информации получаемой в ходе обработки собираемых статистических данных. Главная цель Service Desk – восстановить тот уровень сервиса, который был оговорен в Соглашении об уровне сервиса (Service Level Agreement, SLA) SLA как можно скорее [9]. В данном случае под «восстановлением сервиса» понимается: устранение технического сбоя (инцидента), выполнение запроса на обслуживание, принятие запроса на доработку функционала, устранение ошибки в работе информационной системы, чтобы пользователь смог продолжить свою работу. Service Desk, согласно сервисному подходу, является звеном, помогающим правильно организовать взаимоотношение между пользователями и ИТ-подразделением [10]. Потребность в организации Service Desk может возникнуть в следующих случаях:  пользователям удобно обращаться в единую горячую линию;  при увеличении потока обращений от пользователей появляется необходимость разделять функции специалистов;  появляется необходимость в координации совместных усилий различных ИТ-подразделений;  появляется необходимость в формировании отчетности и сборе статистики по всем обращениям, времени и качеству решений. В отличие от технических специалистов ИТ-подразделения сотрудники Service Desk ориентированы на общение с пользователями. Служба технической поддержки берет на себя решение проблемы пользователя [11]. Обращения по возникшей проблеме фиксируются, обрабатываются, хранятся и могут быть использованы для улучшения качества предоставления услуг компанией. Полученные статистические данные накапливаются для построения стратегического плана развития компании на будущее. Большинство 9 компаний, занимающиеся

предоставлением услуг в области информационных технологий, стремятся организовать службу технической поддержки, обеспечивающую единое, организованное и пользователей [12]. скоординированное Именно такой пространство операторов сервис-ориентированный и подход рекомендуется в ITIL. Преимуществами Service Desk является повышение уровня контроля за работой специалистов, так как, согласно ITIL, операторы Service Desk координируют работу специалистов, контролируют время выполнения работ, оценивают качество решения обращения специалистами на основании оценки пользователей [13]. Благодаря этому большинство компаний для увеличения производительности и повышения эффективности деятельности своего бизнеса организуют работу службы технической поддержки исходя из библиотеки передового опыта IT Infrastructure Library [14]. Одной из важнейших задач совершенствования ИТ-инфраструктуры предприятия является повышение эффективности функционирования системы управления инцидентами. Кроме этого, работа службы технической поддержки организуется при помощи разных автоматизированных систем. В первую очередь, это система распределения звонков. Звонки, поступающие в службу технической поддержки, распределяются между операторами нормировано, например, если один оператор уже принимал звонок, то следующий по очереди звонок поступает на второго оператора. При подключении автоматизированного рабочего места в телефонную линию, оператора регистрируют в автоматической телефонной станции (АТС), чаще всего организации используют АТС от фирм Cisco, Avaya, Asterisk, Infinity. Если входящие вызовы не могут быть немедленно приняты оператором, то функция приоритетной очереди помещает их в упорядоченную очередь оператора. При большом потоке обращений образуется очередь заявок на линии. Подходы по управлению процессами в ITSM реализуются с помощью ITIL, согласно которой инцидентами считаются не только ошибки 10

аппаратного или программного обеспечения, но также и запросы на обслуживание (обращения) [15]. Запрос на обслуживание (обращение) – это запрос от пользователя на поддержку, предоставление информации, не являющийся сбоем ИТ-инфраструктуры [16]. Объединяя критически важные компоненты технической поддержки в единое решение, система управления инцидентами упрощает работу пользователей и операторов службы поддержки, поднимая качество обслуживания на новый уровень. На рабочем пространстве отображаются все поступившие обращения, поставленные по обращениям задачи, доступен быстрый просмотр истории переписки специалистов, реализована возможность быстрого ответа пользователю и возможность возврата заявки на доработку. После регистрации заявки пользователю на электронную почту приходит идентификационный номер его заявки. Процесс работы над обращением прозрачен, пользователь может видеть статус своей заявки по уведомлениям, отправляемым через электронную почту, либо через портал самообслуживания. Автоматизация работы службы технической поддержки в настоящее время заключается в приеме большого количества обращений от разных источников: электронная почта, веб-формы с сайтов, прием и регистрация обращений по телефону, прием служебных записок, через личный кабинет пользователя и с помощью портала самообслуживания. Все поступившие обращения оформляются оператором в заявки. Работа с заявками осуществляется по определенному алгоритму, который в целом одинаков во всех службах технической поддержки. Суть алгоритма заключается в следующем: каждое обращение и инцидент регистрируются для того, чтобы их можно было отследить, проверить и обновить в процессе работы алгоритма. Если в базе знаний решение по возникшему инциденту есть, пользователю сообщают соответствующее решение, и на этом обработка инцидента завершается. В случае отсутствия решения по возникшему инциденту он направляется на 11

вторую линию техподдержки: назначается исполнитель – специалист, который выполняет работу по устранению инцидента. Затем специалист 1-й линии поддержки оповещает пользователя об устранении ошибки. Ожидается ответ от пользователя. В случае отрицательного результата, решение отправляется положительного на результата доработку инцидент исполнителю. А закрывается и в случае считается отработанным. На рисунке 1.1 представлена модель процесса управления инцидентами в службе технической поддержки. Рисунок 1.1 – Модель процесса управления инцидентами В системе управления инцидентами различают понятия обращения и инцидента. Обращение – это заявка в системе управления инцидентами, зарегистрированное по факту обращения пользователя в ИТ-подразделение [17]. Инцидент – это заявка о нештатной ситуации в инфраструктуре, которая привела или может привести к неработоспособности или снижению качества предоставления услуг [17]. Работу над инцидентом проводят специалисты 2й линии поддержки. При этом обращения подразделяются на категории: консультация, запрос на обслуживание, запрос на изменение, обращение не по адресу, отзыв по качеству, инцидент. Все поступившие обращения попадают в базу данных системы обработки поступивших обращений – Service Desk. Система работы с обращениями позволяет сделать поиск по 12

любым параметрам: номер обращения, статус обращения, ФИО контактного лица, адрес электронной почты, контактный телефон, категория обращения, информационная система, краткое описание, код выполнения (по времени открытия обращения, по времени выполнения обращения, по времени закрытия обращения, по лицу, по приоритету). Организация, предоставляющая первый уровень поддержки относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Help Desk, Service Desk. Процесс сфокусирован на скорейшем восстановлении прерванного сервиса. На рисунке 1.2 показан алгоритм управления инцидентами, который применяется в технической поддержке судов общей юрисдикции. Рисунок 1.2 – Алгоритм управления инцидентами 13

На входе имеется обращение пользователя в службу технической поддержки о прерванном сервисе, затем происходит подробное описание проблемы, классификация проблемы и предоставление начальной поддержки. Если в ходе предоставления начальной поддержки проблема устраняется, то инцидент закрывается. При невозможности решить проблему с помощью первой линии технической поддержки проблема направляется на вторую линию поддержки. Инженеры второй линии исследуют проблему, диагностируют неполадки и направляют на первую линию для закрытия. Если проблему не удалось решить на второй линии технической поддержки, то проблема направляется на более глубокое исследование и диагностику, а первая линия информирует об этом пользователя. Таким образом, в модели управления инцидентами на выходе имеется сообщение пользователю о восстановлении сервиса, сохраняется запись об инциденте и запись о возможной проблеме. При этом в системе накапливается статистика: количество открытых инцидентов, отсортированных по приоритету, по прошедшему времени, по рабочим группам; количество инцидентов, решенных каждой из линий поддержки; среднее время решения инцидента в рабочей группе; среднее время восстановления сервиса, процент инцидентов, решенных в рамках крайнего срока [18]. Первый уровень поддержки должен обеспечивать успешное разрешение 80% инцидентов за счет использования базы знаний, содержащей известные ошибки и способы их решения. Остальные инциденты, не найденные в базе знаний, могут быть переданы на второй уровень поддержки. При анализе эталонной модели управления инцидентами (рисунок1.1) выявлены следующие недостатки:  образование очереди на линии при большом потоке звонков (заявок); 14

 ограниченное время для консультирования и обработки обращений операторами, регистрация и классификация обращений занимает значительное время;  недостаточное количество операторов при большом потоке заявок, загруженность операторов;  неструктурированность обновление. При ориентироваться попытке в Базы знаний оказания неструктурированной и ее несвоевременное первоначальной Базе знаний поддержки по предмету консультации крайне сложно;  передача инцидента на 2-й уровень поддержки без его разрешения на 1-м уровне. В большинстве случаев, проблема маршрутизации большинства обращений на вторую линию, происходит из-за ограниченного времени на поиск ответа в неструктурированной Базе знаний. Возникновение очереди необслуженных инцидентов на 2-й линии поддержки. Большой процент направленных на 2-ю линии инцидентов – это отрицательный и крайне низкий показатель качества работы первой линии поддержки, которая должна закрывать не менее 80% всех поступающих обращений [19]. Превышение установленных сроков обслуживания инцидента в соответствии с Соглашением об уровне оказания услуг (SLA). Каждый инцидент, зарегистрированный в информационной системе управления инцидентами имеет свои сроки выполнения. В соглашении об уровне предоставления услуг (англ. Service Level Agreement (SLA)) указаны уровни качества предоставления предоставляемых услуг, услуг. сроки При восстановления управлении и время доступности инцидентами необходимо придерживаться сроков разрешения инцидента согласно срокам, указанным в Соглашении об уровне оказания услуг (SLA) [20]. 15

1.2 Анализ предметной области в рамках поставленной задачи по материалам отечественных и зарубежных публикаций Служба технической поддержки является сервисной структурой и осуществляет поддержку пользователей в ряде услуг, которые помогут устранить неполадки в работе с компьютерными аппаратными средствами, программным обеспечением. Перед службой технической поддержки ставится задача обеспечения доступности поддерживаемых информационных систем и своевременного разрешения инцидентов. Существует определенная модель решения инцидентов, но она недостаточно эффективна при поступлении большого количества заявок. В среднем, каждая 5-я заявка из числа принятых звонков не регистрируется в системе. В рамках исследования научно-исследовательской задачи представляется среднестатистические характеристики оценки системы технической поддержки, придерживаясь методологии ITIL. При управлении инцидентами большое количество заявок не обслуживаются вовремя, возникает проблема нарушения сроков разрешения инцидента. При большом потоке заявок появляются непринятые вызовы, это критично, так как пользователь обращается за помощью тогда, когда возникшая проблема имеет высокую степень значимости. Наличие проблем говорит о недостаточной степени эффективности функционирования инцидент-менеджмента и неполноценный сервис-ориентированный подход при организации инцидент-менеджмента [21]. Задачи совершенствования инцидент-менеджмента рассмотрены в работах авторов: Тушавин В. А, Иванов Д. Б., Больных А. А. и др. С точки зрения зарубежных публикаций, можно отнести сборник конференции: Lessons Learnt from the Improvement of Customer Support Processes: A Case Study on Incident Management. In: Bomarius F., Oivo M., Jaring P., Abrahamsson P. (eds) Product-Focused Software Process Improvement. PROFES 2009. Lecture Notes in Business Information Processing, vol 32. Springer, Berlin, Heidelberg. 16

Основными подходами для получения научно-исследовательского результата у перечисленных авторов являются методы теории очередей для систем массового обслуживания, генетические алгоритмы, количественные и качественные методики оценки инцидент-менеджмента. В статье обслуживания Тушавин для В. анализа А. «Применение времени теории разрешения массового инцидентов» рассматривается практический подход к управлению качеством службой технической поддержки и управления инцидентами с использованием теории массового обслуживания. Предлагается математическая модель, описывающая время разрешения инцидента [22]. Задача процесса управления инцидентами является по своей сути реактивной, поскольку подразумевает уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг. Для построения математической модели были сделаны следующие допущения: среднее время разрешения инцидента на каждой стадии одинаково, поток как входных инцидентов, так и поток между стадиями процесса является простейшим, т. е. описывается распределением Пуассона [23]. В случае, если среднее время работы описывается экспоненциальной функцией с параметром μ, а плотность потока инцидентов – λ, тогда если z – суммарное время разрешения инцидентов, а k – количество стадий, то плотность вероятности описывается функцией:  zk zk ( )k e t . p( z )  t z (k  1)! Целевое значение данной функции придерживается исходя из следующих метрик:  разрешение инцидента службой сервис-деск без эскалации должно составлять 20%; 17

 разрешение инцидентов на линии поддержки 1 должно составлять 95% от оставшихся инцидентов;  3% инцидентов должно разрешаться на линии 2 и оставшиеся инциденты – на линии поддержки 3;  среднее время разрешения инцидента на каждой стадии составляет 20 мин. Таким образом, предложенный подход данного автора позволяет специалистам, отвечающим за процесс управления инцидентами, моделировать с известной долей допущения как сам процесс, так и его под процессы, что позволяет решать задачи паллиативной оптимизации процесса, используя описанные выше шесть переменных. Анализируя текущий подход к решению проблемы данного автора можно сделать вывод, что разрыв между средним временем разрешения инцидентов на различных линиях поддержки свидетельствует о необходимости усиления контроля процесса, а возникновение избыточных переходов обращения пользователя от исполнителя к исполнителю не только приводит к необоснованному увеличению длительности работ, но и свидетельствует о недостаточной зрелости и формализации процесса. В статье А.Р. Айдинян, О.Л. Цветкова «Генетические алгоритмы распределения работ» исследуются задачи распределения неоднородных работ между неоднородными исполнителями с учетом затрат на выполнение работ и переключение между ними. Предложены генетические алгоритмы распределения работ, которые могут использоваться при решении различных практических задач как в автоматизированных процессах, так и в социальных системах [24]. Задачу предлагается решать с использованием генетического алгоритма (ГА), который представляет собой простую модель эволюции в природе, реализованную в виде компьютерной программы [25]. В нем используются как аналог механизма генетического наследования, так и аналог естественного отбора. 18

В случае одного исполнителя задача сводится к минимизации стоимости выполнения всех работ и аналогична задаче коммивояжера без необходимости возвращения в исходный пункт [25]. При этом необходимо получить такую последовательность выполнения работ, чтобы выполнялся критерий: целевая функция (функция фитнеса) определяется как ф = -F1 и наилучшей является хромосома, имеющая наибольшее значение функции фитнеса. Как известно, решение с помощью ГА сводится к последовательному выполнению следующих шагов:  выбор символьной модели объекта в виде закодированных хромосом;  генерация начальной популяции;  модификация хромосом в целях улучшения популяции;  выбор хромосомы из популяции с максимальным значением функции фитнеса [25]. Способ кодирования определяется спецификой задачи. При выборе символьной модели необходимо обеспечить возможность кодирования в хромосоме любой точки из пространства поиска. Невыполнение этого условия может привести к невозможности найти решение поставленной задачи [25]. Таким образом, анализируя основные методы авторов в рамках совершенствования системы управления инцидентами, целесообразно прийти к следующему выводу. Данные методики не конкретизируют целевую оценку и стадию выполнения заявок в системе. Не учитывается время выполнения заявки с использованием Базы Знаний решения инцидентов. Следовательно, целесообразно разработать алгоритм основанный на методиках для совершенствования службы технической поддержки. 19

1.3 Постановка задачи управления инцидентами в службе технической поддержки ГАС «Правосудие» Для проведения анализа существующей системы управления инцидентами использовались данные о работе службы технической поддержки Государственной автоматизированной системы «Правосудие» на примере Белгородской области. Государственная автоматизированная система РФ «Правосудие» (ГАС «Правосудие») – это территориально распределенная автоматизированная информационная система, предназначенная для формирования единого информационного пространства судов общей юрисдикции и системы Судебного департамента при Верховном Суде Российской Федерации [26]. Создание ГАС «Правосудие» было предусмотрено в рамках выполнения федеральной целевой программы «Развитие судебной системы России» на 2002-2006 годы, утвержденной постановлением Правительства Российской Федерации от 20 ноября 2001 г. № 805. В ней были поставлены такие задачи, как формирование единого информационного пространства, реализация конституционных принципов самостоятельности судебной власти и независимости судей, обеспечения единства судебной системы Российской Федерации, повышения эффективности деятельности судов, а также реализации прав граждан и юридических лиц на судебно-правовую информацию. Реализовать эти цели на практике должна ГАС «Правосудие» [26]. Основные цели и задачи деятельности ФГБУ ИАЦ Судебного департамента определены распоряжением Правительства Российской Федерации от 2 мая 2012 г. № 681-р и Уставом федерального государственного бюджетного учреждения «Информационно-аналитический центр поддержки ГАС “Правосудие”»: 20

 обеспечение государственной эксплуатации программно-технических автоматизированной системы средств Российской Федерации «Правосудие»;  поддержка пользователей государственной автоматизированной системы Российской Федерации «Правосудие»;  обеспечение хранения и автоматизированная обработка судебной информации (включая электронные архивы судебных дел);  интеграция информационных ресурсов и данных судебной статистики [27]. Для выявления недостатков существующей модели управления инцидентами невозможно ограничиться только описанием этого процесса, необходимо более глубокое изучение методов в управлении инцидентами. С этой целью проводился мониторинг заявок в существующей организации из системы управления инцидентами. Статистические данные собирались в течение месяца мониторинга за системой управления инцидентами. Отслеживались переходы статусов заявок, их сроки выполнения. Так как основным недостатком при анализе теоретических данных выступало большое количество пропущенных звонков и незарегистрированных заявок, а также превышение сроков выполнения заявок, то были собраны статистические данные отражающие эти показатели. Таким образом, для проведения анализа существующей системы управления инцидентами использованы данные о работе службы технической поддержки ГАС «Правосудие», состоящей из двух линий за период с 08.01.2018 г. по 02.02.2018 г.:  среднее количество пропущенных звонков из числа поступивших звонков;  количество незарегистрированных заявок из числа принятых звонков;  количество заявок закрытых с Базой знаний и без использования Базы знаний; 21

 количество выполненных заявок по линиям технической поддержки;  количество закрытых обращений с соблюдением крайних сроков. Таблица 1.1 – Среднее количество пропущенных звонков из числа поступивших звонков. Неделя № 1 Неделя № 2 Неделя № 3 Неделя №4 За весь период Поступи Поступи Поступи Поступи Поступи Пропуще Пропуще Пропуще Пропуще Пропуще ло ло ло ло ло но но но но но звонков звонков звонков звонков звонков 542 22 453 20 677 27 711 21 2383 90 Таблица 1.2. – Количество незарегистрированных заявок из числа принятых звонков. Неделя № 1 Неделя № 2 Неделя № 3 Неделя № 4 За весь период Принято Принято Не зарег. звонков звонков Не зарег. Принято Принято Не зарег. звонков звонков Не зарег. Принято Не зарег. звонков 520 109 650 59 2293 106 433 53 690 327 Таблица 1.3. – Количество заявок закрытых с Базой знаний и без использования Базы знаний. Неделя № 1 Неделя № 2 Неделя № 3 Неделя № 4 Всего за период Всего за период Без БЗ С БЗ Без БЗ С БЗ Без БЗ С БЗ Без БЗ С БЗ Без БЗ С БЗ 438 46 614 383 368 1803 122 24 22 30 Таблица 1.4. – Количество выполненных заявок по линиям технической поддержки. Неделя № 1 Неделя № 2 Неделя № 3 Неделя № 4 Всего за период Всего за период 1-я л. 2-я л. 1-я л. 2-я л. 1-я л. 2-я л. 1-я л. 2-я л. 1-я л. 2-я л. 83 401 73 565 87 318 103 295 346 1579 22

Таблица 1.5. – Количество закрытых обращений с соблюдением крайних сроков. "Да" – обращение просрочено; "Нет" – обращение не просрочено Неделя № 1 Неделя № 2 Неделя № 3 Неделя № 4 Да 3 Да 15 Да 4 Да 18 Нет 481 Проблемы Нет 623 Нет 401 существующей модели Нет 380 Открытые обращения на конец периода Да Нет 106 667 управления Всего за период Да 146 Нет 2552 инцидентами подтверждены статистикой, показанной в диаграммах, составленных из таблиц. На рисунке 1.3 к таблице 1.1 указано среднее количество пропущенных звонков из числа поступивших звонков. При большом потоке заявок возникает образование очереди на линии, у операторов ограниченное время обработки обращений и консультирования. Очередь на телефонной линии может привести к увеличению количества пропущенных звонков. Рисунок 1.3 – Среднее кол-во пропущенных звонков из числа поступивших 23

На рисунке 1.4 к таблице 1.2 приведено количество незарегистрированных заявок из числа принятых звонков. Рисунок 1.4 – Количество незарегистрированных заявок из принятых Причиной незарегистрированных заявок является ограниченное время обработки обращений у оператора и ограниченное количество линий обработки заявок, в результате заявка, поступившая в систему, когда все операторы заняты, может получить отказ в обслуживании. На рисунке 1.5 к таблице 1.3 представлено соотношение доли заявок закрытых с использованием Базы знаний и без использования. Из-за не структурированности Базы знаний получается низкий процент закрытия обращений первой линией, низкий процент использования Базы знаний. 24

Рисунок 1.5 – Количество заявок закрытых с использованием Базы знаний На рисунке 1.6 к таблице 1.4 отображено количество выполненных заявок по линиям технической поддержки. Из-за нехватки времени и сложного поиска ответа в Базе знаний была выявлена проблема маршрутизации большинства обращений на вторую линию, что отрицательно сказывается на качестве работы первой линии поддержки, которая должна закрывать 80% всех поступающих обращений. По диаграмме 4 к таблице 4 видно, что первая линия закрывает максимум заявок (25%), поступающих в службу технической поддержки. 25

Рисунок 1.6 – Кол-во выполненных заявок по линиям тех. поддержки Из-за обращений того, на что вторую первая линию, линия то маршрутизирует возникают большинство просрочки, которые представлены на рисунке 1.7 к таблице 1.5. Основным показателем эффективной работы первой линии технической поддержки является успешное разрешение 80% инцидентов на первой линии за счет использования базы знаний, а также снижение количества пропущенных звонков и незарегистрированных инцидентов [27]. 26

Рисунок 1.7 – Кол-во закрытых обращений с соблюдением крайних сроков Для проведения точного анализа взяты результаты работы службы технической поддержки, которые показали, что среднее количество пропущенных звонков из числа поступивших звонков составляет 3,77%, количество незарегистрированных заявок из числа принятых звонков – 5,7%, а количество заявок, у которых истек срок выполнения – 81%. Таким образом, были выявлены недостатки существующей модели, которые необходимо устранить. С этой целью во втором разделе магистерской диссертации разработаны предложения по повышению эффективности управления инцидентами, выявленные недостатки. 27 позволяющие устранить

2 ИССЛЕДОВАНИЕ МЕТОДОВ И РАЗРАБОТКА АЛГОРИТМОВ ДЛЯ ОПТИМИЗАЦИИ ПРОЦЕССА ОБРАБОТКИ ЗАЯВОК В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ 2.1 Исследование основных типов инцидентов службы технической поддержки ГАС «Правосудие» и их классификация «Информационно-аналитический центр поддержки ГАС «Правосудие» был учрежден Судебным департаментом при Верховном Суде Российской Федерации – государственным органом, осуществляющим организационное обеспечение деятельности судов общей юрисдикции, органов судейского сообщества, финансирование мировых судей, а также материально-техническим внедрению в обеспечением деятельность судов судов, их информационных информатизацию, технологий и формирование единого информационного пространства федеральных судов общей юрисдикции и мировых судей [29]. В предыдущем разделе были описаны основные цели и задачи деятельности ФГБУ ИАЦ Судебного департамента. Проведем структурирование задач для выявления основных типов инцидентов происходящих в работе технической поддержки судов общей юрисдикции. Перечислим основные задачи, которые стоят перед ФГБУ ИАЦ Судебного департамента для обеспечения эксплуатации обеспечение эксплуатации программно-технических средств (ПТС) ГАС «Правосудие» [28]:  поддержка эксплуатации программного обеспечения на объектах автоматизации ГАС «Правосудие». Установка общего и специального программного обеспечения по заявкам объектов автоматизации;  централизованное администрирование ПТС подсистемы связи и передачи данных ГАС «Правосудие» и ПТС ведомственной телефонной сети; 28

 восстановление и обеспечение функционирования средств автоматизации и ПТС на объектах автоматизации ГАС «Правосудие»;  обновление специального программного обеспечения ГАС «Правосудие»;  актуализация (модификация) комплекса средств автоматизации ГАС «Правосудие», ввод в действие комплекса средств автоматизации ГАС «Правосудие». Следующими задачами по организации и обеспечению постоянной технической поддержки специального программного обеспечения ГАС «Правосудие» являются:  предоставление с использованием каналов электронной связи консультаций и письменных разъяснений по проблемам, возникающим на объектах автоматизации при эксплуатации программно-технических средств ГАС «Правосудие»;  осуществление мониторинга состояния и функционирования программно-технических ГАС «Правосудие»;  разработка изменений (патчей) специального программного обеспечения ГАС «Правосудие» под изменившиеся в процессе эксплуатации требования, их протоколирование и публикация на Интернет-портале ГАС «Правосудие»;  восстановление баз данных специального программного обеспечения ГАС «Правосудие». Проанализировав основные задачи по обеспечению технической поддержки ГАС «Правосудие», можно выделить основные виды инцидентов, которые требуют оптимизации их обработки и разработки нового алгоритма усовершенствование сервиса ITIL. Сгруппируем типы заявок, возникающих в сервисе технической поддержки следующим образом:  распределение «Правосудие», проектов: проведение проектов обучение по пользователей улучшению программного обеспечения и усовершенствования деятельности в судебной системе; 29 ГАС

 ремонт: дооснащение средствами автоматизации и ремонт программно-технических средств комплекса средств автоматизации;  сервисные заявки: установка и обновление общего и специального программного обеспечения по заявкам объектов автоматизации, устранение нештатных ситуаций, возникающих в подсистемах ГАС «Правосудие». Приведя основные положения, можно перейти к анализу применимости математических методов к описанным типам заявок. Для задач выполнения инцидентов по установке, обновлению и устранения нештатных ситуаций целесообразно применять методику, основанную на теории очередей в системах массового обслуживания. Проведение проектов по улучшению программного обеспечения и усовершенствования деятельности в судебной системе, а также обучение пользователей ГАС «Правосудие» целесообразно применять методику в области математической оптимизации – задача о назначениях (венгерский алгоритм). Задача об оптимальной замене оборудования эффективна для мероприятий по ремонту программно-технических средств комплекса средств автоматизации и дооснащения средствами автоматизации. 2.2 Математические методы исследования возможностей оптимизации процесса обработки инцидентов 2.2.1 Моделирование процесса обработки поступающих заявок средствами теории очередей В настоящее время актуальной задачей является поддержание функционирования информационной системы организации на заданном уровне эффективности. При достаточно большом потоке заявок связанным с ухудшением характеристик функционирования информационной системы возникает необходимость оперативного реагирования на заявки пользователей с целью минимизации их потерь [31]. Один из подходов для 30

решения поставленной задачи связан с применением рекомендаций ITIL в системе управления службы технической поддержки, которые позволяют существенно уменьшить время реакции на поступающие заявки от реальных пользователей за счет автоматизации процесса учета и обработки их обращений [32]. В основе построения математической модели обработки поступающих заявок целесообразно использовать математический аппарат теории очередей [33]. Для решения поставленной задачи систему управления службы технической поддержки можно представить, как многоканальную систему массового обслуживания с отказами, которая позволит оценить такие характеристики как среднее число занятых каналов в текущий момент времени и вероятность отказа в обслуживании, которые в свою очередь позволят обосновать решения по совершенствованию системы управления службы технической поддержки [34]. Граф состояний системы технической поддержки представлен на рисунке 2.1, где:  – интенсивность входящих заявок;  – интенсивность обработки заявок; n – число состояний; Si – состояния системы технической поддержки, когда в ней находится i заявок. Рисунок 2.1– Граф состояния системы технической поддержки Представленный граф позволяет решить задачу расчета вероятностей переходов из состояния Sk в соседнее Sk−1. 31

Входящий поток заявок является простейшим с интенсивностью, поэтому переход из состояния Si в Si+1 происходит с одной и той же интенсивностью [35]. Переходы из состояния Sk в соседнее Sk−1 происходит с интенсивностью k (кратное количеству занятых каналов). На основе распределения Эрланга вычисляется вероятность отказа p0, когда система находится в состоянии S0, и вероятность отказа pi, когда система находится в состоянии Si:   2 3 n p0   1     ...   2  2 3!  3 n!  n  pi  i i!  i  p0     1 , (2.1) i  1,2,..., n , (2.2)  Если отношение  обозначить через , то получим:  2  n  p0   1     ..  2! n!   1 ; pi  i i!  0 , i  1,2,..., n (2.3) Величина  определяет среднее число заявок, приходящих за среднее время обслуживания одной заявки. Ее называют коэффициентом загрузки системы [36]. Вычислим вероятность отказа системы управления службы технической поддержки в обслуживании заявки: Pотк  pn  n n!  p0 , (2.4) В результате можно найти среднее число занятых каналов в текущий момент времени по формуле (5):   n  k     1  p0     n!  , A (2.5) где k среднее число занятых каналов в текущий момент времени; n – число каналов связи. 32

Полученные значения k и Pотк позволяют оценить эффективность функционирования системы управления службой технической поддержки и выработать обоснованные решения по ее совершенствованию. Так же существенными показателями эффективности СМО, являются абсолютная и относительная пропускная способность обслуженных и пришедших заявок в техподдержку. Данные показатели рассчитываются по следующим формулам: Q  1  Pотк  1  n n! p0 , (2.6)   n А    Q    1  p0  ,   n!   (2.7) где A – абсолютная пропускная способность СМО, представленная в виде среднего числа заявок, обслуживаемых в единицу времени; Q – относительная пропускная способность, представленной в виде средней доли пришедших заявок, распределенных на первой линии техподдержки. Описанная математическая модель апробирована на исходных данных отдела технической совершенствования поддержки будут ГАС представлены «Правосудие», в программной способы ее реализации. Получение искомого решения обеспечивается за сравнительно небольшое число шагов и не требует больших временных затрат и вычислительных ресурсов. 2.2.2 Моделирование задач по критерию назначения работ Проведение проектов по улучшению программного обеспечения и выполнение задач, в котором задействовано несколько инженеров, а также в обучение пользователей ГАС «Правосудие» целесообразно применять методы математического программирования, используемые в задачах о назначениях, реализуемые так называемым 33 венгерским алгоритмом.

Общепринято, что данная методика нацелена на оптимальное решение, а именно на максимальный или минимальный результат и является частным случаем более общей транспортной задачи [37]. Опишем основные критерии решения данной задачи. Если число исполнителей равно числу выполняемых работ, то такая задача является сбалансированной, в противном случае – не сбалансированной. В случае сбалансированной задачи о назначениях выполняются два условия: каждый исполнитель выполняет только одну работу и каждая работа выполняется только одним исполнителем. Для решения сбалансированной задачи о назначениях можно предложить следующий простой алгоритм: на каждом шаге назначений, начиная с первого исполнителя, выбирать самого эффективного (неэффективного) [38]. Однако такой способ решения, при всей кажущейся очевидности, не приводит, как правило, к получению оптимального решения: выбор на первых шагах самых эффективных (неэффективных) исполнителей заставляет нас на последних шагах алгоритма выполнять назначения, которые вносят негативный вклад в суммарный критерий [39]. В общем случае смысл задачи о назначениях заключается в следующем: как наилучшим способом назначить n исполнителей для выполнения n различных работ. При этом считается, что квалификация каждого исполнителя позволяет выполнить практически любой вид работ, правда с различной производительностью (или за разное время, с разными затратами), и каждый исполнитель может быть назначен для выполнения одной конкретной работы. Цель назначений зависит от реальной ситуации [40]. В нашем случае решается задача о нахождении наименьшего общего времени выполнения всех работ, а именно выполнение проектов или проведение обучения. Пусть т – количество работ. При рассмотрении задачи о назначениях в стандартной форме предполагается, что количество исполнителей равно количеству работ. Представим следующие обозначения, допустимые при типовом решении 34

задачи:  сij – показатель эффективности назначения i-го инженера на j-й работе, например издержки выполнения i-м инженер j-й работы;  xij – переменная модели (хij = 1, если i-й инженер используется на jй работе, и xij = 0 в противном случае). Математическая модель задачи о назначениях представлена в следующем виде: m ∑m j=1 ∑i=1 cij xij → min , (2.8)  m   x ij  1,i  1 j...,m,  i 1  m   x ij  1,j  1 j...,m,  j 1 x  0,i  1,...,m;j  1,...,m  ij  (2.9) где (2.8) – целевая функция (минимум издержек на выполнение всех работ); (2.9) – система ограничений, отражающая следующие условия: а) каждая работа должна быть выполнена одним инженером; б) каждый инженер может быть привлечен к одной работе; в) условия неотрицательности переменных. При решении задачи о назначениях исходной информацией является таблица задачи о назначениях с={сij}, элементами которой служат показатели эффективности назначений [40]. Для задачи о назначениях, записанной в стандартной форме, количество строк этой таблицы совпадает с количеством столбцов: 35

работа 1 2 … j … m 𝑐11 𝑐12 … 𝑐1𝑗 … 𝑐1𝑚 2 𝑐11 𝑐22 … 𝑐2𝑗 … 𝑐2𝑚 … … … … … … … i 𝑐𝑖1 𝑐𝑖2 … 𝑐𝑖𝑗 … 𝑐𝑖𝑚 … … … … … … … m 𝑐𝑚1 𝑐𝑚2 … 𝑐𝑚𝑗 … 𝑐𝑚𝑚 инженер 1 Результатом решения задачи о назначениях (2.8) – (2.9) является вектор х* = { x * }, компоненты которого – целые числа. ij Оптимальный план задачи о назначениях (2.8) - (2.9) можно представить в виде квадратной матрицы назначений, в каждой строке и в каждом столбце которой находится ровно одна единица. Такую матрицу иногда называют матрицей перестановок. Значение целевой функции (2.9), соответствующее оптимальному плану, называют эффективностью назначений. Конечно, задача о назначении может быть решена симплекс-методом или любым алгоритмом решения транспортных задач [41]. Но ее специфичность позволяет использовать специальный алгоритм, который носит название венгерского метода и сразу, же позволяет получить оптимальное решение. Алгоритм метода содержит следующие шаги [42]: Шаг 1. Получение нулей в каждой строке. Для этого в каждой строке определяют наименьший элемент, и его значение отнимают от всех элементов этой строки. Переход к шагу 2. Шаг 2. Получение нулей в каждом столбце. В преобразованной таблице в каждом столбце определяют минимальный элемент, и его значение вычитают из всех элементов этого столбца. Переход к шагу 3. 36

Шаг 3. Поиск оптимального решения. Просматривают строку, содержащую наименьшее число нулей. Отмечают один из нулей этой строки и зачеркивают все остальные нули этой строки и того столбца, в котором находится отмеченный нуль. Аналогичные операции последовательно проводят для всех строк. Если назначение, которое получено при всех отмеченных нулях, является полным (т.е. число отмеченных нулей равно n), то решение является оптимальным, в противном случае следует переходить к шагу 4. Шаг 4. Поиск минимального набора строк и столбцов содержащих все нули. Для этого необходимо отметить: 1) все строки в которых не имеется ни одного отмеченного нуля; 2) все столбцы, содержащие перечеркнутый нуль хотя бы в одной из отмеченных строк; 3) все строки, содержащие отмеченные нули хотя бы в одном из отмеченных столбцов. Действия 2) и 3) повторяются поочередно до тех пор, пока есть что отмечать. После этого необходимо зачеркнуть каждую непомеченную строку и каждый помеченный столбец. Цель этого шага – провести минимальное число горизонтальных и вертикальных прямых, пересекающих, по крайней мере один раз все нули. Шаг 5. Перестановка некоторых нулей. Взять наименьшее число из тех клеток, через которые проведены прямые. Вычесть его из каждого числа, стоящего в невычеркнутых столбцах и прибавить к каждому числу, стоящему в вычеркнутых строках. Эта операция не изменяет оптимального решения, после чего весь цикл расчета повторить, начиная с шага 3. Результат полученный по венгерскому методу, не изменится, если в алгоритме заменить строки на столбцы, и наоборот [43]. Таким образом, применяя данный метод можно оптимально прийти к минимальным затратам для выполнения тех или иных задач, представленным от руководства. 37

2.2.3 Моделирование задачи об оптимальной замене оборудования Ежегодно технической поддержке выделяются денежные средства и оборудование, находящееся в подменном фонде для замены, в случае критичного состояния баз данных судебного делопроизводства или выхода из строя техники. Одной из распространенных и важных задач оптимального планирования в экономике является задача определения наиболее эффективной стратегии замены действующего оборудования на новое [44]. В качестве оборудования в рамках предметной области рассматривается компьютерная техника. С течением времени в процессе эксплуатации любое оборудование стареет – происходит его физический и моральный износ. При этом возрастают финансовые и временные затраты на его ремонт и обслуживание, а вместе с этим снижается производительность оборудования и так называемая ликвидная стоимость [45]. Настает момент, когда эксплуатационные затраты для действующего оборудования вырастают настолько, что его выгоднее продать и заменить новым оборудованием, хотя, конечно, приобретение его связано с некоторыми, как правило, значительными затратами. В связи с изложенными обстоятельствами возникает задача об определении оптимального с точки зрения выбранного критерия срока замены оборудования. В качестве такого критерия обычно принимают либо суммарную прибыль, полученную при реализации производственного или иного процесса на старом и новом оборудовании (с учетом затрат и на эксплуатацию старого оборудования и на приобретение нового), либо суммарные затраты на эксплуатацию оборудования в течение определенного промежутка времени [46]. Заметим, что замена оборудования может состоять в приобретении оборудования того же вида, что и старое (естественно, без износа или с меньшим износом), либо нового более совершенного. 38

Рассмотрим далее изложенную задачу в более узкой и конкретной формулировке. Рассматривается плановый промежуток времени, состоящий из n лет. Вопрос о замене оборудования на новое или сохранении действующего оборудования рассматривается в начале каждого года. Известны следующие исходные условия:  зависимость производительности оборудования от времени эксплуатации (со временем она уменьшается);  зависимость затрат на содержание, эксплуатацию и ремонт этого оборудования от времени (они со временем увеличиваются);  величина затрат на приобретение, установку (монтаж) и запуск в эксплуатацию нового оборудования;  заменяемое старое оборудование списывается (не продается). Требуется составить план замены оборудования, при котором общая прибыль, получаемая при эксплуатации оборудования за n лет, была бы максимальна. Для получения математической модели этой задачи введем следующие обозначения:  t – текущее время в плановом периоде; решение о замене или сохранении оборудования принимается в моменты времени t=0; 1; 2;....; n-1;  τ – возраст оборудования; τ∈{0, 1, 2,...}; τ = 0 соответствует использованию нового оборудования, τ = 1 соответствует эксплуатации оборудования с возрастом 1 год и более;  r = r (τ) – производительность оборудования – годовой выпуск продукции (объем выпускаемой продукции или объем проданных товаров, оказанных услуг) в стоимостном выражении для оборудования возраста τ;  z = z (τ) – эксплуатационные затраты, т.е. затраты на обслуживание и ремонт, которые приходится осуществлять в течение одного года для оборудования, имеющего возраст τ;  p = p0 – стоимость нового оборудования. 39

В рассматриваемом оборудование, случае управлением – управляемой решение о системой сохранении является или замене оборудования [47]. Если это управление обозначить переменной x , то она будет принимать два значения:  x  xс  x 1 з   x2  x  сохранить действующе е оборудование; (2.10)  заменитьоборудование на новое. В качестве состояния этой системы будем рассматривать возраст оборудования: s = τ . Для получения уравнения состояний рассмотрим i-й год планового периода. Пусть к началу этого года оборудование подошло имея возраст τ, тогда в случае принятия решения о его сохранении к следующему моменту рассмотрения это оборудование станет на год старше s (i)= τ +1. Если же оборудование будет заменено на новое, то по истечении рассматриваемого промежутка времени (одного года) его возраст будет равен s(i) = 1. Таким образом, получаем следующее уравнение состояния:   1 при x  x c , s(i  1)      s(i)   X  X (I )  1 при x  x з . (2.11) Рассмотрим теперь величину критерия эффективности использования оборудования, т.е. принятия решений о сохранении действующего оборудования или его замене на новое в течение пятилетки. Следуя (2.12), примем в качестве этого критерия следующий показатель: 5 Y  y , i 1 i (2.12) где  r ( )  z ( ), если x  x c  оборудование сохраняетс я;  i i i y (i )   з  оборудование заменяется . r (0)  z (0)  p, если x  x i  Заметим, что этот показатель интерпретируют как общую прибыль от эксплуатации оборудования в течение пятилетки либо суммарный доход 40

(2.12), хотя в действительности это не соответствует общепринятым в экономике понятиям прибыли и дохода. Функциональное рекуррентное уравнение Беллмана (2.13) в данном случае принимает вид: r ( )  z ( )  Y * (  1),  k k 1 k Y * ( , x )  max  k k k k x  r (0)  x(0)  Y * (1). k  k 1 (2.13) Функции r(τ) и z(τ) определяют производительность оборудования и эксплуатационные затраты, а затраты, связанные с приобретением и установкой нового списывается [47]. оборудования, Таким причем образом, заменяемое предлагаемая оборудование постановка задачи определения оптимальных сроков замены и подход, позволяет решить задачу выбора оптимальной стратегии замены производственных активов предприятия, придерживаясь минимальных затрат. 2.3 Разработка алгоритмов для оптимизации процесса обработки заявок в службе технической поддержки Проанализировав основные подходы и методы необходимые для модернизации процесса обработки заявок в службе технической поддержки, следующим шагом является разработка алгоритмов. Совершенствование алгоритма направлено для расчета минимального количества каналов обработки заявок, а так же учитывает основные задачи, решаемые в деятельности ИТ-подразделения судов общей юрисдикции [48]. На рисунке 2.2 представлен усовершенствованный алгоритм управления инцидентами в службе технической поддержки информационной системы ГАС «Правосудие». 41

Рисунок 2.2 – Алгоритм совершенствования системы управления инцидентами 42

На входе имеется обращение пользователя в службу технической поддержки о прерванном сервисе, затем производится расчет оптимального количества каналов связи с учетом ограничений [49]. Приведем детализацию функции «Расчет оптимального количества каналов связи (СМО)». Расчет будет производиться по следующему алгоритму: 1) задаются исходные данные: интенсивность потока заявок λ, среднее время обслуживания одной заявки tобс, интенсивность обработки заявок μ, вероятность отказа в обслуживании p0 , среднее число заявок, приходящих за среднее время обслуживания одной заявки ρ. Выбирается начальное количество каналов обработки заявок N=1; 2) производится расчет значения вероятности отказа в обслуживании pотк для различного числа каналов обработки заявок n; 3) осуществляется проверка соответствия заданным ограничениям: вероятность отказа в обслуживании должна быть менее 1%. Требуется обслужить максимальное число заявок за время не более 5 минут. Необходимо найти минимальное количество каналов обработки заявок, Nmin при котором будут выполняться введенные ограничения. Если Nmin удовлетворяет требованиям, то работа алгоритма завершается. Нахождение Nmin позволит организовать такое количество каналов обработки заявок, при котором поток заявок будет обслуживаться с вероятностью отказа в обслуживании в 1%. Грамотная организация проводимости заявок в систему значительно повышает показатели работы службы технической поддержки (рисунок 2.3). 43

Рисунок 2.3 – Алгоритм расчета оптимального количества каналов связи На следующем шаге производится первичная регистрация обращения на 1-й линии классифицируют в системе инцидент, управления задают инцидентами, приоритет – операторы степень срочности (важности). В случае если инцидент классифицируется как задача о распределении работ или проектов между сотрудниками, выполняется 44

функция «Распределение работ». Алгоритм данной задачи представлен в приложении А. Если инцидент связан с ремонтом оборудования или заменой составляющих ПТС, целесообразно применить функцию «Ремонт». После классификации и оценки приоритетности инцидента, предоставляется первоначальная поддержка пользователю. Осуществляется поиск решения в актуализированной Базе знаний, при нахождении решения пользователю оказывают консультацию [50]. Актуализация Базы знаний осуществляется ведущими специалистами 1-й линии поддержки, это можно классифицировать как дополнительная линия поддержки, в которой определенная группа инженеров систематизируют базу знаний инцидентов по типовым решениям. При отсутствии решения в Базе знаний специалисты передают инцидент на 2-ю линию поддержки. Дополнительная линия поддержки не требует дополнительных специалистов извне. Она организуется после расчета оптимального количества каналов обработки заявок с учетом ограничений. После нахождения Nmin, часть специалистов 1-й линии, которая выделена с этого момента как дополнительная линия (не принимает входящий поток звонков) занимается исходящими звонками, а также консультированием пользователей по Базе прецедентов [51]. В случае отсутствия решения в Базе знаний инцидент передается специалистам 2-й линии поддержки. Необходимо отметить, что на 2-ю линию поддержки пользователи не имеют доступа. Телефонный контакт с пользователями только у специалистов первой линии (входящие звонки) и дополнительной линии (исходящие звонки). Специалисты 2-й линии проводят диагностику состояния сервиса и при необходимости занимаются восстановление сервиса. Дополнительной специалисты 2-й линии следят за обновлением, дополнением Базы знаний и Базы прецедентов необходимыми, актуальными решениями. После восстановления сервиса инциденты возвращаются специалистам 1-й линии. Специалисты 1-й линии информируют пользователя о проведенных работах. 45

А дополнительная линия поддержки в данном случае следит за сроками разрешения инцидентов. Если специалист 2-й линии, на которого был переведен инцидент, не взял в работу заявку, то посылается информирование о необходимости решить инцидент до определенного времени. Специалистами 3-й линии являются разработчики программноаппаратного комплекса, в которой произошел тот или иной инцидент. На каждой линии поддержки осуществляется обзвон выполненных заявок с целью согласования выполнения инцидента [52]. Обратная связь с пользователем. Данный подход предполагает использование разработанного в магистерской диссертации алгоритма управления инцидентами, который показывает введение дополнительной линии поддержки за счет распределения задач 1-й линии, разгрузки обязанностей 2-й линии. Организация дополнительной линии поддержки, которая разделяет обязанности операторов, повышает показатели эффективности службы технической поддержки. Таким образом, в данном разделе было проведено исследование методов и разработаны алгоритмы совершенствования процесса обработки заявок в службе технической поддержки. На основании деятельности филиала ФГБУ ИАЦ Судебного департамента структурированы и классифицированы задачи решаемые в технической поддержки ГАС «Правосудие». Исследованы математические методы необходимые для оптимизации процесса обработки инцидентов. На основании рассмотренных математических моделей разработаны системы технической поддержки. 46 алгоритмы совершенствования

3 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ АЛГОРИТМОВ ОБРАБОТКИ ИНЦИДЕНТОВ В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ СУДОВ ОБЩЕЙ ЮРИСДИКЦИИ 3.1 Программная реализация и апробация алгоритмов обработки инцидентов в службе технической поддержки На сегодняшний день на рынке представлены несколько десятков программ для учета инцидентов, возникающих в учреждении которые связанны с информатизацией. Несмотря на общую направленность, программы сильно различаются функционально [53]. В информационноаналитическом центре поддержки ГАС «Правосудие» фиксируют все инциденты и заявки на обслуживание в информационной системе «1С:ITIL Управление информационными технологиями предприятия СТАНДАРТ». Конфигурация «1С:ITIL Управление информационными технологиями предприятия СТАНДАРТ» – это универсальная система для службы Service Desk (службы технической поддержки), простая в настройке и использовании. Она предназначена для ИТ-подразделений организаций и сервисных компаний. Система разработана на основе библиотеки ITIL v3 (IT Infrastructure Library - библиотека передового опыта в области управления ИТ) [54]. Программное приложение помогает эффективно с минимальными затратами управлять работой службы технической поддержки, организовать управление обращениями клиентов, сформировать каталог сервисов и соглашений об уровне сервиса, вести учет оборудования и программного обеспечения [55]. «1C:ITIL» – совместное решение фирмы «1С» и компании «1С-Рарус». Основные функциональные возможности:  управление службой поддержки (SERVICE DESK);  управление уровнем сервиса; 47

 управление активами;  импорт данных WMI, Everest;  инструменты сбора информации об оборудовании следующими средствами Windows Management Instrumentation (WMI), а также импорт данных из программы Everest;  импорт пользователей AD; импорт информации по учетным записям пользователей домена из Active Directory (AD);  работа с торговым оборудованием. Функционал системы доступен в тонком клиенте и веб-клиенте. Для работы с программой выделены категории пользователей, которые наделены ограниченным функционалом подсистемы. Представим работоспособность системы на основе прав пользователя «Администратор». При входе в систему появляется окно выбора того пользователя, под которым происходит вход в систему. Для этого необходимо ввести пароль и пройти права доступа (рисунок 3.1). Рисунок 3.1 – Вход в подсистему После входа в подсистему появляется главное окно для начала работы. Пример рабочего стола представлен на рисунке 3.2. Здесь представлены все задачи (заявки), технической поддержки. 48 поступающие для обеспечения

Рисунок 3.2 – Рабочий стол подсистемы В модуле «Service представлен Desk» перечень заявок от пользователей объектов автоматизации, причем при входе в систему для каждого инженера распределены текущие заявки на выполнение. Для представления текущей возможности зашли в подсистему под сотрудником технической поддержки (рисунок 3.3). Рисунок 3.3 – Интерфейс подсистемы пользователя тех. поддержки 49

В целях тестирования программного продукта, в данной работе приводится тестовая информация (в соответствии законодательной базой Российской Федерации). Проведем пошагово апробацию разработанного алгоритма по совершенствованию процесса обработки заявок в службе технической поддержки. На входе имеется обращение пользователя в службу технической поддержки о прерванном сервисе. Существуют следующие способы обращения пользователя в техническую поддержку:  по телефону;  с обращением на бумажном носителе (официальное письмо, заверенное председателем суда);  по электронной почте (при необходимости обращение направляется с вложением/прикреплением);  web-форму информационной системы по регистрации заявки;  через систему документооборота (СЭД). Документ соответствует формату, установленному внутренними регламентирующими документами. Рассмотрим способ обращения по телефону, так как большинство заявок поступает по звонку от пользователя. После поступления заявки и регистрации ее на горячей линии формируется классификация и расчет оптимального количества каналов связи для распределения выполнения заявки инженеру технической поддержки. Следующим шагом является расчет оптимального количества каналов связи для распределения выполнения заявки инженеру технической поддержки. Формальная постановка задачи представляется в следующем виде: N → min. При ограничениях: Pотк < 0,01; tсист. ≤ 5. Необходимо найти минимально допустимое количество каналов обработки заявок при заданных ограничениях: вероятность отказа в обслуживании должна быть менее 0,01, а среднее время обработки заявки не более 5. Для решения поставленной задачи систему управления службы технической поддержки (СУСТП) можно представить, как многоканальную 50

систему массового обслуживания с отказами, которая позволит оценить такие характеристики как среднее число занятых каналов в текущий момент времени и вероятность отказа в обслуживании, которые в свою очередь позволят обосновать решения по совершенствованию СУСТП. Рассмотрим решение поставленной задачи с использованием заданного набора исходных данных. Имеется служба технической поддержки (СТП), которая может быть представлена как несколько автоматизированных рабочих мест с телефонной линией. Всего таких линий 5 (соответственно, число каналов N = 5). Если заявка приходит в момент, когда все каналы заняты, то она получает отказ. Интенсивность потока заявок λ = 0,7 заявки, среднее время обслуживания одной заявки tобс = 3,4 мин. На основании предоставленных данных следует определить число каналов, необходимых для обслуживания не менее 99% поступающих заявок. Формально обозначим поступление заявок через S0, S1, S2, S3, S4, S5 −состояния СМО СТП:  S0 − в системе все каналы свободны;  S1 − один канал занят, 4 – свободны;  S2 − два канала заняты, 3 – свободны;  S3 − три канала заняты, 2 – свободны;  S4 − четыре канала заняты, 1 – свободен;  S5 − пять каналов заняты;  следующая заявка, поступившая в СМО, получает отказ. Из условия задачи известно: λ = 0,7; tобс =3,4 мин.; μ = 1 ∙ tобс = 13,4 = 0,29. ρ = 0,7 ∙ 3,4 = 2,38. Найдем необходимые значения вероятности отказа в обслуживании в состояниях S0 ÷ S5: p0 = 1 + 2.38 + 2.3822! + 2.3833! + 2.3844! + 2.3855! – 1 = 0.096. pi  p0  i !, i  1,2,3,4,5 , в соответствии с представленной формулой произведем расчёт для каждого канала связи: 51

 p1 = 0,096 ∙ 2,3811! = 0,228;  p2 = 0,096 ∙ 2,3822! = 0,271;  p3 = 0,096 ∙ 2,3833! = 0,215;  p4 = 0,096 ∙ 2,3844! = 0,128;  p5 = 0,096 ∙ 2,3855! = 0,06100. Тогда Pотк = p5 = 0,061. Это означает, что в 6 % пользователей получат отказ. Результаты расчетов позволяют сделать вывод, что при достаточно высокой вероятности отказа в обслуживании, загруженность каналов обработки заявок составляет около 45%. Так как по условию можно менять лишь один параметр (число каналов), то задавая значения n = 6 и n = 7 получим значения для Pотк: p6=0,096 ∙ 2,3846! = 0,023 p7=0,096 ∙ 2,3857! = 0,008 Pотк.(p6) ≈ 2%. Pотк.(p7) ≈ 1%. Следовательно, для того чтобы выполнялось неравенство: Pотк < 0,01, достаточно использовать 7 каналов, тогда всего 1% пользователей получат отказ. Таким образом, найдено минимальное допустимое количество каналов обработки заявок Nmin = 7. Отсюда следует вывод, что если вероятность отказа в обслуживании меньше 0,01, т.е. обслуживаются не менее 99% поступающих заявок, то всего на рабочую 1-й линии технической поддержки необходимо выделить 7 инженеров. В случае предоставления пользователем неполной или некорректной информации по контактным данным и/или ключевой информации по сути обращения, то инженер должен дополнительно запросить ее у пользователя в текущем разговоре и заполнить форму заявки. В форме заявки идут такие поля как:  контактное лицо;  название и адрес организации;  контактные данные (телефон, электронная почта);  способ обратной связи (телефон, электронная почта); 52

 суть проблемы;  название системы или оборудования, с которым связана проблема (с указанием модели, марки оборудования и прочих данных). После уточнения всех вышеуказанных данных инженер занимается классификацией и направлением заявки. При этом заполняются в заявке такие данные как:  категория заявки (проектное сопровождение, консультация, запрос на обслуживание, запрос на изменение, отзыв по качеству, не по адресу);  направление (заполняется в соответствии с тематикой вопроса);  вид услуги;  приоритет заявки (критический, высокий, средний, низкий);  срок, отведенный на решение заявки согласно SLA. После проведение классификации инцидента, в случае если категория заявки является проведение мероприятий, проектов по улучшению программного обеспечения и усовершенствования деятельности в судебной системе, а также обучение пользователей ГАС «Правосудие», для назначения этих задач целесообразно рассчитать распределение с помощью метода задача о назначениях. Рассмотрим данный метод путем проведения распределения через программную реализацию, которое было разработано с использованием программной среды C++ Visual Studio [56]. Постановка задачи заключается в следующем: технической поддержке ГАС «Правосудие» необходимо провести установку системы видео-конференц-связи в областном суде, для этого данную задачу разделим на четыре этапа:  монтаж и стационарная настройка системы видео-конференц- связи в зале судебного заседания;  администрирование ведомственного канала связи;  проведение тестового судебного заседания между областным судом и следственным изолятором; 53

 обучение секретарей судебного процесса по эксплуатации системы. Выходные результаты первой задачи являются входными данными для второй задачи, выходные результаты второй задачи − это входные данные для третьей задачи, результаты третьей задачи используются для работы над четвертой задачи (таким образом задачи нельзя выполнять параллельно). В качестве инженерного состава для решения задач рассматриваются кандидатуры четырех инженеров, обладающих различным опытом и способностями. Каждый инженер оценил время, необходимое для реализации каждого мероприятия. Матрица времени в часовом эквиваленте имеет следующий вид: 3 2 Т  4  9 7 5 8 4 4 5 ; 7 2 8  7 3 8 На пересечении i-й строки и j-го столбца матрицы Т стоит время, необходимое i-м инженеру j-го задачи. Требуется выбрать сотрудников так, чтобы суммарное время выполнения всех задач было минимальным. 1, если i  й инженер j  ой задачи, 0, в противном случае.  Пусть хij=  (3.1) Тогда целевая функция имеет вид: z=  tij xij →min, tij − элементы матрицы Т. i, j Проведем подробное описание выполнения распределения задач. На рисунке 3.4 представлено основное окно программы после запуска. 54

Рисунок 3.4 – Главное окно программы Программа состоит из четырех блоков: ввод размерности матрицы, выбор целевой функции, ввод параметров матрицы и предоставление вычислений. Ввод данных параметров матрицы реализуется двумя способами: ручной ввод, путем внесения данных в форму и с помощью файла формата *.txt (рисунок 3.5). Рисунок 3.5 – Файл импорта данных В файле импорта данных указывается сначала размерность матрицы в первой строчке, в последующих строчках перечисляется параметры матрицы через пробел. На рисунке 3.6-3.7 представлен фрагмент импорта данных. Для этого необходимо выбрать вкладку «Файл»«Выбрать существующий». В данном 55

случае представлены данные, которые не опираются на пример решаемый от постановки задачи. Рисунок 3.6 – Импорт данных с файла Рисунок 3.7 – Импортируемые данные На основе постановки задачи, представим работу программы в ручном режиме ввода (рисунок 3.8-3.9). 56

Рисунок 3.8 – Параметры данных задачи Рисунок 3.9 – Полученные результаты Имеем следующее назначение: 1-й инженер назначен ответственным на выполнение 1-й задачи, 2-й − 2-й задачи, 3-й − 3-го мероприятия и 4-й − 4-ой задачи. Получен ответ: 17 (часов). Таким образом, расчет программы полностью советует результатам, которые производились вручную. Так же следующей классификацией задачи является запрос на 57

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

Рисунок 3.11 – Регрессионная зависимость для издержек на продажу Рисунок 3.12 – Регрессионная зависимость для издержек на покупку 59

Нужно учесть, что учреждение никогда не продает оборудование, срок использования, которых менее 2 года, и не держит основное средство со сроком эксплуатации, превышающим 4 года. Квартал, равный 1, соответствует первому наблюдаемому кварталу 6 лет назад. Цель предприятия – выбрать стратегию для покупки серверного оборудования на ближайшие 5 лет, где суммарные затраты будут минимальны. Предполагается, что через 5 лет все сервера реализуются по остаточной стоимости. Возможны Построение различные стратегии подходы предлагается к решению выполнить данной с задачи. применением регрессионного анализа и методов оптимизации, позволяющих определить оптимальные значения, исходя из целевой функции и ограничений. Программная реализация может быть выполнена с использованием любого статистического пакета или MS Excel [57]. Построение оптимизационной модели замены оборудования зависит от следующих параметров: издержки на ремонт, выручка от продаж и покупка нового оборудования. Представим расчеты каждого параметра математической модели в виде построения регрессионной зависимости для издержек на ремонт. Сеть узлов и дуг предназначена для построения оптимизационной модели замены оборудования. Есть дуга для каждого будущего квартала, включая текущий квартал, и на 5 лет вперед. Эти узлы помечены последовательно с 25 по 45. Из каждого узла в каждый последующий узел выходит дуга по крайней мере на четыре квартала вперед, но не более чем на 12 кварталов вперед (так как компания никогда не продает станки со сроком эксплуатации менее 1 года и не эксплуатирует их более 3 лет). В рамках сетевой модели цель предприятия – выбрать наикратчайший путь из узла 25 в узел 45 с минимальными общими издержками. а, b и с – исходные параметры; А11:В127 – это дуги, выходящие из узлов: колонка А – из какого узла дуга выходит, В – в какой узел идет (рисунок 3.13 – 3.14). 60

Рисунок 3.13 – Фрагмент размещения входных данных модели Рисунок 3.14 – Фрагмент расчетной части модели Целевая функция для построения оптимизационной модели замены оборудования имеет следующий вид: n  Si  Pi  min , i 1  Рвх.  1;   Рвых .  1;  Рпр.  0.  61 (3.2)

где Pi – потоки (вес колонки нули, так как нам неизвестно, какие дуги войдут в оптимальный план); Si – общие стоимостные затраты, тыс. рублей (рисунок ). Ограничениями целевой функции являются: потоки, исходящий из узла 25 и входящий в конечный узел 45, должны быть равны 1 – следует из поставленной цели задачи (попасть из узла 25 в узел 45), а для всех промежуточных вершин сумма входящих потоков равна сумме исходящих (рисунок 3.15). Рисунок 3.15 – Балансовые ограничения потоков Найденное оптимальное решение представляет собой следующий алгоритм действий: в 25-м квартале мы покупаем новый серверный комплект, используем его 6 кварталов, продаем в 31-м и в нем же покупаем другой, который эксплуатируем также в течение 7-ми кварталов, продаем и покупаем новый в 38-м. Этот сервер держим 7 кварталов, затем продаем и в 62

45-м закупаем новый серверный комплект. При всех таких действиях минимальные итоговые издержки получились равными 12 335,85р. Предлагаемая постановка задач определения оптимальных сроков замены и подход, позволяет решить задачу выбора оптимальной стратегии замены производственных активов предприятия, придерживаясь минимальных затрат. Таким образом, производственные затраты на ремонт и обслуживание серверного оборудования станут минимальны, а вместе с тем снизиться производительность и так называемая ликвидная стоимость. После проведения классификаций инцидента и решения поставленных задач с помощью разработанного алгоритма, инженеру необходимо провести первоначальную поддержку по устранению инцидента. В случае если инженер не обладает знаниями и опытом по устранению проблемы, то есть возможность обратиться в базу знаний, в которой хранятся все инциденты о прерванном сервисе и пути ее устранения. Далее, инженер технической поддержки 1-ой линии осуществляет поиск информации в Базе знаний (рисунок 3.16). Рисунок 3.16 – Поиск информации в Базе знаний База знаний содержится обычно неструктурированном виде, но необходимо ее тоже классифицировать по услуге и категории для облегчения поиска. Если ответ в Базе знаний найден, то производится консультация пользователя. Если ответ не найден, то специалисты обращаются к Базе 63

прецедентов. База прецедентов в данном случае необходима, так как пользователи чаще всего сталкиваются с проблемами, которые взаимосвязаны [58]. База прецедентов собрана из решений, принятых специалистами, где используются знания предыдущего опыта для выхода из той или иной ситуации. База прецедентов – это описание проблемы или ситуации в совокупности с подробным указанием действий, предпринимаемых в данной ситуации или для решения данной проблемы [59]. На рисунке 3.17 представлен процесс ведения и обращения к Базе знаний. Рисунок 3.17 – Рекомендации по устранению инцидента из Базы знаний Если специалист технической поддержки найдет ответ в Базе прецедентов, то осуществляется консультация по Базе прецедентов [60]. Если ответ не найден ни в Базе знаний, ни в Базе прецедентов, то заявка передается специалистам 2-й линии технической поддержки (инженерам). Инженеры проводят диагностику, восстанавливают сервис, устраняют инцидент. В случае невозможности восстановления сервиса, инженеры 2-й линии передают заявку разработчикам программного или аппаратного обеспечения (3-я линия поддержки). После восстановления сервиса специалисты выходят на связь с пользователем и сообщают о восстановлении сервиса. 64

3.2 Анализ и оценка полученных результатов поставленной задачи Алгоритм управления инцидентами составлен с учетом алгоритма решения задачи нахождения минимального количества каналов обработки заявок при заданных ограничениях. Алгоритм управления инцидентами показывает введение дополнительной линии поддержки за счет распределения задач 1-й линии, разгрузки обязанностей 2-й линии. Особенность данной линии в том, что она не требует выделения дополнительных специалистов, достаточно задействовать часть специалистов из 1-й линии, при этом выявив минимальное количество каналов обработки заявок при заданных ограничениях. Дополнительная линия поддержки использует базу прецедентов, где решаются вопросы, которые не были решены во время разговора с пользователем. Дополнительная линия необходима при появлении большого потока заявок в службу технической поддержки. В обязанности специалистов технической поддержки, выделенных в качестве дополнительной линии поддержки, входят такие задачи как:  проведение анализа назначенных на рабочую группу инцидентов с целью определения правильности назначения и контроля корректности, указанных оператором (диспетчером Контакт Центра) данных;  распределение инцидентов по специалистам 2-й линии технической поддержки (инженерам);  привлечение дополнительных ресурсов;  контроль принятия в работу и времени выполнения инцидентов;  формирование и направление на регулярной основе специалистам 2-й линии поддержки перечня стандартных вопросов, которые оператор (диспетчер КЦ) должен задать Контактному лицу при приёме Обращения;  исходящие звонки и консультирование решенным заявкам; 65 пользователей по

 консультирование из Базы прецедентов;  актуализация Базы знаний по письму от специалистов 2-й линии;  своевременное информирование об обновлениях или наблюдаемых изменениях в системе, сбоях письму технических (по от специалистов 2-й линии);  составление отчетности о поступивших и направленных заявках, ведение счета обращений и инцидентов, обработанных оператором и специалистами 2-й линии;  своевременное информирование специалистов 2-й линии о заявках, у которых истекает срок решения. Расчет количества операторов при алгоритму решения производится согласно минимального количества ограничения. Рекомендуется каналов большом обработки применять потоке задачи заявок заявок нахождения при блок-схему этого заданных алгоритма, предварительно расписав ее в виде программы на одном из языков объектноориентированного программирования для ускорения расчетов. Методика позволяет рассчитать достаточное количество специалистов при большом потоке заявок, тем самым уменьшить количество непринятых звонков и незарегистрированных заявок. Предложение по структуризации Базы знаний и внедрения базы прецедентов позволяет ускорить процесс обработки заявок специалистами 1-й линии. Актуализация и структурирование базы знаний возможна по классификации самого обращения. Например, в обращении всегда указывается тематика вопроса, к какой услуге, предоставляемой технической поддержкой относится тот или иной вопрос, к какому приоритету относится, и какой срок по SLA выделен для решения проблемного вопроса. Если в базе знаний информация будет структурирована таким образом, но можно провести привязку базы знаний с системой управления инцидентами. В результате применения данной методики по разработанному алгоритму уменьшилось количество заявок переданных специалистам 2-й 66

линии, что позволило инженерам придерживаться оговоренного срока выполнения заявки. Для проведения оценки целевой эффективности разработанной методики взяты данные работы службы технической поддержки за период с 12.03.2018 г. по 08.04.2018 г. В таблицах 3.1 – 3.3 приведены данные мониторинга за указанный период. Таблица 3.1 – Количество незарегистрированных заявок из числа принятых звонков. Неделя № 1 Неделя № 2 Неделя № 3 Неделя № 4 За весь период Принято Принято Не зарег. звонков звонков Не зарег. Принято Принято Не зарег. звонков звонков Не зарег. Принято Не зарег. звонков 601 68 430 51 2199 72 620 70 548 261 Таблица 3.2 – Среднее количество пропущенных звонков из числа поступивших звонков. Неделя № 1 Неделя № 2 Неделя № 3 Неделя №4 За весь период Поступи Поступи Поступи Поступи Поступи Пропуще Пропуще Пропуще Пропуще Пропуще ло ло ло ло ло но но но но но звонков звонков звонков звонков звонков 613 12 638 18 450 20 572 24 2273 74 Таблица 3.3 – Количество закрытых обращений с соблюдением крайних сроков. "Да" – обращение просрочено; "Нет" – обращение не просрочено Неделя № 1 Неделя № 2 Неделя № 3 Неделя № 4 Да 7 Да 8 Да 6 Да 6 Нет 522 Нет 544 Нет 354 Нет 491 Открытые обращения на конец периода Да Нет 101 558 Всего за период Да 128 Нет 2469 Ниже представлены диаграммы, полученные по результатам работы службы технической поддержки в период с 12.03.2018 г. по 08.04.2018 г (рисунок 3.18 – 3.20). 67

Рисунок 3.18 – Кол-во незарегистрированных заявок из принятых звонков Рисунок 3.19 – Среднее кол-во пропущенных звонков из числа поступивших 68

Рисунок 3.20 – Кол-во закрытых обращений с соблюдением крайних сроков Проведен сравнительный анализ данных с данными полученными ранее за период 08.01.2018 г. по 02.02.2018 г. Разница между незарегистрированными заявками и пропущенными звонками в том, что незарегистрированные заявки – это те звонки, которые были не по адресу, когда пользователи звонят не в ту службу технической поддержки, либо ошибка оператора по факту звонка, не зафиксировавшего проблему пользователя. Пропущенные звонки – это звонки от пользователей, которые длительное время находились в очереди в ожидании ответа оператора и сбросили вызов. 69

Для оценки целевой эффективности использованы полученные данные: х1 - Данные с 08.01.2018 г. по 02.02.2018 г.; х2 - Данные с 12.03.2018 г. по 18.05.2018 г. ∆ =(x2 - x1) ∙ 100% / x1 – формула оценки целевой эффективности. ∆1= (327 - 261) ∙ 100% / 261 ≈ 25.3% – % снижения количества незарегистрированных заявок. ∆2= (74 - 90) ∙ 100% / 90 ≈ 17.8% – % снижения количества пропущенных звонков. ∆3= (146 - 128)∙ 100% / 128 ≈ 14% – % снижения количества инцидентов с нарушенным сроком. В результате применения алгоритма совершенствования системы по учету инцидентов на 25.3% снизилось количество незарегистрированных заявок, на 17,8% снизилось количество пропущенных звонков и на 14% снизилось количество инцидентов с нарушенным сроком. Сравнительный анализ, проведенный для оценки целевой эффективности показал, что разработанный алгоритм применим инцидент-менеджмента. 70 для повышения эффективности

ЗАКЛЮЧЕНИЕ Выпускная квалификационная работа была выполнена на базе филиала ФГБУ ИАЦ Судебного департамента в Белгородской области. Автоматизация процессов учета инцидентов в информационной системе и распределение заявок между инженерами является актуальной задачей на сегодняшний день. Решение данной задачи рассматривалось в ходе выполнения ВКР. Исследование включило в себя сбор, обработку и анализ информации, как о предметной области, так и о методах решения подобных задач. Разработка алгоритмов оптимизации процессов управления инцидентами в службе технической поддержки является основным этапом на пути достижения цели выпускной работы. Достижение данного результата позволило значительно сократить временные и трудовые затраты, а именно: на 25.3% снизилось количество незарегистрированных заявок, на 17,8% снизилось количество пропущенных звонков и на 14% снизилось количество инцидентов с нарушенным сроком. Сравнительный анализ, проведенный для оценки целевой эффективности показал, что разработанный обобщенный алгоритм применим для повышения эффективности инцидент-менеджмента в информационной системе предприятия. В результате были решены следующие задачи:  изучены сведения об инцидент-менеджменте в информационной системе службы технической поддержки;  проведен анализ предметной области в рамках поставленной задачи по материалам отечественных и зарубежных публикаций;  проанализированы результаты управления инцидентами, полученные в процессе функционирования службы технической поддержки ГАС «Правосудие»;  исследованы методы и разработаны алгоритмы для оптимизации процесса обработки заявок в службе технической поддержки; 71

 осуществлена реализация и тестирование автоматизированной подсистемы для оптимизации процесса обработки инцидентов в службе технической поддержки судов общей юрисдикции;  проведен сравнительный анализ полученных результатов. Таким образом, цель ВКР достигнута, оптимизация процесса обработки инцидентов в службе технической поддержки выполнена в результате использования разработанного алгоритма. Таким образом, улучшились показатели эффективности работы отдела технической поддержки, а именно:  на 25.3% уменьшилось образование очереди на линии при большом потоке звонков (заявок);  рассчитано оптимальное количество операторов при большом потоке заявок, загруженность операторов;  минимизировано суммарное время выполнения проектов (17 часов);  рассчитан оптимальный план замены оборудования. В будущем возможна модернизация алгоритма и реализация его в рамках одной подсистемы. В целях модернизации целесообразно рассматривать функцию «Распределение проектов (работ)» в случаях, если число претендентов не равно количеству работ. Так же в будущем присутствует возможность реализации задачи по определению оптимального плана замены оборудования, путем решения ее в автоматизированной подсистеме. Автоматически будет строиться план, основанный на данных по учету состояния оборудования, где фиксируются все издержки на ремонт и другие манипуляции. 72

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 1 ГОСТ 7.32-2001 Отчет о научно-исследовательской работе. Структура и правила оформления [Текст]. - М.: Изд-во стандартов, сор. 2001. - 26 с. - (Система стандартов по информации, библиотечному и издательскому делу). 2 ГОСТ 7.1-2003 Библиографическая запись. Библиографическое описание [Текст]. - М.: Изд-во стандартов, сор. 2004. - 170 с. - (Система стандартов по информации, библиотечному и издательскому делу). 3 Бон, Ян Ван, Введение в ИТ сервис-менеджмент [Текст] / Бон Ян Ван, Кеммерлинг Георгес, Пондман Дик – М.: IT Expert, 2013. – 205 с. – ISBN: 90-77212-15-9. 4 ITILv.2.3 Лучшие практики: Поддержка Услуг, Стандарт [Текст] – М.: Ай-Теко, 2009. – 418 с. 5 Ингланд, Роб. Введение в реальный ITSM / Пер. с англ. Романа Журавлёва – М.: Лайвбук, 2011. – 132 с. – ISBN 978-5-904584-05-4. 6 Ингланд, Р. Овладевая ITIL. Скептическое руководство для ответственных лиц [Текст] / Ингланд, Р., Пер. с англ. Романа Журавлёва. – М.: Лайвбук, 2011. – 65 с. – ISBN: 978-5-904584-13-9. 7 Corp. YeSSoft «Free ITIL» [Текст] – YeSSoft, 2018. 8 Исайченко, Д.ITSM. Руководство по измерению [Текст] / Д. Исайченко, Р. Журавлев – М.: Лайвбук, 2015. 9 Регламент работы в ITIL. Часть 1. Введение в ITIL. [Текст] / М.: ГВЦ ОАО «РЖД». – 64 с. 10 Самуйлов, К.Е., Учеб. пособие для специальности информационные технологии [Текст] / К.Е. Самуйлов, Н.В. Серебренникова, А.В. Чукарин, Н.В. Яркина – М.: РУДН, 2012. – 171 с. 11 Тебайкина, Н.И. Применение концепции ITSM при вводе в действие информационных систем. Учебное пособие [Текст] Тебайкина – Екатеринбург: Изд-во Урал. ун-та, 2014. – 72 с. 73 / Н.И.

12 Самуйлов, К.Е. Введение в управление инфокоммуникациями [Текст] / К.Е. Самуйлов, Н.В. Серебренникова, А.В. Чукарин, Н.В. Яркина Учеб. пособие. М.: РУДН, 2017. – 87 с. 13 [Текст] Ивашко, А.Г. Информационный менеджмент. Учебное пособие. / А.Г. Ивашко – Издательство Тюменского государственного университета. – 2013 г. – 237 с. 14 Беленькая, М.Н. Администрирование системах. Учебное пособие для вузов [Текст] в информационных / М.Н. Беленькая, С.Т. Малиновский, Н.В. Яковенко – М.: Горячая линия - Телеком, 2011. – 400 с.: ил. – ISBN 978-5-9912-0164-3. 15 Добрынин, А.С. О механизме начального формирования релизов на стадии внедрения ИТ-сервисов. [Электронный ресурс] / А.С. Добрынин, С.М. Кулаков, В.В. Зимин Статья опубликована в материалах конференции "Теплотехника и информатика в образовании, науке и производстве" – Екатеринбург, 2013 - 4 с. 16 качества Гаврилов, С.И. Модели, методы и программные средства оценки информационно-образовательных ресурсов. диссертации канд. техн. наук. [Электронный ресурс] / С.И. Автореферат Гаврилов – Москва: НИЯУ МИФИ, 2011. - 22 с. 17 Брукс, Питер. Метрики для управления ИТ-услугами. [Текст] / Брукс, Питер. Пер. с англ. – М.: Альпина Бизнес Букс , 2008. – 283 с. – ISBN 978-5-9614-0647-4. 18 Зайцев, К.С. Применение методов Data Mining для поддержки процессов управления IT-услугами. Учебное пособие. [Текст] / К.С. Зайцев – М.: МИФИ, 2009. – 96 с. 19 Актуальные вопросы совершенствования системы учета, анализа и аудита в организациях: материалы Международной научно-практической конференции 28 февраля – 1 марта 2013 г.; М-во обр. науки РФ, ФГБОУ ВПО «Тамб. гос. ун-т им. Г.Р. Державина; [отв. ред. Е.А. Баева]. [Электронный ресурс] / Тамбов: Изд-во ТРОО «Бизнес-Наука-Общество», 2013. 194 с. 74

20 Преимущества ITIL. Pink Elephant Inc. All rights reserved. Перевод Кудричевского Б.Ю. Компания «СофтИнтегро». www.softintegro.ru/. Режим доступа: http://www.inframanager.ru/upload/pe_itil_benefits.pdf 21 Софтсервис Бекетов Вадим 1C:ITIL. - Управление информационными технологиями предприятия ITIL. v3.2011 Две недели которые могут изменить Вашу ИТ службу – Режим доступа: http://www.slideshare.net/Expolink/itil-19536505 22 Тушавин, В.А., Методы повышения качества управления инцидентами [Электронный ресурс] // Научно-исследовательский журнал «Методы менеджмента качества». Рекламно-информационное агентство "Стандарты и качество" (Москва), 2010, с.28-32. 23 Тушавин, В. А. Методология и практический опыт менеджмента качества службы технической поддержки и управления инцидентами предприятия [Электронный ресурс] //Теория и практика управления предприятиями и отраслями. Книга 3: монография/ А. Ф. Ахметов, Н. С. Вепрева, У. Г. Ибатуллин и др. – Тю- мень: Ист Консалтинг, 2010. – Гл. 4. – С. 68-91. 24 Авдеенко, Т. В. Метод определения релевантности прецедентов на основе нечетких лингвистических правил [Электронный ресурс] / Т. В. Авдеенко, Е. С. Макарова // Научный вестник Новосибирского государственного технического университета. - 2016. – Т. 62, № 1. – С. 17–34. 25 Размикович, А.А., Генетические алгоритмы распределения работ [Электронный ресурс] / А.А. Размикович, О.Л. Цветкова // Вестник Донского государственного технического университета. Общие и комплексные проблемы технических и прикладных наук и отраслей народного хозяйства. ВАК ДГТУ, 2011, с.343-348. 26 ГАС «Правосудие». Общее описание системы. ИРЦВ.42 5500 9.077.ПД. Режим доступа: http://techportal.sudrf.ru/files/tech_docs_2008/pd.pdf 27 Структура ФГБУ ИАЦ Судебного департамента. Режим доступа: http://iac.cdep.ru/index.php?id=30 75

28 Направление деятельности ФГБУ ИАЦ Судебного департамента. Режим доступа: http://iac.cdep.ru/index.php?id=14 29 Рассказова. М. Н., Имитационное моделирование систем. [Текст] – Омск: Омский государственный институт сервиса, 2010. – 80 с. 30 Гахов, Р.П. Компьютерное моделирование экономических процессов: учебное пособие для студентов вузов по специальности 230400.62 "Информационные системы и технологии" [Текст] / Р.П. Гахов, Н.В. Щербинина и др.; рец.: А.А.Черноморец. - Белгород: ИД Белгород, 2014. 88 с. 31 Кирпичников, А.П. Вероятностные характеристики открытой многоканальной системы массового обслуживания с ограниченным средним временем пребывания в системе [Электронный ресурс] / А.П. Кирпичников, Д.Б. Флакс // Вестник Казанского технологического университета. 2014. Т. 17. № 24. С. 242-245. 32 Кобелев, Н.Б. Основы имитационного моделирования сложных экономических систем. [Текст] / Н.Б. Кобелев – М.: Дело, 2016. – 336c. 33 Кирпичников, А.П. Прикладная теория массового обслуживания [Текст] / А.П. Кирпичников – М: Казань, Изд-во Казанского гос. университета, 2008. 112 с. 34 Кирпичников, А.П. Методы прикладной теории массового обслуживания [Текст] / А.П. Кирпичников – М: Казань, Изд-во Казанского университета, 2011. 200 с. 35 Шуваева, Е.Ю. Задача определения вероятностных характеристик работы отдела технической поддержки в АИС [Электронный ресурс] / Е.Ю. Шуваева, Н.Н. Гахова // Компьютерные технологии и телекоммуникации 2016 (КТИТК-2016) IV Всероссийская молодежная научно-практическая конференция 20 – 23 декабря 2016 г. Сборник трудов. Грозный: ГГНТУ, 2016. 76

36 Афанасьев, М. Ю. Исследование операций в экономике: модели, задачи, решения [Текст] : учеб. пособие (Серия. Высшее образование) / М. Ю. Афанасьев, Б. П. Суворов. – М. : ИНФРА-М, 2013. – 444 с. 37 Катков, К.А. Моделирование процессов управления инцидентами в информационной системе IT-компании [Электронный ресурс] / К.А. Катков, Н.Н. Гахова, Е.Ю. Шуваева // Научный результат. Информационные технологии. Системный анализ и управление. Выпуск № 3 (7) 2017, Белгород: НИУ БелГУ, 2017, с.12-18. 38 Варфоломеев, В. И., Назаров С. В. Алгоритмическое моделирование элементов экономических систем. Практикум; Финансы и статистика [Текст] / В. И. Варфоломеев, С. В. Назаров - 2008. - 264 c. 39 Козлов, В.Н. Решение задач математического программирования. [Текст] / В.Н. Козлов, Д.Н. Колесников, А.Г. Сиднев СПб.: СПбГТУ, 2012 – 112с. 40 Хемди, А.Т. Введение в исследование операций. [Текст] / А.Т. Хемди – М.: Издательство – Вильямс, 2008 – 912с. 41 Афанасьев, М.Ю. Прикладные задачи исследования операций: Учеб. пособие. [Текст] / М.Ю. Афанасьев, К.А. Багриновский, В.М. Матюшок – М.: ИНФРА-М, 2009 - 352 с. - (Учебники РУДН). 42 Гольштейн, Е.Г. Задачи линейного программирования транспортного типа. [Текст] / Е.Г. Гольштейн, Д.Б. Юдин – М.: Наука, ФИЗМАТЛИТ, 1969. - 384 с. 43 Загребаев, А.М. Методы математического программирования в задачах оптимизации сложных технических систем. Учебное пособие. [Текст] / А.М. Загребаев, Н.А. Крицына, Ю.П. Кулябичев, Ю.Ю. Шумилов – М.: МИФИ, 2017. 332 с. 44 Александрова, В.П. Планирование замены оборудования. [Текст] / В.П. Александрова – Киев: Наукова думка, 2013. - 266 с. 45 Имомов, А. И. Организация решения задач динамического программирования [Электронный ресурс] / 77 А. И. Имомов // Молодой

ученый. – 2015. – №12. – С. 1-6. – URL https://moluch.ru/archive/92/20036/ (дата обращения: 15.05.2018). 46 Бокиев, Э. Р. Методы решения задач линейного программирования [Электронный ресурс] / Э. Р. Бокиев // Молодой ученый. – 2015. – №12. – С. 1-6. – URL https://moluch.ru/archive/92/20040/ (дата обращения: 15.05.2018). 47 Окулов, С. М. Динамическое программирование [Электронный ресурс] / С. М. Окулов, О. А. Пестов. – Эл. изд. – М. : БИНОМ. Лаборатория знаний, 2012. – 296 с. 48 Креко, Б. Лекции по линейному программированию. Сб. Применение математики в экономических исследованиях, т. 1, [Электронный ресурс] / Креко Б., – Соцэкгиз, 2010. 49 Шуваева, Е.Ю. Использование семантических технологий при совершенствовании работы отдела технической поддержки в АИС / Шуваева Е.Ю., Ломазов В.А., Рыжков С.П. // Первые шаги в науку третьего тысячелетия: материалы XIII Всероссийской студенческой научно- практической конференции (Нефтекамск, 7 апреля 2017 г.).: Уфа: РИЦ БашГУ, 2017.: 965 с.– стр. 956-961. 50 Шуваева, Е.Ю. Использование знаниеориентированных технологий для совершенствования администрирования информационных систем // Естественнонаучные, инженерные и экономические исследования в технике, промышленности, медицине и сельском хозяйстве: материалы I Молодёжной научно-практической конференции с международным участием; под общ. ред. С.Н. Девицыной.: Белгород: ИД «Белгород» НИУ «БелГУ», 2017. − 693 с. – стр. 173-176. 51 Подходы к выбору Service Desk [Электронный ресурс]. – Режим доступа: http://habrahabr.ru/company/itarena/blog/241724/ 52 Котляр, Л.М. Оптимизация использования совокупных ресурсов информационной системы управления предприятием [Электронный ресурс] / 78

Л.М. Котляр, А.Н. Вильданов // Фундаментальные исследования.№ 5, 2004. – С. 22-25. http://rae.ru/fs/?section=content&op=show_article&article_id=7779649 53 Бирюков, А.Н. Лекции о процессах управления информационными технологиями. [Электронный ресурс] / А.Н. Бирюков – Изд.: Интернет-университет информационных технологий, Бином. Лаборатория знаний. 2010. - 216 с. 54 Шуваева, предприятия на Е.Ю. основе Оценка информационной девятиуровневой модели безопасности защищенности автоматизированных систем с использованием метода анализа иерархии / Е.Ю. Шуваева, О.Н. Захарова // Современное общество: наука, техника, образование: материалы Всероссийской научной конференции с международным участием (г.Нефтекамск, 15 декабря 2016 г.) Раздел 2 Информационная безопасность России в условиях глобального информационного общества Уфа: РИЦ БашГУ, 2016, с.343-348. 55 Радченко, М.Г. Архитектура и работа с данными 1С: Предприятия 8.2 [Текст] / М.Г. Радченко, Е.Ю. Хрусталева. - М.: 1СПаблишинг, 2011- 625 с, ил. 56 Конфигурация технологиями предприятия. конфигурации.Издательство: "ITIL: Управление Стандарт", М.: 1С редакция Год: информационными 1.0 - описание 2011. Режим доступа:http://erpsolution.ru/forum/showthread.php?t=201&page=13 57 Левинсон, Джефф Тестирование ПО с помощью Visual Studio 2010 [Текст] / Левинсон Джефф – ЭКОМ Паблишерз - Москва, 2012. - 314 c. 58 Шуваева, Е.Ю. Методика оптимального планирования замены оборудования с использованием программного средства MS Excel / Е.Ю. Шуваева, Н.Н. Гахова // ЭЛЕКТРОННОЕ НАУЧНО-ПРАКТИЧЕСКОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «Вестник современных исследований» ОМСК: Изд-во Научный центр «Орка». Выпуск №2-1(2) (ноябрь, 2016). с.153-157. 79

59 Шадрина, Н. И. Решение задач оптимизации в Microsoft Excel 2010 : учеб. пособие / Н. И. Шадрина, Н. Д. Берман ; [науч. ред. Э. М. Вихтенко]. – Хабаровск: Изд-во Тихоокеан. гос. ун-та, 2016. – 101 с. 60 Иорш, В.И. Управление основными фондами на основе ключевых показателей эффективности [Текст] / В. И. Иорш, В. Д. Стружинский // Горный журнал. – 2010. - №3. – С. 25 – 28. 61 Зарницина, К. Т. Управление проектами на предприятии: оценка эффективности [Текст] / К.Т. Зарницина - М.: Молодая гвардия, 2009. - 106 с. 80

ПРИЛОЖЕНИЯ ПРИЛОЖЕНИЕ А Рисунок А1 – Алгоритм задачи о назначениях 81

ПРИЛОЖЕНИЕ Б Листинг кода «Задача о назначениях»: #include <windows.h> #include <stdio.h> #define N 101 int v[N][N],u[N][N], cross0[N][N]; // 1 - отмеченный ноль, -1 - зачеркнутый. int str0[N],col0[N]; // Помеченные строки и столбцы. int strround[N],colround[N]; // Пометка кружками (вторая пометка). int usestr[N]; int n; // Размерность матриц. int vmax=0; // Максимальный элемент матрицы V. // Функция считывания данных из файла. int read(){ int a; int i,j; FILE* potok = fopen(“input.txt”,"r"); if(!potok){ MessageBox(0, "Отсутствует файл входных данных!" , ":-(", 16); return 0; } fscanf(potok,"%i",&n); for(i=0; i<n; i++) for(j=0; j<n; j++){ a=fscanf(potok,"%i",&v[i][j]); if(a==0 || a==EOF){ MessageBox(0,"Неверный формат данных!",":-(",16); return 0; } } fclose(potok); return 1; } // Приведение матрицы void privod(BOOL ToMax){ int i,j,umin; for(i=0; i<n; i++) for(j=0; j<n; j++) vmax = vmax > v[i][j] ? vmax : v[i][j]; if(ToMax){ for(i=0; i<n; i++) for(j=0; j<n; j++) u[i][j] = vmax-v[i][j]; } else{ for(i=0; i<n; i++) for(j=0; j<n; j++) u[i][j] = v[i][j]; } for(i=0; i<n; i++){ // Приведение по строкам. umin=u[i][0]; for(j=1; j<n; j++) // Минимум в строке. umin = umin < u[i][j] ? umin : u[i][j]; for(j=0; j<n; j++) u[i][j]-=umin; } for(j=0; j<n; j++){ // Приведение по столбцам. umin=u[0][j]; for(i=1; i<n; i++) // Минимум в столбце. umin = umin < u[i][j] ? umin : u[i][j]; for(i=0; i<n; i++) u[i][j]-=umin; } } void mark0(){ // Отмечаем и зачеркиваем нули. 82

int i,j; for(i=0; i<n; i++) for(j=0; j<n; j++) cross0[i][j]=0; for(i=0; i<n; i++) str0[i]=col0[i]=0; for(i=0; i<n; i++) for(j=0; j<n; j++) if(u[i][j]==0) if(str0[i]==0 && col0[j]==0){ cross0[i][j]=1; str0[i]=col0[j]=1; } else cross0[i][j]=-1; } int findcouple(int i){ int i1,j=0; while(cross0[i][j]!=1) j++; for(i1=0; i1<n; i1++) // Если ноль зачеркнут и в этой строке еще не были if(cross0[i1][j]==-1 && !usestr[i1]){ // Если строка не помечена if(!str0[i1]){ str0[i1]=1; cross0[i1][j]=1; cross0[i][j]=-1; return 1; } else{ usestr[i1]=1; if(findcouple(i1)){ cross0[i1][j]=1; cross0[i][j]=-1; return 1; } } } return 0; } // Нахождение паросочетания. int upcouple(){ int i,j; for(i=0; i<n; i++) usestr[i]=0; // В какой строке побывали. for(j=0; j<n; j++) if(!col0[j]) for(i=0; i<n; i++) if(cross0[i][j]==-1){ // Зачеркнутый ноль в непомеченном столбце. usestr[i]=1; if(findcouple(i)){ col0[j]=1; cross0[i][j]=1; return 1; } else usestr[i]=0; } return 0; } // Нахождение максимального паросочетания. void maxcouple(){ while(upcouple()); } // Проверка на решенность задачи. int fin(){ int i; for(i=0; i<n; i++) if(!str0[i]) return 0; return 1; 83

} // Нахождение минимальной опоры. void minsupport(){ int i,j,b; for(i=0; i<n; i++) strround[i]=colround[i]=0; for(i=0; i<n; i++) strround[i]=1-str0[i]; b=1; while(b){ b=0; for(i=0; i<n; i++) if(strround[i]) for(j=0; j<n; j++) if(cross0[i][j]==-1) colround[j]=1; for(j=0; j<n; j++) if(colround[j]) for(i=0; i<n; i++) if(cross0[i][j]==1 && !strround[i]){ b=1; strround[i]=1; } } } 84

ПРИЛОЖЕНИЕ В Печатная форма документа «Заявки» (СО-3) Процедура ПечатьАктаСО3(ТабДок, Ссылка) Экспорт //{{_КОНСТРУКТОР_ПЕЧАТИ(ПечатьАктаСО3) Макет = Справочники.itilЗадачи.ПолучитьМакет("ПечатьАктаСО3"); Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ | itilЗадачи.АдресОА, | itilЗадачи.Актив, | itilЗадачи.Дата, | itilЗадачи.ДатаИсполнения, | itilЗадачи.ДолжностьЛОА, | itilЗадачи.ДолжностьУЛ, | itilЗадачи.Инициатор, | itilЗадачи.Код, | itilЗадачи.КонтрагентПодрядчик, | itilЗадачи.КСА, | itilЗадачи.ЛицоОА, | itilЗадачи.Наименование, | itilЗадачи.НомерОА, | itilЗадачи.Описание, | itilЗадачи.Организация, | itilЗадачи.РабочееМесто, | itilЗадачи.СпособРазрешения, | itilЗадачи.ТекущийИсполнитель, | itilЗадачи.УполномоченноеЛицо |ИЗ | Справочник.itilЗадачи КАК itilЗадачи |ГДЕ | itilЗадачи.Ссылка В (&Ссылка)"; Запрос.Параметры.Вставить("Ссылка", Ссылка); Выборка = Запрос.Выполнить().Выбрать(); Заголовок1 = Макет.ПолучитьОбласть("Заголовок1"); Заголовок2 = Макет.ПолучитьОбласть("Заголовок2"); Форма = Макет.ПолучитьОбласть("Форма"); ДатаТек = Макет.ПолучитьОбласть("ДатаТек"); ОА = Макет.ПолучитьОбласть("ОА"); Договор = Макет.ПолучитьОбласть("Договор"); Заявка = Макет.ПолучитьОбласть("Заявка"); Печати = Макет.ПолучитьОбласть("Печати"); ТабДок.Очистить(); ВставлятьРазделительСтраниц = Ложь; Пока Выборка.Следующий() Цикл Если ВставлятьРазделительСтраниц Тогда ТабДок.ВывестиГоризонтальныйРазделительСтраниц(); КонецЕсли; ТабДок.Вывести(Форма); Заголовок1.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок1, Выборка.Уровень()); Заголовок2.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок2, Выборка.Уровень()); ДатаТек.Параметры.Заполнить(Выборка); ТабДок.Вывести(ДатаТек, Выборка.Уровень()); ОА.Параметры.Заполнить(Выборка); ТабДок.Вывести(ОА, Выборка.Уровень()); 85

Договор.Параметры.Заполнить(Выборка); ТабДок.Вывести(Договор, Выборка.Уровень()); Заявка.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заявка, Выборка.Уровень()); Печати.Параметры.Заполнить(Выборка); ТабДок.Вывести(Печати, Выборка.Уровень()); ВставлятьРазделительСтраниц = Истина; КонецЦикла; //}} КонецПроцедуры Печатная форма документа «Обновление ПО» (СО-6) Процедура ПечатьАктаСО6(ТабДок, Ссылка) Экспорт //{{_КОНСТРУКТОР_ПЕЧАТИ(ПечатьАктаСО6) Макет = Документы.ОбновлениеПО.ПолучитьМакет("ПечатьАктаСО6"); Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ | ОбновлениеПО.АдресОА, | ОбновлениеПО.Дата, | ОбновлениеПО.ДолжностьЛОА, | ОбновлениеПО.ДолжностьУЛ, | ОбновлениеПО.КСА, | ОбновлениеПО.ЛицоОА, | ОбновлениеПО.Номер, | ОбновлениеПО.НомерОА, | ОбновлениеПО.ОбъектАвтоматизации, | ОбновлениеПО.УполномоченноеЛицо, | ОбновлениеПО.ОбщееПО.( | НомерСтроки, | Наименование, | ВерсияДо, | ВерсияПосле, | ТипОборудования, | ИнвНомер | ), | ОбновлениеПО.СпециальноеПО.( | НомерСтроки, | Наименование, | ВерсияДо, | ВерсияПосле, | ТипОборудования, | ИнвНомер | ), | ОбновлениеПО.Пользователи.( | НомерСтроки, | ФИО, | Должность, | ОПОиСПО | ) |ИЗ | Документ.ОбновлениеПО КАК ОбновлениеПО |ГДЕ | ОбновлениеПО.Ссылка В (&Ссылка)"; Запрос.Параметры.Вставить("Ссылка", Ссылка); Выборка = Запрос.Выполнить().Выбрать(); Заголовок1 = Макет.ПолучитьОбласть("Заголовок1"); Заголовок2 = Макет.ПолучитьОбласть("Заголовок2"); Форма = Макет.ПолучитьОбласть("Форма"); ДатаТек = Макет.ПолучитьОбласть("ДатаТек"); ОА = Макет.ПолучитьОбласть("ОА"); Договор = Макет.ПолучитьОбласть("Договор"); 86

ОбластьОбщееПОШапка = Макет.ПолучитьОбласть("ОбщееПОШапка"); ОбластьОбщееПО = Макет.ПолучитьОбласть("ОбщееПО"); ОбластьСпециальноеПОШапка = Макет.ПолучитьОбласть("СпециальноеПОШапка"); ОбластьСпециальноеПО = Макет.ПолучитьОбласть("СпециальноеПО"); ОбластьПользователиШапка = Макет.ПолучитьОбласть("ПользователиШапка"); ОбластьПользователи = Макет.ПолучитьОбласть("Пользователи"); Подвал = Макет.ПолучитьОбласть("Подвал"); Печати = Макет.ПолучитьОбласть("Печати"); ТабДок.Очистить(); ВставлятьРазделительСтраниц = Ложь; Пока Выборка.Следующий() Цикл Если ВставлятьРазделительСтраниц Тогда ТабДок.ВывестиГоризонтальныйРазделительСтраниц(); КонецЕсли; ТабДок.Вывести(Форма); Заголовок1.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок1, Выборка.Уровень()); Заголовок2.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок2, Выборка.Уровень()); ДатаТек.Параметры.Заполнить(Выборка); ТабДок.Вывести(ДатаТек, Выборка.Уровень()); ОА.Параметры.Заполнить(Выборка); ТабДок.Вывести(ОА, Выборка.Уровень()); Договор.Параметры.Заполнить(Выборка); ТабДок.Вывести(Договор, Выборка.Уровень()); ТабДок.Вывести(ОбластьОбщееПОШапка); ВыборкаОбщееПО = Выборка.ОбщееПО.Выбрать(); Пока ВыборкаОбщееПО.Следующий() Цикл ОбластьОбщееПО.Параметры.Заполнить(ВыборкаОбщееПО); ТабДок.Вывести(ОбластьОбщееПО, ВыборкаОбщееПО.Уровень()); КонецЦикла; ТабДок.Вывести(ОбластьСпециальноеПОШапка); ВыборкаСпециальноеПО = Выборка.СпециальноеПО.Выбрать(); Пока ВыборкаСпециальноеПО.Следующий() Цикл ОбластьСпециальноеПО.Параметры.Заполнить(ВыборкаСпециальноеПО); ТабДок.Вывести(ОбластьСпециальноеПО, ВыборкаСпециальноеПО.Уровень()); КонецЦикла; ТабДок.Вывести(ОбластьПользователиШапка); ВыборкаПользователи = Выборка.Пользователи.Выбрать(); Пока ВыборкаПользователи.Следующий() Цикл ОбластьПользователи.Параметры.Заполнить(ВыборкаПользователи); ТабДок.Вывести(ОбластьПользователи, ВыборкаПользователи.Уровень()); КонецЦикла; Подвал.Параметры.Заполнить(Выборка); ТабДок.Вывести(Подвал); Печати.Параметры.Заполнить(Выборка); ТабДок.Вывести(Печати); ВставлятьРазделительСтраниц = Истина; КонецЦикла; //}} КонецПроцедуры 87

Печатная форма документа «Проверка технического состояния» (СО-7) Процедура ПечатьАктаСО7(ТабДок, Ссылка) Экспорт //{{_КОНСТРУКТОР_ПЕЧАТИ(ПечатьАктаСО7) Макет = Документы.ПроверкаТехническогоСостояния.ПолучитьМакет("ПечатьАктаСО7"); Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ | ПроверкаТехническогоСостояния.АдресОА, | ПроверкаТехническогоСостояния.ВидРемонта, | ПроверкаТехническогоСостояния.Дата, | ПроверкаТехническогоСостояния.ДолжностьУЛ, | ПроверкаТехническогоСостояния.ИнвНомер, | ПроверкаТехническогоСостояния.Комплектность, | ПроверкаТехническогоСостояния.КСА, | ПроверкаТехническогоСостояния.Номер, | ПроверкаТехническогоСостояния.НомерОА, | ПроверкаТехническогоСостояния.Оборудование, | ПроверкаТехническогоСостояния.ОбъектАвтоматизации, | ПроверкаТехническогоСостояния.Пломбы, | ПроверкаТехническогоСостояния.Повреждения, | ПроверкаТехническогоСостояния.СервисныйЦентр, | ПроверкаТехническогоСостояния.СерНомер, | ПроверкаТехническогоСостояния.УполномоченноеЛицо, | ПроверкаТехническогоСостояния.ЛицоОА, | ПроверкаТехническогоСостояния.ДолжностьЛОА, | ПроверкаТехническогоСостояния.ГодВыпуска, | ПроверкаТехническогоСостояния.Обращение, | ПроверкаТехническогоСостояния.Заключение, | ПроверкаТехническогоСостояния.Рекомендации, | ПроверкаТехническогоСостояния.ПричиныНеисправности, | ПроверкаТехническогоСостояния.НомерОбращения, | ПроверкаТехническогоСостояния.ДатаЗаявки, | ПроверкаТехническогоСостояния.Заявитель |ИЗ | Документ.ПроверкаТехническогоСостояния КАК ПроверкаТехническогоСостояния |ГДЕ | ПроверкаТехническогоСостояния.Ссылка В (&Ссылка)"; Запрос.Параметры.Вставить("Ссылка", Ссылка); Выборка = Запрос.Выполнить().Выбрать(); Заголовок1 = Макет.ПолучитьОбласть("Заголовок1"); Заголовок2 = Макет.ПолучитьОбласть("Заголовок2"); Форма = Макет.ПолучитьОбласть("Форма"); ДатаТек = Макет.ПолучитьОбласть("ДатаТек"); ОА = Макет.ПолучитьОбласть("ОА"); Договор = Макет.ПолучитьОбласть("Договор"); Печати = Макет.ПолучитьОбласть("Печати"); ВставлятьРазделительСтраниц = Ложь; Пока Выборка.Следующий() Цикл Если ВставлятьРазделительСтраниц Тогда ТабДок.ВывестиГоризонтальныйРазделительСтраниц(); КонецЕсли; ТабДок.Вывести(Форма); Заголовок1.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок1, Выборка.Уровень()); Заголовок2.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок2, Выборка.Уровень()); ДатаТек.Параметры.Заполнить(Выборка); ТабДок.Вывести(ДатаТек, Выборка.Уровень()); 88

ОА.Параметры.Заполнить(Выборка); ТабДок.Вывести(ОА, Выборка.Уровень()); Договор.Параметры.Заполнить(Выборка); ТабДок.Вывести(Договор, Выборка.Уровень()); Печати.Параметры.Заполнить(Выборка); ТабДок.Вывести(Печати); ВставлятьРазделительСтраниц = Истина; КонецЦикла; //}} КонецПроцедуры Печатная форма документа «Выполнение ремонта ПТС» (СО-8) Процедура ПечатьАктаСО8(ТабДок, Ссылка) Экспорт //{{_КОНСТРУКТОР_ПЕЧАТИ(ПечатьАктаСО8) Макет = Документы.ВыполнениеРемонтаПТС.ПолучитьМакет("ПечатьАктаСО8"); Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ | ВыполнениеРемонтаПТС.АдресОА, | ВыполнениеРемонтаПТС.Дата, | ВыполнениеРемонтаПТС.ДолжностьЛОА, | ВыполнениеРемонтаПТС.ДолжностьУЛ, | ВыполнениеРемонтаПТС.Заключение, | ВыполнениеРемонтаПТС.КСА, | ВыполнениеРемонтаПТС.ЛицоОА, | ВыполнениеРемонтаПТС.Номер, | ВыполнениеРемонтаПТС.НомерОА, | ВыполнениеРемонтаПТС.ОбъектАвтоматизации, | ВыполнениеРемонтаПТС.СервисныйЦентр, | ВыполнениеРемонтаПТС.УполномоченноеЛицо, | ВыполнениеРемонтаПТС.ИсходноеОборудование.( | НомерСтроки, | АктСО7, | Оборудование, | ИнвНомер, | СерийныйНомер, | ВидРемонта | ), | ВыполнениеРемонтаПТС.ЗаменаОборудование.( | НомерСтроки, | Оборудование, | ИнвНомер, | СерийныйНомер | ) |ИЗ | Документ.ВыполнениеРемонтаПТС КАК ВыполнениеРемонтаПТС |ГДЕ | ВыполнениеРемонтаПТС.Ссылка В (&Ссылка)"; Запрос.Параметры.Вставить("Ссылка", Ссылка); Выборка = Запрос.Выполнить().Выбрать(); Заголовок1 = Макет.ПолучитьОбласть("Заголовок1"); Заголовок2 = Макет.ПолучитьОбласть("Заголовок2"); Форма = Макет.ПолучитьОбласть("Форма"); ДатаТек = Макет.ПолучитьОбласть("ДатаТек"); ОА = Макет.ПолучитьОбласть("ОА"); Договор = Макет.ПолучитьОбласть("Договор"); Печати = Макет.ПолучитьОбласть("Печати"); Заключение = Макет.ПолучитьОбласть("Заключение"); Замена = Макет.ПолучитьОбласть("Замена"); ОбластьИсходноеОборудованиеШапка = Макет.ПолучитьОбласть("ИсходноеОборудованиеШапка"); ОбластьИсходноеОборудование = Макет.ПолучитьОбласть("ИсходноеОборудование"); 89

ОбластьЗаменаОборудованиеШапка = Макет.ПолучитьОбласть("ЗаменаОборудованиеШапка"); ОбластьЗаменаОборудование = Макет.ПолучитьОбласть("ЗаменаОборудование"); ТабДок.Очистить(); ВставлятьРазделительСтраниц = Ложь; Пока Выборка.Следующий() Цикл Если ВставлятьРазделительСтраниц Тогда ТабДок.ВывестиГоризонтальныйРазделительСтраниц(); КонецЕсли; ТабДок.Вывести(Форма); Заголовок1.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок1, Выборка.Уровень()); Заголовок2.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заголовок2, Выборка.Уровень()); ДатаТек.Параметры.Заполнить(Выборка); ТабДок.Вывести(ДатаТек, Выборка.Уровень()); ОА.Параметры.Заполнить(Выборка); ТабДок.Вывести(ОА, Выборка.Уровень()); Договор.Параметры.Заполнить(Выборка); ТабДок.Вывести(Договор, Выборка.Уровень()); ТабДок.Вывести(ОбластьИсходноеОборудованиеШапка); ВыборкаИсходноеОборудование = Выборка.ИсходноеОборудование.Выбрать(); Пока ВыборкаИсходноеОборудование.Следующий() Цикл ОбластьИсходноеОборудование.Параметры.Заполнить(ВыборкаИсходноеОборудование); ТабДок.Вывести(ОбластьИсходноеОборудование, ВыборкаИсходноеОборудование.Уровень()); КонецЦикла; Замена.Параметры.Заполнить(Выборка); ТабДок.Вывести(Замена); ТабДок.Вывести(ОбластьЗаменаОборудованиеШапка); ВыборкаЗаменаОборудование = Выборка.ЗаменаОборудование.Выбрать(); Пока ВыборкаЗаменаОборудование.Следующий() Цикл ОбластьЗаменаОборудование.Параметры.Заполнить(ВыборкаЗаменаОборудование); ТабДок.Вывести(ОбластьЗаменаОборудование, ВыборкаЗаменаОборудование.Уровень()); КонецЦикла; Заключение.Параметры.Заполнить(Выборка); ТабДок.Вывести(Заключение); Печати.Параметры.Заполнить(Выборка); ТабДок.Вывести(Печати); ВставлятьРазделительСтраниц = Истина; КонецЦикла; //}} КонецПроцедуры Запрос формирования отчета «Реестр неисправностей оборудования» ВЫБРАТЬ СубъектРФ.Значение КАК СубъектРФ, ПроверкаТехническогоСостояния.ОбъектАвтоматизации.Наименование КАК ОбъектАвтоматизации, ПроверкаТехническогоСостояния.ДатаЗаявки КАК ДатаЗаявкиВРемонт, 90

ПроверкаТехническогоСостояния.Оборудование.ТипАктива КАК ТипПТС, ПроверкаТехническогоСостояния.Оборудование.НаименованиеПолное КАК НаименованиеПТС, ПроверкаТехническогоСостояния.Обращение.Описание КАК ОписаниеНеисправности, ПередачаВРемонтПТС.Дата КАК ДатаПередачиВСервисныйЦентр, ВыполнениеРемонтаПТС.Дата КАК ДатаПолученияИзСервисногоЦентра ИЗ Документ.ПроверкаТехническогоСостояния КАК ПроверкаТехническогоСостояния, Константа.СубъектРФ КАК СубъектРФ, Документ.ПередачаВРемонтПТС КАК ПередачаВРемонтПТС, Документ.ВыполнениеРемонтаПТС КАК ВыполнениеРемонтаПТС Запрос формирования отчета «Остатки и обороты на рабочих местах» ВЫБРАТЬ РАЗЛИЧНЫЕ ОстаткиИОбороты.Актив КАК Актив, ОстаткиИОбороты.РабочееМесто КАК РабочееМесто, ОстаткиИОбороты.МОЛ КАК МОЛ, ОстаткиИОбороты.КоличествоНачальныйОстаток, ОстаткиИОбороты.КоличествоКонечныйОстаток, ОстаткиИОбороты.СтоимостьНачальныйОстаток, ОстаткиИОбороты.СтоимостьКонечныйОстаток, ОстаткиИОбороты.КоличествоПриход, ОстаткиИОбороты.КоличествоРасход, ОстаткиИОбороты.СтоимостьПриход, ОстаткиИОбороты.СтоимостьРасход, ОстаткиИОбороты.Регистратор КАК Регистратор, ОстаткиИОбороты.ВидАктива КАК ВидАктива ИЗ (ВЫБРАТЬ ОстаткиНаНачало.Актив КАК Актив, ОстаткиНаНачало.РабочееМесто КАК РабочееМесто, ОстаткиНаНачало.МОЛ КАК МОЛ, ОстаткиНаНачало.КоличествоНачальныйОстаток КАК КоличествоНачальныйОстаток, NULL КАК КоличествоКонечныйОстаток, ОстаткиНаНачало.СтоимостьНачальныйОстаток КАК СтоимостьНачальныйОстаток, NULL КАК СтоимостьКонечныйОстаток, NULL КАК КоличествоПриход, NULL КАК КоличествоРасход, NULL КАК СтоимостьПриход, NULL КАК СтоимостьРасход, NULL КАК Регистратор, ВЫБОР КОГДА ОстаткиНаНачало.Актив ССЫЛКА Справочник.itilАктивы ТОГДА ОстаткиНаНачало.Актив.Модель.ВидАктива ИНАЧЕ ОстаткиНаНачало.Актив.ВидАктива КОНЕЦ КАК ВидАктива ИЗ РегистрНакопления.itilПартииАктивовНаСкладах.ОстаткиИОбороты(, , Авто, , ) КАК ОстаткиНаНачало ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ ОстаткиНаКонец.Актив, ОстаткиНаКонец.РабочееМесто, ОстаткиНаКонец.МОЛ, NULL, ОстаткиНаКонец.КоличествоКонечныйОстаток, NULL, ОстаткиНаКонец.СтоимостьКонечныйОстаток, NULL, NULL, NULL, NULL, NULL, ВЫБОР КОГДА ОстаткиНаКонец.Актив ССЫЛКА Справочник.itilАктивы ТОГДА ОстаткиНаКонец.Актив.Модель.ВидАктива ИНАЧЕ ОстаткиНаКонец.Актив.ВидАктива 91

КОНЕЦ ИЗ РегистрНакопления.itilПартииАктивовНаСкладах.ОстаткиИОбороты(, , Авто, , ) КАК ОстаткиНаКонец ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Обороты.Актив, Обороты.РабочееМесто, Обороты.МОЛ, NULL, NULL, NULL, NULL, Обороты.КоличествоПриход, Обороты.КоличествоРасход, Обороты.СтоимостьПриход, Обороты.СтоимостьРасход, Обороты.Регистратор, ВЫБОР КОГДА Обороты.Актив ССЫЛКА Справочник.itilАктивы ТОГДА Обороты.Актив.Модель.ВидАктива ИНАЧЕ Обороты.Актив.ВидАктива КОНЕЦ ИЗ РегистрНакопления.itilПартииАктивовНаСкладах.ОстаткиИОбороты(, , Авто, , ) КАК Обороты) КАК ОстаткиИОбороты {ГДЕ ОстаткиИОбороты.Актив.*, ОстаткиИОбороты.РабочееМесто.*, ОстаткиИОбороты.МОЛ.*, ОстаткиИОбороты.ВидАктива.*} УПОРЯДОЧИТЬ ПО РабочееМесто, МОЛ, Актив, ВидАктива, Регистратор 92

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв