Разработка мобильного приложения по формированию и отслеживанию заявок на обслуживание оборудования для ГАУ ТО "МФЦ"

Ромашин Артур

Разработка мобильного приложения по формированию и отслеживанию заявок на обслуживание оборудования для ГАУ ТО "МФЦ"

В работе описан процесс по разработке мобильного приложения для устройств на операционной системе Android, а также серверного приложения для оформления, контроля за исполнением заявок на обслуживание оборудования и интегрирование в текущие информационные системы ГАУ ТО "Многофункциональный центр предоставления государственных и муниципальных услуг в Тюменской области”, а также изучение существующих информационных систем МФЦ, в которых ведется учет информации об оборудовании и обработка заявок и изучение фактического процесса исполнения заявок по неисправностям оборудования.

Информатика

Дипломы

Вуз: Тюменский государственный университет (ТюмГУ)

ID: 5f45f8abcd3d3e0001720171

UUID: 48724110-c98e-0138-211b-0242ac180006

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

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

Просмотры: 24

10.48

Ромашин Артур

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

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

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

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

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

Оглавление СПИСОК ТЕРМИНОВ ........................................................................................... 3 ВВЕДЕНИЕ .............................................................................................................. 4 ГЛАВА 1. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К РАЗРАБАТЫВАЕМОЙ СИСТЕМЕ ................................................................................................................ 6 1.1 БЕРЕЖЛИВОЕ ПРОИЗВОДСТВО ....................................................... 6 1.2 ОПИСАНИЕ БИЗНЕС-ПРОЦЕССА ..................................................... 8 1.3 ОБЗОР ИСТОЧНИКОВ ЛИТЕРАТУРЫ ............................................ 11 ГЛАВА 2. ИНФРАСТРУКТУРА СИСТЕМ МФЦ............................................. 18 2.1 ОПИСАНИЕ ИНФРАСТРУКТУРЫ МФЦ......................................... 18 2.2 СИСТЕМА ЗАЯВОК OTRS ................................................................. 18 2.3 СИСТЕМА УЧЕТА ОБОРУДОВАНИЯ ............................................. 23 ГЛАВА 3. РАЗРАБОТКА МОБИЛЬНОГО И СЕРВЕРНОГО ПРИЛОЖЕНИЙ ................................................................................................................................. 26 3.1 ОПИСАНИЕ ТЕХНОЛОГИЙ И СРЕДСТВ РАЗРАБОТКИ ............ 26 3.2 ОСОБЕННОСТИ ИНТЕГРАЦИИ С ИМЕЮЩИМИСЯ СЕРВИСАМИ ПРЕДПРИЯТИЯ .......................................................................... 27 3.3 АУТЕНТИФИКАЦИЯ .......................................................................... 28 3.4 СЕРВЕРНОЕ ПРИЛОЖЕНИЕ ............................................................. 30 3.5 МОБИЛЬНОЕ ПРИЛОЖЕНИЕ ........................................................... 34 ЗАКЛЮЧЕНИЕ ..................................................................................................... 39 СПИСОК ЛИТЕРАТУРЫ..................................................................................... 40

СПИСОК ТЕРМИНОВ МФЦ – Многофункциональный центр. ITSM (IT Service Management) — это деятельность, выполняемая организацией для проектирования, планирования, предоставления, эксплуатации и контроля услуг информационных технологий, предлагаемых клиентам. OTRS (Open-source Ticket Request System) — открытая система обработки заявок. СУО – Система учета оборудования, разработанная ГАУ ТО «МФЦ». API (Application Programming Interface) – описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. JWT (JSON Web Token) – интернет-стандарт для создания данных с необязательной подписью и/или необязательным шифрованием, чья полезная нагрузка содержит JSON, который утверждает некоторое количество утверждений, основанный на открытом стандарте (RFC 7519) для создания токенов доступа. REST (REpresentational State Transfer) – это программный архитектурный стиль, который определяет набор ограничений, которые будут использоваться для создания веб-сервисов. 3

ВВЕДЕНИЕ В нынешних условиях, когда компании должны качественно и бесперебойно вести свою работу и обслуживать клиентов, любые задержки с простоем оборудования из-за неисправностей или задержки, связанные с доставкой различных грузов неприемлемы, ведь они могут понести убытки и к репутационным потерям. Также нельзя забывать о том, что сам процесс построения заявки на доставку материалов нуждается в ускорении, упрощении или даже в автоматизации. Мониторинг за исполнением заявки также необходим, что включает в себя, отслеживание стадий выполнения доставки, список ответственных лиц, время завершения заявки и итог выполнения. Решением данной проблемы может являться разработка сервиса по формированию и отслеживанию заявок на обслуживание оборудования, интегрированного в текущую информационную систему учреждения. Данная работа посвящена изучению процесса обслуживания и доставки оборудования и материальных ценностей в сети филиалов центров “Мои документы” и поиску решений позволяющих улучшить данный процесс, а также интегрированию полученного решения в работу организации. Основной целью работы является разработка мобильного приложения для устройств на операционной системе Android по оформлению, контролю за исполнением заявок на обслуживание оборудования и интегрирование в текущие информационные системы ГАУ ТО "Многофункциональный центр предоставления государственных и муниципальных услуг в Тюменской области” Задачи: • Изучить существующие информационные системы МФЦ, в которых ведется учет информации об оборудовании и обработка заявок • Изучить фактический процесс неисправностям оборудования 4 исполнения заявок по

• Разработать мобильное и серверное приложение • Интегрировать разработанные сервисы в работу центров “Мои документы” 5

ГЛАВА 1. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К РАЗРАБАТЫВАЕМОЙ СИСТЕМЕ 1.1 БЕРЕЖЛИВОЕ ПРОИЗВОДСТВО Бережливое производство, созданное на основе Toyota Production System, в настоящее время является одной из философий управления. Вся концепция этой философии основана на «потерях». Избавление от них — это самая суть бережливого производства. Несмотря на кажущиеся простыми принципы, ликвидация потерь не является легкой задачей. Многие компании, даже те, все еще пытаются избавиться от потерь своих процессов. Toyota распознает три основных типа потерь – Муда, Мура, Мури. Все три японские Му определяют понимание потерь. Муда означает пустая трата или бесполезность. Муда относится к трате ненужных действий. Этот тип потерь характеризуется использованием времени, денег и ресурсов, при этом не добавляя никакой ценности для клиента. Существует семь традиционных типов муда: 1. Перепроизводство - производство впереди того, что действительно нужно следующему процессу или клиенту. Худшая форма муда, потому что она способствует другим шести. 2. Ожидание - операторы бездействуют, когда машины работают, оборудование выходит из строя, необходимые детали не приходят и т. д. 3. Транспортировка - перемещение частей и продуктов без необходимости, например, с этапа обработки на склад до последующего этапа обработки, когда второй этап может быть расположен непосредственно рядом с первым этапом. 4. Избыточная обработка - выполнение ненужной или неправильной обработки, как правило, из-за плохого инструмента или дизайна продукта. 5. Инвентаризация - обработка ненужных запасов, что приводит к другим типам муда, таким как ожидание, исправление и чрезмерная обработка. 6

6. Движение - создание бесполезных или ненужных движений, таких как поиск деталей, инструментов, документов и т. д. 7. Исправление - осмотр продукции на наличие дефектов, переделка бракованных материалов. Муда делает невозможным достижение цели, используя только ресурсы, которые абсолютно необходимы. Муда также приводит к потерям во времени, что усугубляет доставку продукта в нужное время. Мури означает перегруженность или необоснованность. Это связано с ненужной перегрузкой оборудования, оборудования или людских ресурсов. Перегрузка для сотрудников создает ненужные стрессы, снижая их работоспособность. Есть три основные причины Мури: 1. Плохо организованная рабочая станция 2. Отсутствие стандартизированной работы - проблемы с поддержанием 5S (Сортировка - Соблюдение порядка - Содержание в чистоте – Стандартизация - Совершенствование 3. Мура - изменение объема производства, о которой будет сказано далее. Мури также является распространенной причиной поломок, когда речь идет о машинах, и невыходов на работу, когда речь идет о людях. Таким образом, чрезмерная нагрузка мешает компании, ведь люди не могут работать на 100% своих возможностей. Мура означает вариации или неровности. Это относится к потерям неравномерности в объеме производства. Это может принимать две разные формы: • Изменения в планировании производства, • Неравномерная производственная нагрузка и темп работы. Хотя Мура часто встречается во многих компаниях, этот тип потерь часто игнорируется управленческими командами. Это большая ошибка, 7

потому что изменение объема производства может быть общей причиной как Мури, так и Муда. Все три вида потерь связаны между собой. Мура и мури являются единственными причинами муда, создавая больше губительной деятельности подрывая все предыдущие усилия по избавлению от потерь. 1.2 ОПИСАНИЕ БИЗНЕС-ПРОЦЕССА Для начала необходимо определить, что является бизнес-процессом. Бизнес-процесс — это описание последовательности действий сотрудников при выполнении определенных действий в графическом и текстовом виде с целью регламентации действий в коллективе, анализа и оптимизации их последовательности. Описание бизнес-процесса в текстовом виде сложно представить и анализировать системно. Поэтому принято описывать бизнес-процесс в виде схемы, которая является представлением пошаговых процессов, где схемы обычно создаются как блок-схемы, в которых фигуры представляют этапы процесса, а последовательность этапов обозначается стрелками. Схема решения бизнес-процесса будет построена на примере поломки оборудования в отделении центра “Мои документы”. В начале работы, процесс решения этой проблемы, а именно доставка рабочего оборудования из главного офиса и отправка вышедшего из строя оборудования в главный офис для ремонта или отправки его на утилизацию описывается так. После обнаружения неисправности, работник при помощи своего компьютера или чужого компьютера, если сломался свой компьютер, создает заявку в системе заявок OTRS, в которой чаще всего нет никакой информации об оборудовании. Далее техник откликаясь на данную заявку, начинает искать информацию по оборудовании если это возможно из информации в заявке, теряя время на поиск информации или начинает спрашивать в заявке пользователя о том какое именно оборудование сломалось и что с ним произошло, также теряя время. Пользователю будет сложно ответить на 8

вопросы тех поддержки по заявке если сломался именно его компьютер. Основной проблемой в данном процессе является то, что по данной заявке много времени уйдет на уточнение подробностей и нахождение информации об оборудовании. Так как заявки и информация об оборудовании находятся в разных системах. Для исправления этого, необходимо разработать мобильное приложение по созданию и взаимодействию с заявками. На рисунке 1 представлен схема бизнес-процесса с использованием мобильного приложения сервиса заявок. Как можно понять из схемы, были исключены проблемы с человеческим фактором, а именно нехваткой информации об оборудовании. Решением этой проблемы будет уведомления и механизм подтверждения условий заявки в цепочке процесса, благодаря которым можно сократить излишние затраты по времени на выполнение заявки и времени людей, задействованных в этом бизнес-процессе. Таким образом можно оптимизировать данный процесс. Также процесс заполнения оборудования в заявке автоматизирован при помощи сканирования штрихкода расположенного на оборудование, данный штрихкод представлен в общепризнанного стандартa линейного штрихкода CODE 128, при котором определяется какое именно оборудование было выбрано и принадлежность его к определённому отделению. Мобильное приложение также поможет сократить муда, а именно сократить ожидание из-за простоя по неисправностям оборудования и сократить лишние движения связанные с созданием заявок и последующей с ней работой. 9

Рисунок 1. Бизнес-процесс с ролями участников 10

1.3 ОБЗОР ИСТОЧНИКОВ ЛИТЕРАТУРЫ Такие проблемы разрабатывается в научной литературе уже достаточно много времени, всё это из-за того, что подобные проблемы всегда были актуальными. Потому что нельзя себе представить современное общество без такого явления как организация ИТ-услуг и логистика. Ксиаоюн Танг, Юки Тодо в своем исследовании по внедрению служб поддержки говорят о том, что одним из ключевых фактором для достижения успеха в реализации ITSM, являлся создание систем справочных столов (Service Desk) [12]. Он предназначен для обеспечения единой точки контакта (SPOC) для удовлетворения потребностей пользователей и ИТ-специалистов в области связи, а также для достижения целей как Заказчика, так и поставщика ИТ-услуг. Служба поддержки обрабатывает инциденты и запросы на обслуживание, а также предоставляет пользователям интерфейс для других видов деятельности ITSM, таких как: • Управление происшествиями. • Управление проблемами. • Управление конфигурацией. • Управление изменениями. • Управление релизами. • Управление уровнем сервиса. • Управление доступностью. • Управление мощностями. • Финансовый менеджмент. • Управление непрерывностью ИТ-услуг. • Управление безопасностью. Миссия Службы Поддержки должна быть центральной точкой контакт между пользователем и поставщиком ИТ-услуг. 11

Также они приходят в таким выводам, что хорошая служба поддержки повышает удовлетворенность клиентов компании, эффективно и результативно взаимодействует с каждым конечным пользователем. Филип Ф., Мараску-Клейн В, рассматривают полезность внедрения метода 5S который расшифровываются как [2]: 1. Сортировка 2. Соблюдение порядка 3. Содержание в чистоте 4. Стандартизация 5. Совершенствование Этот метод внедряется для улучшения рабочих мест, повышения качества рабочей среды, устранения или уменьшения ошибок, для поддержания производительности производственного процесса. Преимущества, которые мы можем получить, внедрив метод 5S, заключаются в следующем: разработка качественной рабочей среды, устранение ошибок, ошибок и проблем визуального характера, сокращение потерь, сокращение времени ожидания и поиска, прозрачность и четкость рабочего процесса и рабочих мест, установить стандарты, безопасность труда и эргономичность всех сотрудников. Теодор Станк, Скотт Келлер и Дэвид Клосс предлагают рассмотреть более глубокое исследование взаимосвязи между интеграцией логистики и производительностью [3]. Авторы приходят к такому заключению что улучшенная интеграция логистической цепочки поставок приводит к улучшению операционных показателей. Чаэ Ан и Ханджорк Фромм приводят пример недавних, относительно выхода книги, разработках по управлению логистикой для запасных частей в компании IBM. Также большое внимание уделяется такому понятию как «Проектирование сервисных сетей», а именно как можно распределить запасные части по всей сети отделений, при этом снижая общие расходы на хранение, учет и отправку запчастей [4]. Схема с представленной стратегией 12

представлена на рисунке 3. Главным с схеме является Хаб (Hub), в структуре IBM было 4 Хаба, которые соединялись между собой, а также со складом страны (Country Stock Room, CSR), которые в свою очередь соединялись с региональным офисом (Region Offices, RO), далее следовал филиалы (Branch Offices, BO) и при необходимости со станциями поддержки (Support Stations). Рисунок 3. Географическая сеть сервиса Структура центров “Мои документы” тюменской области не такая большая, поэтому можно ограничится Хабом, региональными офисами и филиалами. В заключении, авторы приходят к таком выводу что логистические сервисы по востребованию необходимы для сокращения 13

издержек по простою оборудования, а также для сокращения расходов по хранению, закупке, учету и отправке запасных частей. Ерхан Кутаноглу и Диви Лохайя представляет модель для понимания комплексной проблемы с запасами и транспортировкой для многоуровневой системы логистики запасных частей для нескольких объектов с временными ограничениями уровня обслуживания [5]. В заключении автор приходит к выводу что запасные части характеризуются как детали с крайне редкими и низкими спросом и высокими затратами. Репин В. В., Елиферов В. Г проводят анализ создания и реорганизациии бизнес-процессов и выделяют следующие этапы [6]: 1. Подготовительный; 2. Моделирование и анализ бизнес-процессов «как есть»; 3. Моделирование бизнес-процессов «как должно быть»; 4. Подготовка и внедрение изменений в процессах, построение процессной системы управления организацией. На подготовительном этапе создаются необходимые условия и предпосылки для успешного выполнения проекта. Основным результатом подготовительного этапа является формирование команды руководителей и сотрудников организации, так называемой «критической массы»), четко представляющих цели проекта и последовательность шагов по их достижению. Основным результатом второго этапа являются модели бизнеспроцессов, построенные в соответствии с требованиями организации, и данные анализа этих моделей. Полученные модели процессов используются для дальнейшей работы по созданию регламентирующих документов и реорганизации бизнес-процессов. Третий этап предназначен для построения моделей бизнес-процессов «как должно быть». В методиках, предлагаемых различными авторами и фирмами, подразумевается, что на третьем этапе должны быть сформированы новые варианты моделей бизнес-процессов. Однако исходя из опыта 14

выполнения проектов можно утверждать, что такой подход на практике не работает. Дело в том, что понимание «как должно быть» формируется у сотрудников (и привлеченных консультантов) постепенно, по мере описания и регламентации бизнес-процессов, выполнения работ по анализу процессов и осознания того, что, собственно, в организации «не так» и почему. На четвертом этапе проводится подготовка к внедрению процессной системы управления. Осуществляется выбор приоритетов при изменении процессов оцениваются на основе рассчитанной требуемые ресурсы, экономической проводится эффективности, оценка рисков и компенсационных мероприятий, выполняются подготовительные работы с персоналом организации. В заключении Результатом проекта должны стать новые, более эффективные бизнес-процессы, комплект документации, регламентирующей процессы, а также организационная структура, соответствующая новым процессам. Алесинская интеграции Т.В. в логистической своем исследовании деятельности, а затрагивает именно проблему фрагментацию логистической деятельности. Ведь разные отделы логистики заинтересованы порой в собственных совершенно разных целях. Например, отдел снабжения ищет надежных поставщиков, транспортный отдел стремится к полной загрузке транспортных средств, отдел сбыта заинтересован в быстром реагировании на спрос, производство заинтересовано в бесперебойной работе, отдел складирования старается снизить запасы. Все эти цели сами по себе несомненно важны для эффективного функционирования каждого подразделения в отдельности, но по объективным причинам они, как правило, конфликтуют между собой. Основными недостатками фрагментированной логистики внутри предприятия являются [7]: 1. Конфликт целей различных подразделений одного предприятия; 2. Затрудняется и подразделениями; замедляется 15 обмен информацией между

3. Плохая координация деятельности различных подразделений; 4. Излишние запасы всех видов; 5. Отсутствие информации по общим логистическим издержкам и как следствие отсутствие возможности управления ими; 6. Снижение эффективности деятельности предприятия. В заключении автор приходит к выводу что всегда существуют ситуации, когда сокращение затрат на один вид деятельности влечет увеличение затрат на другой, но при этом общие логистические издержки сокращаются. Целенаправленное использование эффекта снижения общих логистических издержек возможно только в интегрированной логистике. Романенкова О. Н. в своей статье говорит о важном значении использования глобальной навигационной системы GPS, которая позволяет [8]: • Обладать наиболее точной информацией о местонахождении транспортного средства; • Контролировать в режиме реального времени состояние и маршрут транспортного средства; • Вести статистику и проводить анализ перемещения и состояния автомобиля и перевозимого груза за любой период; • Иметь возможность поддерживать связь с контролируемым объектом (водителем); • Обеспечивать автоматизированный контроль за рейсами и оперативное управление грузовыми перевозками; • Проводить координацию экипажей транспортных средств и организацию их взаимодействия; • Максимально оптимизировать и обезопасить процесс перевозки. Благодаря подобному мониторингу за транспортными средствами участвующими в перевозках, можно сократить расходы на транспортировку, а также вести контроль за выполнением перевозок. 16

Иванов Р. В. Маятин А. В. Михайленко А. Е. в своем исследовании выделяли следующие проблемы в организациях которых нет четкого регламента работы службы технической поддержки (СТП) [9]: • При возникновении проблемы пользователю приходится самостоятельно определять ее причину, чтобы сообщить в СТП. • Информация о проблеме передается, как правило, устно (по телефону) и должна быть повторена для каждого нового специалиста, подключившегося к ее решению. • Отсутствуют средства структурирования и детальной фиксации проблемы (шаблоны и пр.). • Диспетчирование и контроль прохождения заявки на обслуживание выполняются, как правило, на уровне межличностных отношений, соответствующие средства информационной поддержки отсутствуют или не используются. В подобной этой модели СТП время и средства, затрачиваемые на устранение проблемы, неоправданно велики, что во многом связано с наличием в СТП факторов неопределенности различной природы. Именно изза этого появляется необходимость в полноценной системе обработок заявок, связанных со сложными техническими системами. 17

ГЛАВА 2. ИНФРАСТРУКТУРА СИСТЕМ МФЦ 2.1 ОПИСАНИЕ ИНФРАСТРУКТУРЫ МФЦ Для создания приложения, которое ускорить и облегчить процесс создания и взаимодействия с заявками, необходимо изучить инфраструктуру информационных систем ГАУ ТО «МФЦ», чтобы понять откуда можно взять исчерпывающую информацию об оборудовании и какие есть инструменты для создания заявок. 2.2 СИСТЕМА ЗАЯВОК OTRS Система заявок OTRS (Open-Source Ticket Request System) представляет собой пакет управления службами (Information Technology Service Management (ITSM)), который включает в себя создание билетов, автоматизацию рабочих процессов и уведомление, а также широкий спектр настраиваемых функций. Он используется службами управления ИТуслугами, обслуживания клиентов и корпоративной безопасности, чтобы лучше структурировать свои коммуникации и задачи. Для предприятий небольшого размера в которой может быть 1-3 сотрудников тех поддержки, необходимости в полноценной системе заявок нет, они могут вести переписку по электронной почте или отвечать на телефонные звонки. Однако в МФЦ штаб рядовых сотрудников и штат сотрудников поддержки намного больше, также нельзя забывать о множестве отделений в Тюмени и по всему югу Тюменской области. Поэтому без полноценной системы заявок работа МФЦ не представляется возможной. Также не маловажным фактором является то, что при помощи системы заявок можно вести оценку качества работы службы технической поддержки, такие как время первого ответа, среднее время закрытия заявки, количество решенных заявок и так далее. Работу отдела технической поддержки можно оценивать по KPI (Key Performance Indicators), эти показатели будут бесполезными если они не будут объективными и измеримыми. 18

В работе предприятия используется 6-ая версия, OTRS Community Edition, которая является последней версией с открытым кодом на Perl. Последующие версии перестали быть программным обеспечением с открытым кодом и обрели платную облачную версию, последней с которых является 8-ая. Также переход на новую версию продукта не происходит из-за того, что лучше иметь данные, среди которых могут быть конфиденциальные, на своем выделенном сервере. Доступ к системе заявок происходит по средством учетной записи службы каталогов Active Directory. В зависимости от вашей должности вы можете быть зарегистрированы в системе заявок как Клиент или как Агент. Клиент может просматривать собственные заявки, создавать и редактировать заявки, изменять настройки своей учетной записи. Агент может отвечать на вопросы клиентов, создавать новые заявки для клиентов и агентов, создавать заявки на основе телефонных звонков клиентов, писать и редактировать записи FAQ-модуля, редактировать данные клиентов и так далее. На рисунке 4 представлен интерфейс главной страницы агента. На рисунке 5 представлен интерфейс главной страницы клиента. Рисунок 4. Интерфейс главной страницы агента 19

Рисунок 5. Интерфейс главной страницы клиента Создать заявку можно через веб-интерфейс системы заявок. При создании заявки выбирается процесс, а именно вид заявки, по которой изменяется форма заявки в зависимости от процесса. Агент может выбрать отдельную учетную запись клиента, от которой будет создана заявка. Клиент не имеет такой возможности, а значит все его заявки будут созданы от его имени. На рисунке 6 представлен интерфейс процесса создания заявки по проблеме с оборудованием от лица агента. Рисунок 6. Процесс создания заявки 20

У OTRS есть так называемый универсальный интерфейс (Generic Interface) [10], он состоит из многоуровневой структуры, которая позволяет OTRS взаимодействовать с другими системами через веб-сервис. Это сообщение может быть двунаправленным: • OTRS как поставщик (Provider): действует как сервер, который прослушивает запросы от внешней системы, обрабатывает информацию, выполняет запрошенное действие и отвечает на запрос. • OTRS как запрашиваемая сторона (Requester): собирает информацию, посылая запрос к Внешней системе, и ожидает ответа. Благодаря этому интерфейс появляется возможность создать запросы на заявки. Уровни универсального интерфейса представляет из себя: 1. HTTP-запрос • OTRS получает HTTP-запрос и передает его через слои. • Модуль провайдера отвечает за выполнение и контроль этих действий. 2. Транспортная Сеть • Сетевой транспортный модуль декодирует данные запроса и отделяет имя операции от остальных данных. • Название операции и данные операции будут возвращены поставщику. 3. Внешние данные • Данные, отправленные из удаленной системы. 4. Преобразование • Данные преобразуются из формата внешней системы во внутренний формат данных OTRS так, как это указано в конфигурации отображения для этой операции. 21

• Преобразованные данные возвращаются обратно поставщику. 5. Внутренние Данные • Данные как преобразованы и подготовлены для передачи в операцию 6. Операция • Принимает и проверяет данные. • Осуществляет контроль доступа пользователей. • Выполняет действие. На рисунке 7 наглядно представлены уровни интерфейса. Рисунок 7. Уровни универсального интерфейса 22 универсального

Основными операциями являются создание, обновление, получение информации и закрытие заявки. В имеющейся версии OTRS доступны только протоколы SOAP (Simple Object Access Protocol) и REST (Representational State Transfer). Каждый способ имеет различные параметры конфигурации для настройки, и они могут использовать различные модули внешнего интерфейса для их настройки. В разрабатываемом приложении OTRS будет использоваться как поставщик (Provider), при создании новых и изменениях существующих заявок. 2.3 СИСТЕМА УЧЕТА ОБОРУДОВАНИЯ СУО – она же система учета оборудования, является продуктом, разработанным в ГАЦ ТО «МФЦ». В этой системе хранится информация о всем оборудовании, используемом в учреждении, с информацией о том, где именно находится оборудование с точностью до кабинета, весь жизненный цикл оборудования, также все оборудование закреплено за материально ответственными лицами. Осуществляется учет перемещений оборудования, а также отправлений оборудования в сервисный центр. Система написана на языке программирования Kotlin в качестве фреймворка бэкенда использован Spring. Как основной инструмент разработки в ГАУ ТО «МФЦ». В качестве фреймворка фронтенда использован React. Все данные системы хранятся в СУБД PostgreSQL. Доступ к системе учета оборудования происходит по средством учетной записи службы каталогов Active Directory. На рисунке 8 представлен интерфейс главной страницы системы учета оборудования. 23

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

Рисунок 9. Пример отчета по перемещениям оборудования Взаимодействие фронтенда и бэкенда происходит при помощи REST запросов. 25

ГЛАВА 3. РАЗРАБОТКА МОБИЛЬНОГО И СЕРВЕРНОГО ПРИЛОЖЕНИЙ 3.1 ОПИСАНИЕ ТЕХНОЛОГИЙ И СРЕДСТВ РАЗРАБОТКИ В качестве среды разработки для мобильного приложения использована Android Studio 4.0. Мобильное приложение, которым будут пользоваться работники МФЦ, разработано на языке программирования Kotlin. Это кроссплатформенный, статически типизированный язык программирования общего назначения с выводом типов. Kotlin предназначен для полного взаимодействия с Java, а версия его стандартной библиотеки JVM зависит от библиотеки классов Java. Требования к мобильному устройству: • ОС Android версии 5.0 или выше • Камера с разрешением от 4 мегапикселей • Доступ в интернет В качестве среды разработки для серверного приложения использована IntelliJ IDEA 2020.1.1. Серверное приложение разработано на языке программирования Kotlin, с использованием универсального фреймворка Spring. Выбор пал на данные технологии из-за того, что большинство продуктов разработанных в учреждении также используют эту связку. Также к удобствам этой связки можно отнести то, что Spring объединяет свою коллекцию отдельных инструментов, которые позволяют добиться высокой функциональности при совместном их использовании. Для взаимодействия различных сервисов между собой будет использоваться REST из-за прозрачности системы взаимодействия, простоты и надежности. это стиль архитектуры программного обеспечения для построения распределенных масштабируемых веб-сервисов. Расшифровывается как «Representational State Transfer». Одно из этих правил гласит, что при обращении к определенному адресу, вы должны получать определенный набор данных (ресурс). 26

3.2 ОСОБЕННОСТИ ИНТЕГРАЦИИ С ИМЕЮЩИМИСЯ СЕРВИСАМИ ПРЕДПРИЯТИЯ Разрабатываемое серверное приложения будет взаимодействовать с тремя действующими в учреждении сервисами: • Служба каталогов Active Directory – служит единым хранилищем данных для быстрого доступа к данным для всех пользователей и контролирует доступ для пользователей на основе политики безопасности каталога. • СУО (Система учета оборудования) – разработанная в учреждении система, в которой хранится информация о всем оборудовании, используемом в учреждении, с информацией о том, где именно находится оборудование с точностью до кабинета, также все оборудование закреплено ответственными лицами. за ответственными Осуществляется учет материально перемещений оборудования, а также отправлений оборудования в сервисный центр. • OTRS (Open-source Ticket Request System) – открытая система обработки заявок. Она используется службами управления ИТ-службами, службами поддержки клиентов и корпоративной безопасности для лучшей структуризации взаимодействия и задач. Это сервис управления службами, который индивидуально оформляет заявки, автоматизирует рабочий процесс и уведомляет вместе с широким спектром настраиваемых функций. Эти системы работают в учреждение и зарекомендовали себя как хорошие инструменты в своей сфере. Итоговая схема системы со всеми компонентами, приведена на рисунке 10. 27

Рисунок 10. Общая схема системы 3.3 АУТЕНТИФИКАЦИЯ Аутентификация - проверка подлинности пользователя путём сравнения введённого им пароля (для указанного логина) с паролем, сохранённым в базе данных пользовательских логинов. Без нее сложно представить современный сервис. В данном сервисе, пользователь имеет право на просмотр, добавление, изменение и удаление данных только если у него есть учетная запись и соответствующие права его роли. У каждого пользователя в приложении есть своя роль. Из них представлены: • Роль пользователя – базовая роль нового пользователя, имеет права получать информацию об определенном оборудовании по инвентаризационному номеру, добавлению заявок и просмотра состояния только своих заявок. 28

• Роль техника – имеет право просматривать все оборудование, но не изменять, удалять или добавлять его. Также имеет право видеть и изменять все заявки пользователей в своем отделении. • Роль администратора – имеет полные права на добавление, изменение, удалении данных об оборудовании, а также просмотр и изменение заявок во всех отделениях. В учреждении уже долгое время используется служба каталогов корпорации Microsoft, Active Directory, было принято решение использовать её, так как в ней уже настроены групповые политики для обеспечения единообразия настройки пользовательской рабочей среды. Для аутентификации в разрабатываемом мобильном приложении в имеющихся сервисов работающих со службой каталогов Active Directory пары логин пароля, данной системы каталогов, благодаря такому решению остается возможность использования единой учетной записи в учреждении, что позволяет пользователям не запоминать множество логинов и паролей, для различных приложений и сервисов, а также облегчает настройку групповых политик для отдела информационных технологий. По протоколу HTTPS, на сервер приложения, который доступен из внешнего интернета, клиент отправляет запрос, в теле которого находятся данные о аутентификации, а именно логин и пароль пользователя. В ответ серверное приложение отправляет мобильному приложению JSON Web Tokenн токен стандарта JWT (JSON Web Token), который состоит из трех частей: заголовка (header), полезной нагрузки (payload) и подписи или данных шифрования. Первые два элемента — это JSON объекты определенной структуры. Третий элемент вычисляется на основании первых и зависит от выбранного алгоритма, в данном случае в качестве алгоритма был выбран HS512. По соображениям безопасности на рисунке 11 представлен вид токена, который уже истек, и он уже не может быть использован. В полезной нагрузке хранится логин пользователя, время создания и окончания действия токена, 29

активирована ли четная запись у пользователя и его роли. Как видно у пользователя «admin» есть роль пользователя и администратора. Рисунок 11. Зашифрованный и расшифрованный вид JWT токена При помощи этих данных ведется проверка в веб приложении и мобильном приложении, если учетная запись не активирована, то пользователь не получит доступ к данным, благодаря ролям пользователь сможет в приложения видеть только возможности доступные ему. 3.4 СЕРВЕРНОЕ ПРИЛОЖЕНИЕ Серверное приложение соединяет мобильное приложение и сервисы предприятия, а именно систему учета оборудования, систему заявок OTRS, службу каталогов Active Directory. Для виртуальной машины, содержащей серверное приложение, было выделено: • 1 ядро ЦП • 1 ГБ ОЗУ • 5 ГБ ПЗУ В качестве архитектуры была выбрана Многозвенная клиент-серверная архитектура. Она была выбрана для обеспечения защиты уже существующих и используемых сервисов МФЦ и обеспечения (совместной) бесперебойной работы указанных сервисов. Серверное приложение необходимо для того, чтобы можно было открыть для внешнего интернета только один ресурс, 30

вместо трех отдельных если бы система разрабатывалась без серверного приложения. Также это повышает безопасность от утечки данных или взлома. Так, например для взаимодействия с системой заявок OTRS при помощи REST запросов для создания изменения и удаления заявок используется базовая аутентификация (Basic authentication), с использованием одной учетной записи. Если хранить эту заголовок аутентификации в приложении, то его легко можно достать из собранного или даже установленного мобильного приложения. И воспользоваться этими данными для корыстных целей. Для взаимодействия мобильного и серверного приложения, а также серверного приложения и системы учета оборудования и системы заявок использоваться REST запросы, из-за прозрачности системы взаимодействия, простоты и надежности. Это стиль архитектуры программного обеспечения для построения распределенных масштабируемых веб-сервисов. Таким образом можно сократить расход трафика мобильного интернета, преобразовывая и удаляя не нужные данные из ответов, которые отправляют сервисы. Также ответ системы учета оборудования об определенном оборудовании, не представлял полную информацию по оборудованию, а лишь ссылки на идентификаторы различных параметров, ответ на запрос об оборудовании представлен на рисунке 12. 31

Рисунок 12. Результат запроса из системы учета оборудования Таким образом для получения полной информации об оборудовании, которую можно прочитать, необходимо сделать ещё 5 запросов с систему учета оборудования. Если бы серверного приложение не было сделано, то трафик через мобильное приложение возрос, а благодаря тому, что серверное приложение и система учета оборудования находятся в одной сети, влияние трафика можно опустить. В качестве СУБД для серверного приложения была выбрана PostgreSQL из-за надёжных механизмов транзакций и репликации, а также из-за легкой расширяемости. Также не маловажным аспектом было то, что базы данных в учреждении, с которыми будет взаимодействие также используют PostgreSQL. В базе серверного приложения хранить только данные об пользователях и их ролях. Информация об оборудовании хранится в базе системы учета оборудования. Схема таблицы с пользователями представлена на рисунке 13. 32

Рисунок 13. Схема таблицы «Пользователи» В данной таблице: • id – идентификатор • username – логин пользователя • password – пароль пользователя, хранящийся в зашифрованном виде • email – почта пользователя • branch – отделение в котором работает пользователь • enabled – активна ли учетная запись пользователя • name – фамилия, имя и отчество пользователя • last_login – время последнего входа пользователя • deleted – деактивирована ли учетная запись пользователя 33

3.5 МОБИЛЬНОЕ ПРИЛОЖЕНИЕ Мобильное приложение для устройств на операционной системе Android, было написано на языке программирования Kotlin. Также, как и в веб приложении пользователю при запуске приложения необходимо войти в сервис, используя свой логин и пароль. Форма входа в приложение представлена на рисунке 14. Рисунок 14. Форма входа пользователя в систему заявок Авторизация проходит сервер приложения, который в свою очередь подключен к службе каталогов Active Directory, что позволяет использовать логин и пароль от учетной записи, созданной в учреждении. Если комбинация логина и пароля неверны, приложение выдаст предупреждение об этом, также если учетная запись пользователя не активирована, он не сможет войти в сервис. При успешном входе в сервис, пользователь увидит свой вид интерфейса в зависимости от роли пользователя. Обычному пользователю будет доступно 34

добавление заявки и просмотр информации по своим прежде отправленным заявкам. Пользователю с ролью «Техника», помимо прав обычного пользователя имеет прав видеть все заявки отделения, за которым он закреплён. Пользователь с ролью «Администратора» имеет все предыдущие права, а также имеет право смотреть все заявки со всех отделений, а также может добавить новое оборудование в систему. Интерфейс главного меню для различных пользователей представлен на рисунке 15. Рисунок 15. Главное меню приложение у пользователей с разными ролями После перехода в меню добавления заявки, пользователь увидит интерфейс, вверху которого транслируется изображение с камеры устройства возможностью включения вспышки устройства в качестве фонарика для того, чтобы можно было легко отсканировать штрихкод расположенный на всем оборудовании в учреждении. Он обычно расположен на задней части устройства. Штрихкод выполнен по стандарту Code 128. Который позволяет делать наклейки достаточно маленького размера. При сканировании штрихкода, на сервер приложения отправляется REST-запрос, с полученным при сканировании инвентаризационным номерам, который отправляется в систему учета оборудования для того, чтобы получить в ответе информацию 35

о оборудовании, в формате JSON объекта. Пример полученной информации представлен на рисунке 16. Рисунок 16. Результат запроса об оборудовании из сервера приложения Полученные данные о оборудовании добавляются в список к заявке. Также для удобства пользователя и для ускорения обработки заявки, предусмотрены типовые виды классификации неполадок. Необходимость в классификации заявок, объясняется тем, что в зависимости от типа проблемы, она будет направлена определённым специалистам. Время создания заявки и логин пользователя, создавшего заявку, заполняется Интерфейс добавления заявки представлен на рисунке 17. 36 автоматически.

Рисунок 17. Интерфейс добавления заявки Созданная заявка отправляется на сервер приложения и после этого в систему заявок OTRS, REST запросом, содержащим всю информацию по заявке. После добавления заявки пользователь может отслеживать за статусом в меню последних заявок. Обычный пользователь видит только свои заявки, «Техник» все заявки в отделении, «Администратор» видит заявки со всех отделений. Интерфейс с последними заявками от обычного пользователя представлен на рисунке 18. 37

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

ЗАКЛЮЧЕНИЕ В рамках выполнения выпускной квалификационной работы была изучена архитектура информационной системы ГАУ ТО «МФЦ». Определены системы и подходы взаимодействия с ними для получения необходимой информации об оборудовании. Изучен фактический процесс исполнения заявок по неисправностям оборудования. Разработано мобильное приложение для устройств на операционной системе Android и серверное приложение, которые позволяют ускорить процесс создания и взаимодействия с заявками по обслуживанию оборудования. Идет подготовка разработанных сервисов в работу центров “Мои документы”. 39 к интеграции

СПИСОК ЛИТЕРАТУРЫ 1. Xiaojun Tang, Yuki Todo A Study of Service Desk Setup in Implementing IT Service Management in Enterprises [Электронный ресурс], режим доступа: http://www.repository.embuni.ac.ke/bitstream/handle/123456789/1672/Persona l%20Financial%20Planning%20for%20College%20Graduates.pdf?sequence=1 &isAllowed=y 2. Filip F.,Marascu-Klein V, The 5S lean method as a tool of industrial management performances [Электронный ресурс], режим доступа: https://iopscience.iop.org/article/10.1088/1757-899X/95/1/012127/pdf 3. Theodore P. Stank, Scott B. Keller, David J. Closs Performance Benefits of Supply Chain Logistical Integration // Transportation Journal, 2002 [Электронный ресурс], режим доступа: https://www.jstor.org/stable/20713491 4. Chae An, Hansjörg Fromm Supply Chain Management on Demand – Springer, 2005 5. Erhan Kutanoglu, Divi Lohiya Integrated inventory and transportation mode selection: A service parts logistics system // Transportation Research Part E: Logistics and Transportation Review, 2008 [Электронный ресурс], режим доступа: https://www.sciencedirect.com/science/article/pii/S1366554507000294 6. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. // М.: РИА "Стандарты и качество", 2008. - 252 с. 7. Алесинская Т.В. Основы логистики. Общие вопросы логистического управления. Таганрог: Изд-во ТРТУ, 2005. 121 с. 8. Романенкова О. Н. Организация информационных потоков в управлении логистикой на автомобильном транспорте // Экономика. Налоги. Право, 2014. 40

9. Иванов Р.В. Маятин А.В. Михайленко А.Е. Моделирование процесса обработки заявок в службе технической поддержки сложных технических систем // Научно-технический вестник информационных технологий, механики и оптики, 2007 10.OTRS Generic Interface [Электронный ресурс], режим доступа: https://doc.otrs.com/doc/manual/admin/6.0/en/html/genericinterface.html 41