СОДЕРЖАНИЕ ВВЕДЕНИЕ .................................................................................................................. 3 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ .................................................................. 5 1.1 Системный анализ предметной области ............................................................. 6 1.1.1 Роли системы ...................................................................................................... 8 1.1.2 Описание входных и выходных информационных потоков .......................... 9 1.1.3 АРМ в день.......................................................................................................... 9 1.1.4 Модернизация ................................................................................................... 10 1.1.5 Увольнение ........................................................................................................ 10 1.1.6 Остальные кейсы ...............................................................................................11 1.2 Обзор выбранного инструментария разработки .............................................. 11 1.3 Обзор продуктов аналогов.................................................................................. 13 1.4 Требования к системе в целом ........................................................................... 15 1.4.1 Системные и бизнес требования .................................................................... 15 1.4.2 Требования к порталу ...................................................................................... 16 1.5 Мероприятия по внедрению системы в эксплуатацию ................................... 18 1.6 Выделение системных статусов......................................................................... 19 1.7 Мероприятия по сопровождению системы ...................................................... 20 1.8 Выводы по первому разделу .............................................................................. 23 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ........................... 24 2.1 Схема в нотации IDEF0 ...................................................................................... 24 2.2 Проектирование бизнес-процесса системы...................................................... 27 2.3 Описание процесса системы с помощью вариантов использования ............. 29 2.3.1 Описание процессов «АРМ в день» через варианты использования ......... 29 2.3.2 Описание процессов «Модернизация» через варианты использования ..... 41 2.3.3 Описание процессов «Увольнение» через варианты использования.......... 50 2.3.4 Описание процессов «Запрос на вывоз» через варианты использования .. 58 2.3.5 Описание процессов «Внеплановая потребность» через варианты использования ............................................................................................................ 63 Москва, 2023 2.3.6 Описание процессов «Переезд» через варианты использования ................ 71 2.4 Выводы по второму разделу ............................................................................... 75 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ........................................ 76 3.1 Настройка CMS Strapi ......................................................................................... 76 3.2 Автоматизация с помощью технологии RPA.................................................... 83 3.2.1 Создание заявок в системе .............................................................................. 83 3.3 Написание PowerShell-скриптов ........................................................................ 84 3.4 Тестирование системы ........................................................................................ 86 3.5 Тест-кейс 1. АРМ в день. Успешная установка нового оборудования........... 89 3.6 Тест-кейс 2. АРМ в день. Заявка отменена. ...................................................... 90 3.7 Тест-кейс 3. АРМ в день. Пользователь не ответил на звонок ВП. ............... 91 3.8 Тест-кейс 4. АРМ в день. Невозможно установить оборудование................. 93 3.9 Выводы по третьему разделу ............................................................................. 95 ЗАКЛЮЧЕНИЕ ......................................................................................................... 96 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ................................................ 99 Тест-кейс 1. Модернизация. Успешная модернизация оборудования................ 119 Тест-кейс 2. Модернизация. Заявка отклонена пользователем........................... 120 Тест-кейс 3. Модернизация. Заявка не подтверждена пользователем ............... 121 Тест кейс 4. Модернизация. Невозможно установить оборудование ................ 123 Тест-кейс 1. Возврат. Успешный возврат оборудования ..................................... 125 Тест-кейс 2. Возврат. Сотрудник не подтвердил заявку ...................................... 126 Тест-кейс 3. Возврат. Оборудование не возвращено ........................................... 127 Тест-кейс 1. Внеплановая потребность. Успешная установка оборудования ... 129 Тест-кейс 2. Внеплановая потребность. Оборудование не установлено ........... 130 ПРИЛОЖЕНИЕ 1 — Описание процессов «Прочее» ПРИЛОЖЕНИЕ 2 — Описание процессов «Диагностика» ПРИЛОЖЕНИЕ 3 — Остальные тест-кейсы 2 ВВЕДЕНИЕ В нынешних реалиях, когда ничто не стоит на месте, а темп жизни постоянно ускоряется, неоспоримо важно успевать за изменениями и вовремя к ним адаптироваться. Внедрение разрабатываемой системы принесет компании огромную пользу. В ходе оптимизации и автоматизации жизненного цикла оборудования, организация сможет увеличить продуктивность на всех затронутых этапах, высвободить время у сотрудников, избавив их от рутинной работы, а также задать высокий стандарт обеспечения сотрудников автоматизированными рабочими местами. Благодаря автоматизации, также можно будет исключить из процесса большое количество ошибок, сопровождаемых человеческим фактором. Разработанная система будет предоставлять интерфейс специалистам, связанным с процессами выдачи, забора и модернизации оборудования, а также сопровождать эти процессы. Для достижения поставленных целей следует выделить следующие задачи: 1. Ознакомится с предметной областью, а также стандартами обеспечения сотрудников рабочими местами; 2. Провести анализ уже имеющегося в компании процесса и определить варианты по его оптимизации; 3. Спроектировать схемы и диаграммы в различных методологиях для оптимизации бизнес-процесса; 4. Спроектировать инфологическую модель данных и реализовать таблицу статусов объектов системы; 5. Описать сценарии взаимодействия будущей системы с помощью use- case (вариантов использования) 6. Реализовать пользовательский интерфейс; 3 7. Спроектировать и развернуть контейнер для взаимодействий компонентов внутри архитектуры; 8. Настроить роботов, для работы с внутренними компонентами организации; 9. Реализовать работу голосового помощника. Разработанная система поможет оптимизировать деятельность разъездных специалистов, оптимизировать и сократить всю рутинную работу, переложив её на Робот и программное обеспечение. 4 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ МГТС [1] – крупнейший в Европе оператор, предоставляющий телекоммуникационные услуги по всей Москве. Управление ПАО «МГТС» осуществляет персонально генеральный директор, которому подчиняются подразделения и заместители общества. В ПАО «МГТС» осуществляется налоговый, управленческий, а также бухгалтерский учет разного рода хозяйственных операций. К тому же документооборот в ПАО «МГТС» ведется на основании законов России, устава ПАО «МГТС», а также прочих распорядительных документов. Результаты деятельности общества отражаются в периодической регулярной отчетности, представляемой в сроки и объемах установленные ПАО «МГТС». Главный бухгалтер возглавляет подразделение бухгалтерии. Без подписей главного бухгалтера никакие расчетные или денежные документы, обязательства не считаются действительными и, в результате этого, не должны исполнятся другими отделами. Работа маркетингового отдела направляется непосредственно на продвижение коммуникационных услуг, которые предоставляются ПАО «МГТС». При этом производится рекламная продукция, поддержка сайта компании. Ремонтный отдел предназначается для проведения технического осмотра и ремонта аппаратного обеспечения компании. В штат сотрудников отдела входят 8 инженера-техников и 3 инженер-программиста. Стоит отметить, что эти работники используют одни с самых современных тестирующих приборов и установок для диагностики оптоволоконной сети ПАО «МГТС». 5 Отдел кадров реализует работу по подбору персонала, их аттестации, выполняет проверку квалификации и т.д. Работа ИТ подразделения направлена на: • поддержание бизнес процессов, для минимизации простоев и предупреждения аварий; • анализ, внедрение и контроль развития информационных систем; • сопровождение информационных систем; • предоставление и контроль доступа к информационным ресурсам организации; • материально-техническое обеспечение организации средствами автоматизации и связи; • ведение технологической документации; Таким образом, можно сделать вывод, что исследуемое предприятие реализует свою деятельность на основе проектного управления, что позволяет выделить ключевые виды деятельности в приоритетные проекты и обеспечивает их реализацию за счет структурных подразделений, которые взаимодействуют на уровне бизнес-процессов. В ходе прохождения практики был выделен отдел организационной структуры развития и сопровождения пользовательских сервисов, в котором было изучено: • Решение поступивших заявок технической поддержки пользователей; • Автоматизация бизнес-процессов по средствам технологии RPA; • Был проведен анализ бизнес-процессов, требующих автоматизации. 1.1 Системный анализ предметной области Автоматизированная информационная система «Жизненный оборудования», является объектом автоматизации, далее АО. 6 цикл В ПАО «МГТС» есть стандарты и правила обеспечения сотрудников оборудованием. Согласно СТ-042 «Оснащение автоматизированных рабочих мест сотрудников Компании» можно выделить четыре основные конфигурации оборудования: 1. КК1 – Моноблок с монитором 27 дюймов, используется в частных случаях в основном дизайнерами, предоставляется по запросу; 2. КК2 – Массовая конфигурация, используется штатными сотрудниками (бухгалтеры и другие офисные работники); 3. КК3 – Производительная конфигурация, предоставляется разработчикам, предоставляется по запросу; 4. КК4 – компактная конфигурация (Ноутбуки), предоставляется по запросу. Жизненный цикл разрабатываемая система оборудования позволит тесно — объект автоматизации, взаимодействовать с уже работающими системами внутри организации, а именно: 1. OeBS [2] — интегрированный комплекс прикладного программного обеспечения, способствует ведению документооборота внутри компании; 2. Perfmon – система, отслеживающая состояние и нагрузку на модули персонального компьютера; 3. Remedy – информационная система для работы с запросами на обслуживание и инцидентами. Предоставляет функционал для обработки и учета созданных пользователями заявок; 4. Аctive Directory (AD) [3] —является базой данной, хранящей информацию по объектам внутри домена МГТС (сотрудники, оборудование), а также позволяющей группировать эти объекты и предоставлять им различные доступы в сети; 7 5. БоссРеферент [25] – система, необходимая для автоматизации документооборота и делопроизводства, в разрабатываемой системе будет предоставлять информацию по увольняющимся сотрудникам. 6. CUCM [4] – сервис для настройки ip-телефонии. На данный момент сотрудников, занимающихся процессом учета и предоставления оборудования можно разделить на три основные группы – диспетчеры, логисты, кладовщики. Диспетчеры сопровождают заявку от ее создания на портале в ИС Remedy, до закрытия. Информируют пользователей и собирают их пожелания и решения, касательно оборудования. Передают заявку на комплектацию – кладовщикам, а после назначают логиста, который доставит данное оборудование. В случае возникновения любых нестандартных случаев их также решает диспетчер. Кладовщик – специалист, конфигурирующий и укомплектовывающий оборудование, согласно указаниям диспетчера. Логист – специалист службы доставки, привозящий и монтирующий оборудование сотруднику ПАО МГТС. Как видно из описания ролей, уже есть места, которые можно автоматизировать. 1.1.1 Роли системы Выделим новые роли для работы, проектируемой автоматизированной информационное системы: 1. Разъездной специалист(Логист) —сотрудник, занимающийся перевозом и установкой или деинсталляцией оборудования; 2. Кладовщик — сотрудник, комплектующий оборудование; 3. Диспетчер — сотрудник, разбирающий нестандартные ситуации в работе системы, курирует работу остальных специалистов; 8 4. Администратор — сотрудник, имеющий полный доступ к системе, может добавлять новое оборудование в систему, изменять объекты системы. В совокупности, данные роли обеспечивают полное и корректное функционирование автоматизированной информационной системы. 1.1.2 Описание входных и выходных информационных потоков Система покрывает следующие такие кейсы, «АРМ в день» — доставка и установка оборудования устроившемуся на работу сотруднику, благодаря автоматизации удастся предоставлять сотруднику в день его трудоустройства, если он устроился до 15:00. Если же сотрудник устроился после 15:00, оборудование будет предоставлено на следующий день; Модернизация — модернизация оборудования, подходящего под условия модернизации, заводится заявка, после чего голосовой помощник спрашивает у сотрудника, согласен ли он с модернизацией. В случае согласия, система регистрирует на него заявку, собирает новую конфигурацию и отправляет ее в интерфейс кладовщика на комплектацию. После этого разъездной специалист доставляет и монтирует новое оборудование сотруднику; Увольнение — сопровождения процесса увольнения сотрудника. 1.1.3 АРМ в день Для заведения заявки по кейсу «АРМ в день». Робот раз в час выгружает отчет «АРМ Отчёт для загрузки в 1С.xls» из OeBS и заносит его в общую папку (расположенную на сервере mgts-scommon01:1433). Потом из БД IT Robot, таблицы new_users скрипт «Create_Inc.py» забирает информацию по сотрудникам, кроме исключений, описанных в Приложении 4. Забранные данные Скрипт заносит в БД Портала. На стороне портала работает скрипт «ArmToDay.ps1», которые каждые три минуты проверяет БД Портала на наличие записей о вновь принятых сотрудниках. Этот скрипт с помощью API HelpDesk 9 генерирует запрос на облуживание и полученный номер заявки заносит в БД портала. 1.1.4 Модернизация Для создания заявки по кейсу «Модернизация» реализован Python скрипт —«create_perfmon.py», который раз в день берет выгрузку из БД ITRobot с данными описи оборудования, подлежащего модернизации, далее он собирает данные по сотруднику и оборудованию из AD и ИнфраМенеджера и заносит не более 2-х записей в день в БД Портала. На стороне портала работает Скрипт — «Modern.ps1», который каждые три минуты ищет в БД Портала записи по модернизации, и с помощью API HelpDesk генерирует запрос на облуживание. После чего сгенерированный номер запроса заносит к уже созданной записи в БД Портала 1.1.5 Увольнение Для создания заявки по кейсу «Увольнение». На учетную запись Робота в письме приходит ссылка на согласование обходного листа увольняющегося сотрудника. По этой ссылке Робот заходит в БР и из заголовка служебной записки забирает табельный номер сотрудника. По табельному номеру в AD Робот берет логин и ФИО сотрудника. Далее в БД ITRobot, таблице «Data_from_excel_FN1» ищет оборудование, закрепленное за сотрудником. Если за сотрудником закреплено оборудование Робот согласует СЗ с комментарием, внося туда перечень закрепленного за сотрудником оборудования, а также отправляет письмо на почту [email protected] с данными по пользователю и списком оборудования закрепленного за ним. Информация, полученная в письме, заносится в БД Портала. На стороне Портала работает скрипт «BackEquip.ps1», которые каждые три минуты ищет записи в БД Портала по увольняющимся сотрудникам. Найдя такую запись, скрипт генерирует запрос на 10 обслуживание с помощью API HelpDesk, после чего заносит сгенерированный номер запроса в БД Портала. 1.1.6 Остальные кейсы Для создания заявки по остальным кейсам, Робот получает письма от ИС Remedy о факте создания заявки, Python [5] скрипт — Create_incident.py, выгружает информацию из письма и заносит в БД Портала номер заявки и информацию из нее; По следующим шаблонам заявку заводят пользователи на корпоративном портале − Запрос на вывоз; − Внеплановая потребность; − Диагностика; − Переезд В кейс «Прочее» попадают заявки, не вошедшие ни в одну из описанных выше категорий. 1.2 Обзор выбранного инструментария разработки Для отображения пользовательского интерфейса будут использоваться такие средства, как языки разметки и стилей — HTML [6] и CSS [7]. Язык программирования —JavaScript [8], а также CMS Strapi [9] вместе с плагином на реализацию Docker-контейнера [10]. Для обработки информации используются PowerShell [11] и Python скрипты Для взаимодействия с внутренними компонентами компании будет использоваться технология RPA [12]- robotic process automation. Данное средство 11 позволит эмулировать действия пользователя, что представляет отличную возможность взаимодействовать с системой, не изменяя ее. Настройка и программирование робота происходит на платформе UiPath [13], предоставляющей удобный и практичный интерфейс для работы, а также поддерживающей написание скриптов на языках программирования C# [14] и Python. Также в системе будет реализован модуль виртуального голосового помощника, с помощью программного обеспечения Asterisk, являющегося платформой для создания виртуального помощника, инициализируемого и настраиваемого с помощью скриптов, написанных на языке Python. Программное обеспечение и информационные системы, используемые в процессе описаны в Таблице 1. Таблица 1 — ПО и ИС используемые в процессе Название № п/п приложения и версия 1 2 3 4 5 MS Excel Язык системы RUS Модуль входа в Интерфейс систему n/a Desktop- Среда/способ доступа GUI приложение Route RUS n/a Web- GUI интерфейс CUCM ENG n/a Web- GUI интерфейс Remedy RUS n/a Web- GUI интерфейс Asterisk[15] ENG n/a Desktopприложение 12 GUI 1.3 Обзор продуктов аналогов Как таковых явных продуктов-аналогов разрабатываемой системы не существует, но из неявных можно выделить «1С: Предприятие» [26] (Рисунок 1). Рисунок 1 —Интерфейс «1С: Предприятие, раздел Логистика» Несмотря на гибкость настройки и широкий каталог шаблонных решений, наш случай не вписывается в общую картину 1С, так как плотно интегрирует со множеством интерфейсов внутренних ИС организации, посредством Роботов, доводя определенные процессы до полного автоматизма, например, обработка кейса увольнение. Остальные аналоги являются как таковыми копиями 1С, но с меньшим функционалом, например, «ТИС-online» [27] (Рисунок 2). Данная система позволяет контролировать внутренний автопарк организации, предоставляя транспорт и заявки на работу с оборудованием разъездным специалистам. 13 Рисунок 2 —Интерфейс «ТИС-online» Еще одним неявным аналогом можно выделить «АРМ. Экспедитор» [28] (Рисунок 3). Как и предыдущая она позволяет проводить мониторинг и диспетчеризацию грузоперевозок, также имеет возможность интеграции с 1С, но так как в организации уже установлен OeBS, вариант полного перехода на 1С нельзя назвать хорошим. Рисунок 3 —Интерфейс «АРМ. Экспедитор» 14 На основе проведенного обзора продуктов аналогов, можно сделать вывод, что как таковых прямых или близких аналогов проектируемого продукта нет, отдаленные же аналоги заменяют только один из модулей системы: учет или мониторинг разъездных специалистов. 1.4 Требования к системе в целом Для работы системы нужно получить доступы к следующим ресурсам: OeBS, Босс Референт, Remedy, Cucm. 1.4.1 Системные и бизнес требования 1 Робот должен запускаться, при получении выгрузки из OEBS, когда находит ПК подходящий для модернизации, а также в случае появления заявки на портале Remedy; 2 Робот должен менять статусы заявки в зависимости от контекста; 3 Робот должен инициализировать звонок ВП (Виртуального помощника) по форме, исходя из контекста; 4 Робот должен переводить заявки в интерфейсы кладовщика, логиста и диспетчера, исходя из контекста задачи; 5 Робот должен отсылать уведомление о статусе заявки на почту; 6 Робот должен переносить оборудование с МОЛ на пользователя и наоборот; 7 Робот должен проверять грейд сотрудника; 8 Робот должен автоматически создавать конфигурацию ПК сотрудника исходя из оборудования его коллег по департаменту и сотрудников аналогичной должности; 9 Робот должен настраивать IP-телефонию; 15 10 Робот должен закрывать отработанную заявку в Remedy с соответствующим статусом 1.4.2 Требования к порталу Портал должен корректно открываться и правильно отображать информацию на основных браузерах: 1. Chrome; 2. Firefox; 3. Edge. Информация должна быть структурирована по таблицам. На сайте должна быть реализована возможность поиска объектов системы с помощью фильтров и категоризации. Для каждой роли в системе должен быть отведен свой интерфейс. Портал должен предоставлять возможность авторизации пользователя в системе. Портал должен способствовать корректной обработке заявок путем: 1. Добавления комментариев к заявке; 2. Дополнения заявки необходимой информацией; 3. Передачи заявок по разным интерфейсам. Портал должен менять статусы заявки в зависимости от стадии ее обработки. Портал должен составлять отчетность и направлять ее администратору автоматизированной системы. 16 1.4.2.1 Требования к графическому обеспечению портала На портале должна быть реализована панель навигации, расположенная сверху снизу, содержащая название системы. Портал должен иметь единый стиль отображения для всех страниц. 1.4.2.2 Требования к лингвистическому обеспечению портала Информация на сайте должна быть представлена на русском языке, без пунктуационных и орфографических ошибок. 1.4.2.3 Исключения Исключения составлены в Таблице 2. Как видно исходя из таблицы первый столбец – номер исключения. Второй столбец – название и тип исключения. Третий столбец – действия Робота [16], то что он должен делать, столкнувшись с исключением. Четвертый столбец – действия пользователя, описывает кто и что именно следует сделать, для того чтобы обработать данное исключение. Таблица 2 — Исключения № Исключение 1. Сайт недоступен Действия Робота Ожидание 60 проверка, секунд, Действия Пользователя — повторное ожидание 60 секунд 2 Портал недоступен Ожидание 60 проверка, секунд, повторное ожидание 60 секунд 17 — Продолжение Таблицы 2 № 3 Исключение Нет доступа интернету Действия Робота к Ожидание 60 проверка, Действия Пользователя секунд, — повторное ожидание 60 секунд 4 5 Неизвестная Переход к следующей Диспетчер устраняет ошибка заявке Ошибка доступа Переход к следующей Лицо, ответственное за проблему заявке решение проблем и инцидентов настраивает доступ робота к недоступной системе 1.5 Мероприятия по внедрению системы в эксплуатацию Разработанная система будет работать на выделенном внутри домена МГТС сервере. Для корректной работоспособности системы сервер должен обладать следующими минимальными характеристиками: vCPU – 4 ядра. Оперативная память – 8 ГБ. Объем жесткого диска – 170 ГБ. Также на сервере должно быть предустановлено следующее программное обеспечение: 1. Oracle Linux 8.5 [17]; 2. PostgreSQL 14 [18]; 3. Strapi 4; 18 4. Python 3.7; 5. PowerShell 5.1; 6. Asterisk 18.11.3; 7. UiPath 2021.4.4; 8. .NET 4.3. Оперативная система: Linux Debian 11.6[19]. 1.6 Выделение системных статусов Для корректности и учета стадий по заявкам были спроектированы и выделены статусы, описанные в Таблице 3. Таблица 3 — Статусы, выводимые ИС в процессе работы Сообщение Описание Новый сотрудник Инициализация процесса «АРМ в день» Сконфигурировано Сконфигурирована заявка Комплектация Комплектация оборудования Выбор ПК/Ноутбук Комплектация оборудования с выбором ПК или ноутбук Отзыв RA Отзыв заявки Не подтвержден Запрос не подтвержден после звонка ВП Доставка Оборудование находится в процессе доставки Установлено Оборудование установлено Не установлено Оборудование не было установлено Перемещение Перемещение оборудования с МОЛ на пользователя и наоборот Возврат Возврат оборудования на склад 19 Продолжение Таблицы 3 — Статусы, выводимые ИС в процессе работы Сообщение Описание Отменен Заявка закрыта по причине отмены пользователем Архив Заявка успешно закрыта и занесена в архив Заявка на модернизацию Инициализация процесса «Модернизация» RA создан Создана заявка Ошибка переноса Ошибка переноса оборудования с МОЛ на пользователя и наоборот Забор Забор оборудования у пользователя Не забрано Оборудование не было забрано Внеплановая потребность Инициализация процесса «Внеплановая потребность» Получение Инициализация процесса «Переезд» Диагностика Инициализация процесса «Диагностика» Продиагностировано Оборудование было продиагностировано Доукомлпектация Запрошена доукомплектация оборудования 1.7 Мероприятия по сопровождению системы Система представляет собой следующие сервисы: • Получение данных по вновь принятым, уволенным сотрудникам; • Получение данных по ПК с превышением значений из Perfmon; • Определение конфигурации выдаваемого оборудования; • Генерация заявок на выдачу компьютерного оборудования вновь принятым сотрудникам; • Генерация заявок на модернизацию ПК по показаниям Perfmon; • Генерация заявок на возврат техники уволенного сотрудника; 20 • Процессы работы с входящими обращениями пользователей; • Голосовое оповещение сотрудников о предстоящих работах; • Распределение заявок на разъездных специалистов согласно зон ответственности; • Интерфейс для работы кладовщика; • Интерфейс для работы разъездного специалиста; • Интерфейс для работы диспетчера; • Интерфейс для работы учетчика оборудования; • Процесс регистрации оборудования IP телефонии и присвоения абонентского номера пользователю; • Процесс переноса имущества в ИС учета с МОЛ на пользователя и обратно; • Внесение данных по входящим обращениям пользователей в автоматизированную систему; Данные процессы поддерживаются руководителем проекта, как сотрудником, распределяющим ответственность, а также специалистами RPA, Front-end и Back-end разработки. 21 Управление инцидентами осуществляется по схеме, представленной на Рисунке 4. Рисунок 4 — Управление инцидентами Любое изменение в Системе должно быть оформлено в виде запроса на изменение и авторизовано в соответствии с действующим регламентом РПМГТС-023-2 «Управление потребностями в ИТ-сервисах». Жизненный цикл решения инцидента (инцидент или запрос на консультацию) состоит из следующих стадий: ⎯ Идентификация и принятие в работу; ⎯ Исследование и диагностика; ⎯ Решение/выполнение и подтверждение; ⎯ Закрытие. Все инциденты и запросы на консультации пользователей, сотрудники ПАО «МГТС» направляют через внутренний портал HelpDesk. В процессе работы каждому инциденту присваивается статус, фиксирующий этап обработки инцидента. Статусы, характеризующие жизненный цикл инцидента описаны в Таблице 4. 22 Таблица 4 — Статусы инцидента № Статус Описание 1 Назначен Инцидент назначен на команду Исполнителя для проведения анализа 2 Решен Инцидент решен Исполнителем 3 Закрыт Инцидент согласован с пользователем, инициировавшим данный инцидент 1.8 Выводы по первому разделу В ходе анализа предметной области были выделены требования к самому порталу и серверной части, а также определены входные информационные потоки. Проведенное исследование поспособствует проектированию системных статусов и самого бизнес процесса системы, а также позволит описать весь процесс с помощью вариантов использования. 23 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 2.1 Схема в нотации IDEF0 Контекстная диаграмма спроектированной структурной диаграммы в нотации IDEF0 [20], состоянии TO-BE изображена на Рисунке 5. Рисунок 5 — Контекстная диаграмма Ее декомпозиция изображена на Рисунке 6. 24 Рисунок 6 — Декомпозиция контекстной диаграммы Декомпозиции остальных блоков представлены на Рисунках 7-10. Рисунок 7 — Декомпозиция блока А1 — «Регистрация заявки» 25 Рисунок 8 — Декомпозиция блока А2— «Звонок виртуального помощника» Рисунок 9 — Декомпозиция блока А3 — «Установка оборудования» 26 Рисунок 10 — Декомпозиция блока А4 — «Закрытие заявки» 2.2 Проектирование бизнес-процесса системы Автоматизированные процессы в нотации BPMN [21] изображены на Рисунка 11, 12, 13, 14. Рисунок 11 — Процесс настройки телефонии в состоянии «TO-BE» 27 Рисунок 12 — Процесс выбора разъездного специалиста в состоянии «TO-BE» Рисунок 13 — Процесс подбора конфигурации в состоянии «TO-BE» Рисунок 14 — Процесс переноса оборудования с пользователя на МОЛ и наоборот в состоянии «TO-BE». 28 2.3 Описание процесса системы с помощью вариантов использования Все основные маршруты описаны с помощью вариантов использования [22]. 2.3.1 Описание процессов «АРМ в день» через варианты использования UC01. Взятие задачи в работу Роботом Действующие лица: • Робот. Цели выполнения: • Запуск процесса; • Проверка выгрузки на наличие вновь нанятого сотрудника. Предусловие: • Поступила выгрузка из OEBS Постусловие: • Робот нашел нового сотрудника в выгрузке из OEBS; • Робот не нашел нового сотрудника в выгрузке из OEBS. Основной поток действий: 1. Робот запускается; 2. Открывает выгрузку из OEBS; 3. Проверяет есть ли в выгрузке новый сотрудник: 3.1. Если в выгрузке есть новый сотрудник. Робот переходит к выполнению UC02; 29 3.2. Если в выгрузке нового сотрудника нет. Робот переходит к выполнению п.п.1. UC02. Получение данных по новому сотруднику Действующие лица: • Робот. Цели выполнения: • Получение данных по новому сотруднику. Предусловие: • В выгрузке из OEBS был найден новый сотрудник. Постусловие: • Робот забрал данные по новому сотруднику. Основной поток действий: 1. Робот считывает данные по-новому сотруднику 2. Робот запоминает данные по новому сотруднику; 3. Робот переходит к выполнению UC03. UC03. Оповещение виртуальным помощником. Действующие лица: • Робот; • ВП. Цели выполнения: • Совершить звонок оповещение новому сотруднику. Предусловие: 30 • Робот взял в работу данные по новому сотруднику. Постусловие: • Звонок ВП был совершен: o Руководитель сотрудника подтвердил необходимость в оборудовании; o Руководитель сотрудника отказался от оборудования; o Грейд нанимаемого сотрудника больше шести. Заявка перешла в ручное управление диспетчером; o Руководитель сотрудника не ответил на звонок ВП. Основной поток действий: 1. Робот проверяет грейд нанимаемого сотрудника. 2. Робот автоматически назначает логиста, исходя из округа, привязанного к нему. 3. Робот инициализирует звонок руководителю сотрудника по форме «АРМ в день». 4. ВП звонит руководителю нового сотрудника 4.1. Если руководитель нового сотрудника дал согласие. Робот собирает данные о компьютерах сотрудников аналогичной должности, а также коллег нового сотрудника по департаменту. 4.1.1. Если грейд пользователя меньше 6. Робот автоматически конфигурирует сборку ПК. Статус заявки меняется на «Комплектация». Переход к UC04. 4.1.2. Если грейд пользователя больше или равен 6. Заявка переходит в ручное управление к диспетчеру. Нужно предоставить выбор ПК или Ноутбук. Статус заявки меняется на «Выбор ПК/Ноутбук». Переход к UC08 31 4.2. Если руководитель нового сотрудника не дал согласие. Статус заявки меняется на «Отзыв RA». Переход к UC12. 4.3. Если руководитель нового сотрудника не ответил на звонок. Совершается 3 повторных звонка с интервалом в 30 минут, пока пользователь не ответит. 4.3.1. Если руководитель нового сотрудника ответил на звонок и дал согласие. Если 4.3.1.1. грейд нанятого сотрудника меньше 6. Статус заявки меняется на «Комплектация». Переход к UC04. Если грейд нанимаемого сотрудника 4.3.1.2. больше или равен 6. Статус заявки меняется на «Выбор ПК/Ноутбук». Переход к UC08. 4.3.2. Если руководитель нового сотрудника ответил на звонок и не дал согласие. Статус заявки меняется на «Отзыв RA». Переход к UC12; 4.3.3. Если руководитель нового сотрудника не ответил на звонок по истечению 3-х попыток. 4.3.4. Если грейд сотрудника меньше 6. Статус заявки меняется на «Не подтверждено». Заявка переходит в ручное управление диспетчеру. Переход к UC13. 4.3.5. Если грейд сотрудника больше 6. Статус меняется на «Выбор ПК/Ноутбук». Переход к UC08. UC04. Комплектация оборудования Действующие лица: 32 • Робот; • Кладовщик. Цели выполнения: • Укомплектовать оборудование новому сотруднику. Предусловие: • Руководитель дал согласие на установку оборудования. Постусловие: • Оборудование укомплектовано кладовщиком. Основной поток действий: 1. Заявка переходит в интерфейс кладовщику 2. Кладовщик собирает комплектующие исходя из представленного списка; 2.1. Если все оборудование подошло. Кладовщик заносит данные об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка. Робот переходит к выполнению UC05; 2.2. Если комплектующие не подходят/их нет в наличии. Кладовщик заменяет комплектующие на другие и заносит информацию об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка» Робот переходит к выполнению UC05. UC05. Доставка Действующие лица: • Робот; • Логист. 33 Цели выполнения: • Доставить оборудование новому сотруднику. Предусловие: • Оборудование успешно укомплектовано. Постусловие: • Оборудование успешно доставлено новому сотруднику; • Оборудование не было доставлено; • Сотрудник отказался от оборудования. Основной поток действий: 1. В интерфейсе отображается заявка 2. Логист выезжает по указанному в интерфейсе адресу 2.1. Если оборудование успешно установлено. Логист фиксирует факт установки в интерфейсе. Статус заявки меняется на «Установлено» Робот переходит на UC06. 2.2. Если оборудование не было установлено. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не установлено». Заявка переходит в ручное управление диспетчером UC 10. 2.3. Если пользователь отказался от оборудования. Статус заявки меняется на «Не установлено». Заявка переходит в ручное управление диспетчером UC 10 UC06. Настройка IP-Телефонии Действующие лица: • Робот. 34 Цели выполнения: • Настроить IP-телефонию. Предусловие: • Оборудование успешно установлено. Постусловие: • IP-телефония успешно настроена. Основной поток действий: 1. Робот входит в систему CUCM; 2. Робот настраивает телефонию на нового сотрудника; 3. Переход на UC07. UC07. Перенос оборудования Действующие лица: • Робот. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование успешно установлено. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 1. Робот входит в систему OEBS; 35 2. Робот заводит карточку нового сотрудника; 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 2.2. Если оборудование установить не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC09 UC08.Выбор ПК/Ноутбук Действующие лица: • Диспетчер. Цели выполнения: • Руководитель сотрудника выбрал оборудование для установки. Предусловие: • Руководитель сотрудника дал согласие на установку оборудования новому сотруднику и грейд нового сотрудника больше или равен 6. Постусловие: • Руководитель сотрудника подтвердил необходимость в подтвердил необходимость в оборудовании и выбрал для сотрудника ПК; • Руководитель сотрудника оборудовании и выбрал для сотрудника ноутбук; • Диспетчер сохранил заявку для рассмотрения в будущем. Основной поток действий: 1. Диспетчер совершает звонок руководителю сотрудника 1.1. Если был выбран вариант ПК. Статус заявки меняется на «Комплектация». Переход на UC04; 36 1.2. Если пользователь отказался от установки оборудования. Статус заявки меняется на «Отзыв RA». 1.3. Если был выбран ноутбук. Статус заявки меняется на «Доставка». Переход к UC05. 2. Диспетчер может не совершать звонок, а сохранить заявку. Статус заявки меняется на «Сохранено». Переход к UC08. UC09. Ручной перенос оборудования Действующие лица: • Диспетчер. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование не было автоматически перенесено с МОЛ на пользователя. Постусловие: • Оборудование успешно перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 2. Диспетчер создает и заполняет карточку нового сотрудника. Статус заявки меняется на «Архив»; UC10. Оборудование не было установлено. Ручное управление диспетчером. Действующие лица: • Диспетчер. 37 Цели выполнения: • Решить вопрос установки оборудования. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно установлено; • Оборудование не было установлено; • Разъездной специалист привез неполный комплект оборудования. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не установлено; 2. Диспетчер связывается с руководителем нового сотрудника; 2.1. Если руководитель запрашивает повторную доставку. Диспетчер отправляет оборудование в доставку. Статус заявки меняется на «Доставка». Переход на UC05. 2.2. Если руководитель отменил заявку. Диспетчер делает возврат оборудования. Статус заявки меняется на «Возврат». Логист возвращает оборудование на склад. Кладовщик складирует оборудование. Переход на UC11. 2.3. Если руководитель сообщает, что получен не полный комплект оборудования. Диспетчер отправляет оборудование на доукомплектацию. Статус заявки меняется на «Комплектация». Переход на UC04. UC11. Возврат оборудования. Действующие лица: • Логист; 38 • Кладовщик; • Диспетчер. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно возвращено на склад. Основной поток действий: 1. Логист отвозит оборудование обратно на склад. 2. Кладовщик разукомплектовывает оборудование и информацию в ИМ. 3. Статус заявки меняется на «Отзыв RA». Переход к UC12. UC12. Отзыв RA Действующие лица: • Робот. Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен». Предусловие: • Статус заявки изменился на «Отзыв RA». Постусловие: • Cтатус заявки успешно изменен на «Отменен». 39 заносит Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен» UC13. Ручное управление. Руководитель сотрудника не ответил на звонок ВП. Действующие лица: • Диспетчер Цели выполнения: • Решить вопрос с выдачей нового оборудования. Предусловие: • Руководитель сотрудника не ответил на звонок ВП. Постусловие: • Руководитель сотрудника подтвердил необходимость установки оборудования; • Руководитель сотрудника отказался от установки оборудования; • Диспетчер сохранил заявку для рассмотрения в будущем. Основной поток действий: 1. В интерфейсе диспетчера отобразилась заявка со статусом «Не подтвержден» 2. Диспетчер «проваливается» в заявку. 3. Диспетчер звонит руководителю нанятого сотрудника: 3.1. Если руководитель не ответил на звонок. Диспетчер сохраняет заявку, чтобы вернуться к ней позже. Статус заявки меняется на «Сохранено»; 40 3.2. Если руководитель подтвердил необходимость оборудовании для вновь нанятого сотрудника. Диспетчер отправляет заявку на комплектацию. Статус заявки меняется на «Комплектация». Переход к UC04; 3.3. Если руководитель ответил на звонок и не подтвердил необходимость оборудовании для сотрудника. Диспетчер отменяет заявку. Статус заявки меняется на «Отзыв RA» Переход к UC12. 2.3.2 Описание процессов «Модернизация» через варианты использования UC01. Взятие задачи в работу Роботом. Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • Оборудование из БД Сапог подходит для модернизации. Постусловие: • Запущен процесс модернизации. Основной поток действий: 1. Робот заходит в БД Сапог 1 раз в день; 2. Робот выбирает компьютер для модернизации по следующим параметрам: 2.1. Создана ли уже заявка на этот ПК 41 2.2. Находится ли этот ПК в списке исключений 2.3. Есть ли уже две заявки в исполнении, если есть робот возвращается к п.1 на следующий день. 2.4. Робот диагностирует проблему в ПК по следующим условиям: 2.4.1. Если нагрузка на оперативную память больше 80%, оперативной памяти меньше 16GB и установлен HDD. Создается заявка на модернизацию ПК. Переход к UC02. 2.4.2. Если средняя нагрузка на процессор больше 85% и/или средняя загрузка оперативной памяти больше 80%, оперативной памяти больше 16GB и установлен SSD. Создается заявка на замену ПК. Переход к UC02. UC02. Оповещение виртуальным помощником. Действующие лица: • Робот. • ВП. Цели выполнения: • Оповещение сотрудника. Предусловие: • Создана заявка на модернизацию. Постусловие: • Пользователь подтвердил необходимость модернизации ПК; • Пользователь отказался от возможности модернизации ПК; • Пользователь не ответил на звонок ВП. Основной поток действий: 42 1. Робот инициализирует звонок оповещение по форме «Модернизация» 2. ВП совершает звонок оповещение сотруднику: 2.1. Если сотрудник подтвердил необходимость модернизации ПК. Статус заявки меняется на «Комплектация». Переход к UC03.; 2.2. Если сотрудник отказался от возможности модернизировать ПК. Статус заявки меняется на «Отзыв RA». Переход к UC09; 2.3. Если сотрудник не ответил на звонок. Совершается 3 повторных звонка с интервалом в 30 минут, пока пользователь не ответит. 2.3.1. Если сотрудник ответил на звонок и дал согласие. Статус заявки меняется на «Комплектация». Переход к UC03. 2.3.2. Если сотрудник ответил на звонок и не дал согласие. Статус заявки меняется на «Отзыв RA». Переход к UC09; 2.3.3. Если сотрудник не ответил на звонок по истечении 3-х попыток. Статус заявки меняется на «Не подтверждено». Заявка переходит в ручное управление диспетчеру. Переход к UC10. UC03. Комплектация оборудования. Действующие лица: • Робот; • Кладовщик. Цели выполнения: • Укомплектовать оборудование. Предусловие: • Сотрудник подтвердил необходимость модернизации. 43 Постусловие: • Оборудование укомплектовано. Основной поток действий: 1. Заявка переходит в интерфейс кладовщику; 2. Кладовщик собирает комплектующие исходя из представленного списка; 2.1. Если все оборудование подошло. Кладовщик заносит данные об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка. Робот переходит к выполнению UC04; 2.2. Если комплектующие не подходят/их нет в наличии. Кладовщик заменяет комплектующие на другие и заносит информацию об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка» Робот переходит к выполнению UC04. UC04. Доставка Действующие лица: • Робот; • Логист. Цели выполнения: • Доставить оборудование сотруднику. Предусловие: • Оборудование успешно укомплектовано. Постусловие: • Оборудование успешно доставлено и установлено сотруднику; 44 • Оборудование не было доставлено сотруднику; Основной поток действий: 1. В интерфейсе отображается заявка; 2. Логист выезжает по указанному в интерфейсе адресу; 2.1. Если оборудование успешно установлено. Логист фиксирует факт установки в интерфейсе. Статус заявки меняется на «Установлено» Робот переходит на UC05; 2.2. Если оборудование не было установлено. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не установлено». Заявка переходит в ручное управление диспетчером UC 07; 2.3. Если пользователь отказался от оборудования. Статус заявки меняется на «Не установлено». Заявка переходит в ручное управление диспетчером UC07. UC05. Перенос оборудования Действующие лица: • Робот. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование успешно установлено. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. 45 Основной поток действий: 1. Робот авторизуется в системе OEBS; 2. Робот находит карточку сотрудника; 3. Робот переносит оборудование с МОЛ на пользователя; 3.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 3.2. Если оборудование перенести не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC06. UC06. Ручной перенос оборудования Действующие лица: • Диспетчер. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование не было автоматически перенесено с МОЛ на пользователя. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 2. Диспетчер находит карточку сотрудника и переносит оборудование; 46 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 2.2. Если перенести оборудование не удалось. Возврат к п.1. UC07. Оборудование не было установлено. Ручное управление диспетчером. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос установки оборудования. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно установлено; • Сотрудник отменил заявку на установку оборудования; • Сотрудником был получен неполный комплект оборудования. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не установлено; 2. Диспетчер рассматривает оставленный комментарий логиста и по надобности связывается с сотрудником; 2.1. Если сотрудник запрашивает повторную доставку. Диспетчер отправляет оборудование в доставку. Статус заявки меняется на «Доставка». Переход на UC04. 2.2. Если сотрудник отменил заявку. Диспетчер делает возврат оборудования. Статус заявки меняется на «Возврат». Переход на UC08. 47 2.3. Если сотрудник сообщает, что получен не полный комплект оборудования. Диспетчер отправляет оборудование на доукомплектацию. Статус заявки меняется на «Комплектация». Переход на UC03. UC08. Возврат оборудования. Действующие лица: • Логист; • Кладовщик; • Диспетчер. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование не было установлено, диспетчер запросил возврат оборудования. Постусловие: • Оборудование успешно возвращено на склад. Основной поток действий: 1. Логист отвозит оборудование обратно на склад; 2. Кладовщик проводит разукомплектацию оборудования и размещает его на складе; 3. Статус заявки меняется на «Отзыв RA». Переход к UC09. UC09. Отзыв RA Действующие лица: • Робот. 48 Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен». Предусловие: • Статус заявки изменился на «Отзыв RA». Постусловие: • Статус заявки успешно изменен на «Отменен». Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен». UC10. Ручное управление. Сотрудник не ответил на звонок ВП. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос с модернизацией старого оборудования. Предусловие: • Сотрудник не ответил на звонок ВП. Постусловие: • Пользователь подтвердил необходимость в модернизации оборудования; • Пользователь отказался от модернизации оборудования; • Диспетчер сохранил заявку для рассмотрения в будущем. Основной поток действий: 49 1. В интерфейсе диспетчера отобразилась заявка со статусом «Не подтвержден» 2. Диспетчер «проваливается» в заявку. 3. Диспетчер звонит сотруднику: 3.1. Если сотрудник не ответил на звонок. Диспетчер сохраняет заявку, чтобы вернуться к ней позже. Статус заявки меняется на «Сохранено» 3.2. Если сотрудник подтвердил необходимость в модернизации оборудования. Диспетчер отправляет заявку на комплектацию. Статус заявки меняется на «Комплектация». Переход к UC03. 3.3. Если сотрудник ответил на звонок и не подтвердил необходимость в модернизации оборудования. Диспетчер отменяет заявку. Статус заявки меняется на «Отзыв RA» Переход к UC09. 2.3.3 Описание процессов «Увольнение» через варианты использования UC01. Взятие задачи в работу Роботом. Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • В выгрузке из Босс-Референт обнаружен увольняющийся сотрудник. Постусловие: 50 • Запущен процесс возврата. Основной поток действий: 1. Робот заходит в выгрузку из БР; 2. Робот производит поиск сотрудников, числящихся увольняющимися 3. Робот генерирует новую заявку и автоматически определяет логиста, исходя из его местоположения. Статус заявки устанавливается «RA создан» Переход к UC02. UC02. Оповещение виртуальным помощником. Действующие лица: • Робот; • ВП. Цели выполнения: • Оповещение сотрудника. Предусловие: • Создана заявка на забор/возврат оборудования. Постусловие: • Пользователь оповещен; • Пользователь не оповещен. Основной поток действий: 1. Робот генерирует звонок ВП; 2. ВП совершает звонок оповещение сотруднику: 2.1. Если сотрудник оповещен. Статус заявки меняется на «Забор». Переход к UC03; 51 2.2. Если сотрудник не ответил на звонок. Совершается 3 повторных звонка с интервалом в 30 минут, пока пользователь не ответит. 2.2.1. Если сотрудник ответил. Статус заявки меняется на «Забор». Переход к UC03; 2.2.2. Если сотрудник не ответил на звонок по истечении 3-х попыток. Статус заявки меняется на «Не подтверждено». Заявка переходит в ручное управление диспетчеру. Переход к UC09. UC03. Забор. Действующие лица: • Робот; • Логист. Цели выполнения: • Забрать оборудование сотрудника. Предусловие: • Статус заявки изменен на «Забор». Постусловие: • Оборудование было успешно забрано. • Оборудование не было забрано; Основной поток действий: 1. В интерфейсе отображается заявка 2. Логист выезжает по указанному в интерфейсе адресу 2.1. Если оборудование успешно забрано. Логист фиксирует факт забора в интерфейсе. Статус заявки меняется на «Возврат» Робот переходит на UC04. 52 2.2. Если оборудование не было забрано. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не забрано». Заявка переходит в ручное управление диспетчером UC 08. UC04. Возврат на склад Действующие лица: • Робот; • Кладовщик. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование успешно доставлено кладовщику. Постусловие: • Оборудование подготовлено к переиспользованию. Основной поток действий: 1. Заявка переходит в интерфейс кладовщику; 2. Кладовщик разбирает и складирует оборудование. Статус заявки меняется на «Перемещение». Переход к UC05. UC05. Перенос оборудования Действующие лица: • Робот Цели выполнения: • Перенести оборудование с пользователя на МОЛ. 53 Предусловие: • Оборудование успешно возвращено на склад. Постусловие: • Оборудование успешно перемещено с пользователя на МОЛ; • Оборудование не было перенесено с пользователя на МОЛ. Основной поток действий: 1. Робот входит в систему OEBS; 2. Робот открывает карточку сотрудника и совершает попытку переноса оборудования: 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 2.2. Если оборудование установить не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC06. UC06. Ручной перенос оборудования Действующие лица: • Диспетчер. Цели выполнения: • Перенести оборудование с пользователя на МОЛ. Предусловие: • Оборудование не было автоматически перенесено с пользователя на МОЛ. Постусловие: 54 • Оборудование успешно перенесено. • Оборудование не было перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 2. Диспетчер открывает карточку сотрудника и вручную переносит оборудование: Если перенести оборудование удалось. Статус заявки меняется 2.1. на «Архив». 2.2. Если перенести оборудование не удалось. Возврат к п.1. UC07. Отзыв RA Действующие лица: • Робот; Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен». Предусловие: • Статус заявки изменился на «Отзыв RA». Постусловие: • Cтатус заявки успешно изменен на «Отменен». Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен» 55 UC08. Оборудование не было забрано. Ручное управление диспетчером. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос забора оборудования. Предусловие: • Оборудование не было забрано. Постусловие: • Оборудование успешно забрано. • Руководитель увольняющегося сотрудника отменил забор оборудования. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не забрано; 2. Диспетчер ознакамливается с комментарием и в случае надобности связывается с сотрудником; 2.1. Если сотрудник запрашивает повторный забор. Диспетчер отправляет логиста на забор. Статус заявки меняется на «Забор». Переход на UC03. 2.2. Если сотрудник отменил заявку. Диспетчер отменяет заявку. Статус заявки меняется на «Отзыв RA». Переход на UC07. UC09. Ручное управление. Сотрудник не ответил на звонок ВП. Действующие лица: • Диспетчер. 56 Цели выполнения: • Решить вопрос с забором оборудования. Предусловие: • Сотрудник не ответил на звонок ВП. Постусловие: • Диспетчер сохранил заявку для рассмотрения в будущем; • Руководитель сотрудника отказался от забора оборудования; • Руководитель сотрудника подтвердил необходимость забора оборудования. Основной поток действий: 1. В интерфейсе диспетчера отобразилась заявка со статусом «Не подтвержден» 2. Диспетчер «проваливается» в заявку. 3. Диспетчер звонит сотруднику: 3.1. Если сотрудник не ответил на звонок. Диспетчер сохраняет заявку, чтобы вернуться к ней позже. Статус заявки меняется на «Сохранено» 3.2. Если сотрудник подтвердил надобность забора оборудования. Диспетчер отправляет заявку логисту на забор. Статус заявки меняется на «Забор». Переход к UC03. 3.3. Если сотрудник ответил на звонок и не подтвердил необходимость в заборе оборудования. Диспетчер отменяет заявку. Статус заявки меняется на «Отзыв RA» Переход к UC07. 57 2.3.4 Описание процессов «Запрос на вывоз» через варианты использования UC01. Взятие задачи в работу Роботом. Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • В Remedy появилась заявка на вывоз оборудования. Постусловие: • Запущен процесс вывоза оборудования. Основной поток действий: 1. Робот заходит в Remedy и выбирает заявку по имени «Запрос на вывоз»; 2. Робот генерирует новую заявку в системе Route и автоматически определяет логиста, исходя из его местоположения. устанавливается «RA создан» Переход к UC02. UC02. Забор. Действующие лица: • Робот; • Логист. Цели выполнения: 58 Статус заявки • Забрать оборудование сотрудника. Предусловие: • Статус заявки изменен на «Забор». Постусловие: • Оборудование было успешно забрано. Основной поток действий: 1. В интерфейсе отображается заявка 2. Логист выезжает по указанному в интерфейсе адресу 2.1. Если оборудование успешно забрано. Логист фиксирует факт забора в интерфейсе. Статус заявки меняется на «Возврат» Робот переходит на UC03. 2.2. Если оборудование не было забрано. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не забрано». Заявка переходит в ручное управление диспетчером UC 07. UC03. Возврат на склад Действующие лица: • Робот; • Кладовщик. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование доставлено кладовщику. Постусловие: 59 • Оборудование успешно подготовлено к переиспользованию. Основной поток действий: 1. Заявка переходит в интерфейс кладовщику; 2. Кладовщик разбирает и складирует оборудование. Статус заявки меняется на «Перемещение». Переход к UC04. UC04. Перенос оборудования Действующие лица: • Робот Цели выполнения: • Перенести оборудование с пользователя на МОЛ. Предусловие: • Оборудование успешно возвращено на склад. Постусловие: • Оборудование успешно перемещено с пользователя на МОЛ. • Оборудование не было перенесено с пользователя на МОЛ. Основной поток действий: 1. Робот входит в систему OEBS; 2. Робот открывает карточку сотрудника и совершает попытку переноса оборудования: 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 60 2.2. Если оборудование установить не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC05. UC05. Ручной перенос оборудования Действующие лица: • Диспетчер. Цели выполнения: • Перенести оборудование с пользователя на МОЛ. Предусловие: • Оборудование не было автоматически перенесено с пользователя на МОЛ. Постусловие: • Оборудование успешно перенесено. • Оборудование не было перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 2. Диспетчер открывает карточку сотрудника и вручную переносит оборудование: Если перенести оборудование удалось. Статус заявки меняется 2.1. на «Архив». 2.2. Если перенести оборудование не удалось. Возврат к п.1. 61 UC06. Отзыв RA Действующие лица: • Робот; Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен». Предусловие: • Статус заявки изменился на «Отзыв RA». Постусловие: • Cтатус заявки успешно изменен на «Отменен». Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен». Переход на UC07. UC07. Оборудование не было забрано. Ручное управление диспетчером. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос забора оборудования. Предусловие: • Оборудование не было забрано. Постусловие: • Сотрудник подтвердил необходимость вывоза оборудования; • Сотрудник отменил заявку на вывоз оборудования. 62 Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не забрано; 2. Диспетчер ознакамливается с комментарием и в случае надобности связывается с сотрудником; 2.1. Если сотрудник запрашивает повторный забор. Диспетчер отправляет логиста на забор. Статус заявки меняется на «Забор». Переход на UC02. 2.2. Если сотрудник отменил заявку. Диспетчер отменяет заявку. Статус заявки меняется на «Отзыв RA». Переход на UC06. 2.3.5 Описание процессов «Внеплановая потребность» варианты использования UC01. Взятие задачи в работу Роботом Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • Найдена заявка на внеплановую потребность в оборудовании. Постусловие: • Робот создал новую заявку на портале Route. Основной поток действий: 1. Робот запускается; 2. Робот мониторит портал Remedy; 63 через 2.1. Если найдена новая заявка, попадающая под категорию внеплановой потребности: 2.1.1. Робот создает новую заявку на портале Route по внеплановой потребности; 2.1.2. Робот создает конфигурацию оборудования, исходя из оборудования коллег сотрудника и оборудования сотрудников с аналогичной должностью; 2.1.3. Робот назначает логиста к заявке. 2.1.4. Робот присваивает заявке статус «Внеплановая потребность». 2.1.5. Робот проверяет грейд сотрудника: 2.1.5.1. Если грейд больше или равен 6 переход к UC09; 2.1.5.2. 2.2. Если грейд меньше 6 переход к UC02. Если заявка не найдена переход к п.1. UC02. Комплектация. Действующие лица: • Робот; • Кладовщик. Цели выполнения: • Укомплектовать оборудование. Предусловие: • Грейд сотрудника меньше 6. 64 Постусловие: • Оборудование укомплектовано Основной поток действий: 1. Заявка переходит в интерфейс кладовщику; 2. Кладовщик собирает комплектующие исходя из представленного списка; 2.1. Если все оборудование подошло. Кладовщик заносит данные об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка». Робот переходит к выполнению UC05; 2.2. Если комплектующие не подходят/их нет в наличии. Кладовщик заменяет комплектующие на другие и заносит информацию об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка» Робот переходит к выполнению UC05. UC03. Доставка Действующие лица: • Робот; • Логист. Цели выполнения: • Доставить оборудование сотруднику. Предусловие: • Оборудование успешно укомплектовано. Постусловие: • Оборудование успешно доставлено сотруднику; 65 • Оборудование не было доставлено. Основной поток действий: 1. В интерфейсе отображается заявка; 2. Логист выезжает по указанному в интерфейсе адресу: 2.1. Если оборудование успешно установлено. Логист фиксирует факт установки в интерфейсе. Статус заявки меняется на «Установлено» Робот, при надобности е настраивает ip-телефонию. Переход на UC04. 2.2. Если оборудование не было установлено. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не установлено». Заявка переходит в ручное управление диспетчером UC 05. UC04. Перенос оборудования Действующие лица: • Робот. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование успешно установлено. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 1. Робот входит в систему OEBS; 66 2. Робот находит карточку сотрудника: 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 2.2. Если оборудование установить не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC08. UC05. Оборудование не было установлено. Ручное управление диспетчером. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос установки оборудования. Предусловие: • Оборудование не было установлено. Постусловие: • Сотрудник подтвердил повторную доставку. • Диспетчер сохраняет заявку для рассмотрения в будущем; • Сотрудник отменил заявку. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не установлено; 2. Диспетчер связывается с сотрудником; 2.1. Если сотрудник запрашивает повторную доставку. Диспетчер отправляет оборудование в доставку. Статус заявки меняется на «Доставка». Переход на UC03. 67 2.2. Если сотрудник отменил заявку. Диспетчер делает возврат оборудования. Статус заявки меняется на «Возврат». Переход на UC11. 2.3. Если сотрудник сообщает, что получен не полный комплект оборудования. Диспетчер отправляет оборудование на доукомплектацию. Статус заявки меняется на «Комплектация». Переход на UC04. UC06. Возврат Действующие лица: • Логист; • Кладовщик; • Диспетчер. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно возвращено на склад. Основной поток действий: 1. Логист отвозит оборудование обратно на склад; 2. Кладовщик разукомплектовывает оборудование и информацию в ИМ; 3. Статус заявки меняется на «Отзыв RA». Переход к UC07. UC07. Отзыв RA Действующие лица: 68 заносит • Робот; Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен» Предусловие: • Статус заявки изменился на «Отзыв RA» Постусловие: • Cтатус заявки успешно изменен на «Отменен» Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен» UC08. Ручной перенос оборудования Действующие лица: • Диспетчер Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование не было автоматически перенесено с МОЛ на пользователя. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 69 2. Диспетчер находит карточку сотрудника; 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 2.2. Если оборудование перенести не удалось. Возврат к п.1. UC09. Ручное управление диспетчером. Выбор ПК/Ноутбук Действующие лица: • Диспетчер Цели выполнения: • Сотрудник выбрал оборудование для установки. Предусловие: • Сотрудник дал согласие на установку оборудования и грейд сотрудника больше или равен 6. Постусловие: • Диспетчер зафиксировал выбор сотрудника. Основной поток действий: 1. Диспетчер совершает звонок сотруднику; 1.1. Если был выбран вариант ПК. Статус заявки меняется на «Комплектация». Переход на UC02; 1.2. Если был выбран вариант ноутбук. Статус заявки меняется на «Доставка». Переход на UC03; 2. Диспетчер может не совершать звонок, а сохранить заявку. Статус заявки меняется на «Сохранено». Переход к UC09. 70 2.3.6 Описание процессов «Переезд» через варианты использования UC01. Взятие задачи в работу Роботом. Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • В Remedy появилась заявка с названием «Переезд». Постусловие: • Запущен процесс «Переезд». Основной поток действий: 1. Робот заходит на портал Remedy; 2. Робот отбирает заявку по запросу «Переезд» 3. Робот генерирует новую заявку на портале Route и автоматически определяет логиста, исходя из его местоположения. устанавливается «Получение» Переход к UC02. UC02. Забор Действующие лица: • Робот; • Логист. Цели выполнения: • Забрать оборудование сотрудника. 71 Статус заявки Предусловие: • Статус заявки изменен на «Забор». Постусловие: • Оборудование было успешно забрано; • Оборудование не было забрано. Основной поток действий: 1. В интерфейсе отображается заявка; 2. Логист выезжает по указанному в интерфейсе адресу: 2.1. Если оборудование успешно забрано. Логист фиксирует факт забора в интерфейсе. Статус заявки меняется на «Получено» Робот переходит на UC03. 2.2. Если оборудование не было забрано. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не получено». Заявка переходит в ручное управление диспетчером UC05. UC03. Доставка Действующие лица: • Робот; • Логист. Цели выполнения: • Доставить оборудование сотруднику. Предусловие: • Оборудование успешно забрано. Постусловие: 72 • Оборудование успешно доставлено сотруднику; • Оборудование не было доставлено. Основной поток действий: 1. В интерфейсе отображается заявка; 2. Логист выезжает по указанному в интерфейсе адресу; 2.1. Если оборудование успешно установлено. Логист фиксирует факт установки в интерфейсе. Статус заявки меняется на «Архив»; 2.2. Если оборудование не было установлено. Логист фиксирует этот факт в интерфейсе с комментарием проблемы. Статус заявки меняется на «Не установлено». Заявка переходит в ручное управление диспетчером UC 04. UC04. Оборудование не было установлено. Ручное управление диспетчером. Действующие лица: • Диспетчер; Цели выполнения: • Решить вопрос установки оборудования. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно установлено; • Диспетчер сохранил заявку для рассмотрения в будущем. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не установлено; 2. Диспетчер связывается с сотрудником: 73 2.1. Если сотрудник готов принять доставку. Диспетчер отправляет оборудование в доставку. Статус заявки меняется на «Доставка». Переход на UC03. 2.2. Если сотрудник не готов принять доставку. Диспетчер оставляет эту заявку на потом, пока сотрудник не сможет принять доставку. UC05. Оборудование не было забрано. Ручное управление диспетчером. Действующие лица: • Диспетчер Цели выполнения: • Решить вопрос забора оборудования. Предусловие: • Оборудование не было забрано. Постусловие: • Оборудование успешно забрано; • Сотрудник отменил заявку. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не забрано; 2. Диспетчер связывается с сотрудником; 2.1. Если сотрудник запрашивает повторный забор. Диспетчер отправляет логиста на забор. Статус заявки меняется на «Забор». Переход на UC02. 2.2. Если сотрудник отменил заявку. Диспетчер делает возврат оборудования. Статус заявки меняется на «Отзыв RA». Переход на UC06. 74 UC06. Отзыв RA Действующие лица: • Робот. Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен». Предусловие: • Статус заявки изменился на «Отзыв RA». Постусловие: • Cтатус заявки успешно изменен на «Отменен». Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен». 2.4 Выводы по второму разделу Во втором разделе — Проектирование программного обеспечения спроектированы схемы в нотации BPMN, состояниях AS-IS и TO-BE, и схема в нотации «IDEF0», отображающая основные потоки данных между компонентами системы, а также описаны все маршруты Робота по основным кейсам с помощью сценариев использования, представлены в Приложении 1 и Приложении 2. 75 остальные маршруты РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 3.1 Настройка CMS Strapi Для разработки Back-end части проекта используется CMS Strapi v4. Strapi представляет собой Фреймворк [22] для управления контентом, полностью настраиваемый и масштабируемый с помощью плагинов и расширений. В проекте реализованы следующие сущности — Content-Type Builder: 1. Action (Рисунок 14); Рисунок 14 — сущность Action 2. Delivery Point (Рисунок 15); 76 Рисунок 15 — сущность Delivery point 3. Delivery Zone (Рисунок 15); Рисунок 16 — сущность Delivery zone 4. Hardware Group (Рисунок 17); 77 Рисунок 17 — сущность Hardware Group 5. Hardware Model (Рисунок 18); Рисунок 18 — сущность Hardware Model 6. Hardware Type (Рисунок 19); 78 Рисунок 19— сущность Hardware Type 7. Incident (Рисунок 20); Рисунок 20.1 — сущность Incident 79 Рисунок 20.2— сущность Incident Рисунок 20.3 — сущность Incident 8. Notification (Рисунок 21); Рисунок 21 — сущность Notification 9. Log (Рисунок 22); 80 Рисунок 22 — сущность Log 10. Operation (Рисунок 23); Рисунок 23— сущность Operation 11. RemedyTAS (Рисунок 24); Рисунок 24 — сущность RemedyTAS 12. Status (Рисунок 25); Рисунок 25 — сущность Status 81 13. TAS (Рисунок 26); Рисунок 26 — сущность TAS 14. User (Рисунок 27); Рисунок 27 — сущность User 15. View (Рисунок 28); Рисунок 28 — сущность View 16. WorkTime (Рисунок 29). Рисунок 29 — сущность WorkTime 82 3.2 Автоматизация с помощью технологии RPA 3.2.1 Создание заявок в системе Для заведения заявки по кейсу «АРМ в день». Робот раз в час выгружает отчет «АРМ Отчёт для загрузки в 1С.xls» из OeBS.Этот отчет кладется в общую папку\\Mgts-scommon02\from_OEBS$. Сторонний скрипт находит новых сотрудников и заносит эту информацию в БД User_table. Исходя из занесенных данных в БД User_table и фильтров, описанных в Приложении 4, подходящих сотрудников робот заносит в БД Портала. Раз в день запускается скрипт «ArmToDay.ps1», которые каждый три минуты проверяет БД Портала на наличие новых заявок, не заведенных в ИС Remedy. Этот скрипт заводит заявку в ИС Remedy и полученный номер заявки заносит в БД портала. Для создания заявки по кейсу «Модернизация» реализован Python скрипт —«create_perfmon.py», который раз в день берет сделанную Роботом выгрузку из БД ITRobot, если Робот нашел оборудование, подходящее под критерии модернизации (подробная логика описана в Разделе 2.10.2.1), Робот заходит в Инфраменеджер и забирает дополнительную информацию по имени компьютера. Данный скрипт генерирует не более 2-х заявок в день — 10-ти в неделю и заносит их в БД Портала. По занесенной заявке скрипт — «Modern.ps1» генерирует запрос на обслуживание в ИС Remedy. Сгенерированный номер запроса заносится к уже созданной ранее заявке в БД Портала. Для создания заявки по кейсу «Увольнение». Робот был добавлен согласующим в заявке на увольнение, ему приходит письмо о факте согласования, что инициализирует запуск процесса, в выгрузке «FN1.xls» (OeBS) Робот проверяет наличие оборудования, закрепленного за пользователем, и, если такое есть, заносит собранную информацию в БД Портала, после чего генерирует запрос на обслуживание по кейсу «Увольнение» на портале и в ИС Remedy, с 83 помощью скрипта «BackEquip.ps1», указывая закрепленное за пользователем оборудование. Полученный номер запроса Скрипт заносит в БД Портала. Для создания заявки по остальным кейсам, Робот получает письма от ИС Remedy о факте создания заявки, Python скрипт — Create_incident.py, выгружает информацию из письма и заносит в БД Портала номер заявки и информацию из нее; В кейс «Прочее» попадают заявки, не вошедшие ни в одну из описанных выше категорий. 3.3 Написание PowerShell-скриптов Для корректной работы системы реализованы следующие скрипты 1. Определение логиста; 2. Определение конфигурации оборудования; 3. Занесение заявок в ИС Remedy по кейсам АРМ в день, модернизация, увольнение. Для определения разъездного инженера используются таблицы соответствий адресов зонам обслуживания. К каждой зоне прикреплён свой разъездной инженер. Алгоритм определения разъездного специалиста: 1. Поиск адреса в таблице соответствия адрес-зона. Если адрес не указан или не найден в таблице, выбор разъездного инженера с помощью генератора случайного выбора 2. Если адрес обнаружен, определение принадлежности адреса к зоне обслуживания согласно таблице соответствия адрес-зона 3. Определение разъездного инженера, закреплённого за зоной согласно таблице соответствия участок-инженер 84 4. Проверка наличия у инженера отпуска на текущий период в БД отпусков 5. В случае обнаружения отпуска у инженера определение заместителя согласно таблице соответствия инженер-заместитель 6. Для найденного заместителя повтор операций проверки отпуска и поиска заместителя 7. Назначение выбранного разъездного инженера Выбор конфигурации ПК осуществляется исходя из грэйда сотрудника, на основании результатов сравнения ПК (БД ИнфраМенеджер) пользователей того же подразделения и должности, а также превышений нагрузки на ПК (Elastic): 1. Для сотрудников с грейдом 7 и выше - по согласованию улучшенная конфигурация или ноутбук (КК3.1, КМ2, КТ2 или КН3, КТ2) 2. Для сотрудников с грейдом 6 - по согласованию улучшенная конфигурация или улучшенный ноутбук (КК3.1, КМ2, КТ2 или КН2, КТ2) 3. Для сотрудников с грейдом 5 и ниже: 3.1. Выборка из БД ИнфраМенеджер всех членов отдела с аналогичной должностью, если таковые отсутствуют, то присваивается базовая конфигурация 3.2. Выбор пользователей с младшей конфигурацией ПК. Если пользователи с ПК стандартных конфигураций не найдены, то присваивается базовая конфигурация 3.3. Проверка превышения нагрузки на ПК по данным Elastic, если превышение зарегистрировано, то присваивается конфигурация уровнем выше 85 3.4. Если пользователь состоит в Блоке информационных технологий или Отделе технологий информационной безопасности, то выдаётся второй монитор Для занесения информации в ИС Remedy используются скрипты: 1. ArmToDay.ps1; 2. Modern.ps1; 3. BackEquip. Данные скрипты заходят в БД Портала и ищут заявки, которые не заведены в ИС Remedy. Найдя такую заявку скрипт забирает информацию из БД Портала, необходимую для создания заявки. После того, как скрипт полностью выгрузил информацию по заявке он создает ее в Remedy и записывает номер созданной заявке в БД Портала. 3.4 Тестирование системы Тестирование системы будет проводиться на показе бизнес-заказчику с помощью документа — ПМИ [23] — программа и методика испытаний. На основе прохождения тест-кейсов [24], будет приниматься решение о введение системы в эксплуатацию. Испытания проводятся по адресу: г. Москва, Докучаев переулок, дом 9, корпус 1, этаж 4, опенспейс. Продолжительность испытаний составляет четыре часа. Результаты испытаний должны быть зафиксированы в Протоколе испытаний и предоставлены на утверждение Заказчику. Приемо-сдаточные испытания состоят из следующих этапов: • Проверка комплектности пользовательской документации; 86 и качества эксплуатационной и • Проверка работоспособности ПО; • Проверка соответствия доработок ПО требованиям ТЗ. Оценки фиксируются в «Протоколе проведения испытаний». Протокол проведения испытаний согласовывается и подписывается членами Приемочной комиссии. Система считается принятой, если отсутствуют оценки «испытание не пройдено» и выполнены все критерии, изложенные в Таблице 5. В случае если испытания проводятся в условиях не соответствующих проектной документации, и присутствуют оценки «испытание не пройдено», c примечанием о том, что причинами не пройденного испытания являются условия, не зависящие от Исполнителя, система принимается с замечаниями, которые фиксируются в протоколе испытаний с пометкой способов и сроков устранения. Таблица 5. Критерии оценки выполнения проверок № Необходимый Расшифровка Критерий параметр Реализованная ПО функциональность, 1. описанная в 2. комиссии приемочной отвечает требованиям 100% ФТ документации Приемка критерия 100%, нет критичных замечаний 87 Оценка критерия Выполнено/Не выполнено Выполнено/Не выполнено № Необходимый Расшифровка Критерий параметр Наличие документации 3. по испытанию критерия Наличие 100% актуальной версии ПМИ Оценка критерия Выполнено/Не выполнено Наличие эксплуатационной 4. и пользовательской Выполнено/Не 100% выполнено документации 1. Рабочая группа проверяет выполнение всех условий, необходимых для начала испытаний. В случае выявления несоответствий с рабочей документацией, они фиксируются в Протоколе проведения испытаний, при этом часть проверок может быть исключена из испытаний; 2. Рабочая группа проводит испытания ПО в объеме проверок, предусмотренных разделом; 3. Данный объем проверок является необходимым и достаточным для принятия решения о приемке ПО в опытную эксплуатацию; 4. Рабочая группа фиксирует выявленные в процессе испытаний замечания к ПО и рекомендации по улучшению; 5. Рабочая группа фиксирует результаты испытаний в документе «Протоколе проведения испытаний»; 6. При успешном исходе испытаний Рабочая группа принимает решение о приемке ПО в эксплуатацию, оформляет и подписывает протокол и акт приемки-передачи в эксплуатацию; 7. В случае неуспешного исхода испытаний, рабочей группой составляется список ошибок и доработок для устранения ошибок в системе. 88 Тест-кейс 1. АРМ в день. 3.5 Успешная установка нового оборудования Номер Ошибка! Источник ссылки не найден. Название АРМ в день. Успешная установка нового Успешная установка нового оборудования ВИ АРМ в день. оборудования, при согласии руководителя вновь принятого сотрудника Задействованные CUCM, Route, Uipath, ВП, OEBS, ИМ системы Подготовка В выгрузке из OEBS добавить нового сотрудника Результат Оборудование успешно установлено № Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок произведен, звонок пользователю пользователь дал шага положительный ответ 3 Route Укомплектовать заказ В интерфейсе кладовщика отразилась заявка со статусом «Комплектация» 89 4 Route Доставить заказ В интерфейсе логиста отразилась заявка со статусом «Доставка» 5 CUCM Настроить ip- Ip-телефония настроена телефонию 6 OEBS, Перемещение Оборудование перемещено ИМ оборудования в ИС с МОЛ ИТ на пользователя учета 7 Uipath Успешно закрыть В интерфейсе статус заявку заявки изменился на «Архив» 3.6 Тест-кейс 2. АРМ в день. Заявка отменена. Номер Тест-кейс 2 Название АРМ в день. Заявка отменена ВИ АРМ в день. Заявка отменена, в связи с отказом руководителя сотрудника. Задействованные Uipath, ВП системы Подготовка В выгрузке из OEBS добавить нового сотрудника Результат Руководитель вновь принятого сотрудника дал отказ, заявка отменена 90 № Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок произведен, звонок пользователь дал шага отрицательный ответ 3 Uipath Отменить заявку В интерфейсе статус заявки изменился на «Отменен» 3.7 Тест-кейс 3. АРМ в день. Пользователь не ответил на звонок ВП. Номер Тест-кейс 3 Название АРМ в день. Заявка не подтверждена ВИ АРМ в день. руководителем. Не Заявка не подтверждена было ответа на звонок виртуального помощника. Задействованные Route, Uipath, ВП системы Подготовка В выгрузке из OEBS добавить нового сотрудника Результат Умный помощник руководителя принятого передана диспетчеру 91 не смог дозвониться сотрудника, до заявка № Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок произведен, звонок пользователю пользователь не дал ответа Передать заявку на В интерфейсе диспетчера самостоятельное появилась заявка шага 3 Route рассмотрение диспетчеру 4 Route Оповестить Пользователь оповещен. пользователя самостоятельно Если руководитель нанято сотрудника отказался от установки оборудования – в интерфейсе статус заявки меняется на «Отменен». Если руководитель согласился на установку оборудования статус заявки меняется на «Комплектация». Переход к кейсу «АРМ в день» №1, шагу 3. Если руководитель нанятого сотрудника не 92 ответил на звонок 3 раза с интервалом в 30 минут – диспетчер сохраняет заявку, чтобы вернуться к ней позже. Статус заявки меняется на «Сохранено» Тест-кейс 4. АРМ в день. Невозможно установить оборудование. 3.8 Номер Тест-кейс 4 Название АРМ в день. Невозможно установить оборудование ВИ АРМ в день. Невозможно установить оборудование, в виду отсутствия необходимых требований для эксплуатации. Задействованные Route, Uipath, ВП системы Подготовка В выгрузке из OEBS добавить нового сотрудника Результат Заявка передана диспетчеру № Система Воздействие 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок произведен, звонок пользователю руководитель вновь шага 93 Результат принятого сотрудника дал положительный ответ 3 Route Укомплектовать заказ В интерфейсе кладовщика отразилась заявка 4 Route Доставить заказ В интерфейсе логиста отразилась заявка 5 6 Route Route Передать заявку Заявка передана диспетчеру диспетчеру в ручное управление Диспетчер принимает Диспетчер может: решение по заявке • Передать заявку в доставку – статус заявки «Доставка». Переход к кейсу АРМ в день №1 шаг 4. • Отменить заявку – в интерфейсе статус заявки меняется на «Отменено» • Отправить оборудование на доукомплектацию – статус меняется на «Комплектация», переход к кейсу АРМ в день №1 шаг 3 94 3.9 Выводы по третьему разделу В заключительном, третьем разделе описывается этап разработки программного обеспечения, а именно настройка CMS Strapi, логика разработки PowerShell скриптов. Также в разделе представлены тест-кейсы и методика проведения приемо-сдаточных работ по выполненной системе 95 ЗАКЛЮЧЕНИЕ В ходе выполнения выпускной квалификационной работы были успешно выполнены следующие задачи: 1. Ознакомились и изучили предметную область, включая внутренние стандарты и регламенты компании ПАО «МГТС» 2. Провели анализ существующего в компании бизнес процесса и спроектировали вариант его оптимизации 3. Реализовали системные статусы для отслеживания этапов работы с оборудованием; 4. Описали основные бизнес процессы в нотации BPMN, а также все взаимодействие Роботов с внутренними системами с помощью вариантов использования; 5. Реализовали пользовательский интерфейс; 6. Спроектировали и развернули контейнер для взаимодействия компонентов внутри архитектуры с помощью CMS Strapi и плагинов для него; 7. Настроили Роботов для работы с внутренними компонентами организации; 8. Реализовали работу голосового помощника; В первом разделе — Анализ предметной области был проведен системный анализ, описаны роли, необходимые для корректной работоспособности системы, описаны входные и выходные информационные потоки, конкретно кейсы «АРМ в день», «Модернизация» и «Увольнение». Далее были обозрены инструменты разработки и продукты-аналоги проектируемой системы, что позволило подчеркнуть оригинальность и актуальность разрабатываемой системы, а также выявить недостатки уже существующих систем, для избежание повтора схожих ошибок в будущем. В заключение раздела выделены системные 96 и бизнес требования к системе, требования к порталу, мероприятия по внедрению ИС и мероприятия по сопровождению системы, по данным требованиям и будет проектироваться будущая система. Во втором разделе — Проектирование программного обеспечения спроектированы схемы в нотации BPMN, состояниях AS-IS и TO-BE, и схема в нотации «IDEF0», отображающая основные потоки данных между компонентами системы, а также описаны все маршруты Робота по основным кейсам с помощью сценариев использования, остальные маршруты представлены в Приложении 1 и Приложении 2. В заключительном, третьем разделе описывается этап разработки программного обеспечения, а именно настройка CMS Strapi, логика разработки PowerShell скриптов. Также в разделе представлены тест-кейсы и методика проведения приемо-сдаточных работ по выполненной системе. Разработанная система, позволила сократить количество персонала, работающего над одной задачей, сократить время выдачи оборудования вновь принятому сотруднику до одного рабочего дня, что на данный момент нигде более не достигнуто. Выполненная автоматизация позволила вести более детальный и глубокий учет всех действий персонала, сопутствующего доставке и установке оборудования. Также были оптимизированы не основные кейсы, такие как: 1. «Переезд» - теперь при перемещении места работы сотрудника, ему достаточно оформить заявку на корпоративном портале, всю остальную работу сделают разъездные специалисты. 2. «Диагностика» - в случае поломки оборудования или любых проблем с работой ПК, сотрудник столкнувшийся с проблемой также может оставить заявку на портале, после чего заявка появится в системе, и с ней могут работать специалисты. 97 3. «Прочее» - в данный раздел попали все остальные кейсы, которые не получается обозначить как одни из уже описанных, либо же если сотрудник сам не понимает в чем у него проблема и хочет проконсультироваться по данному вопросу со специалистом. Кроме того, все шаблонные переговоры теперь вместо диспетчера производит реализованный в рамках проекта виртуальный голосовой помощник, который в случае возникновения проблем переводит звонок на диспетчера. Благодаря этому решению более 50% заявок теперь обрабатываются без деятельности диспетчера, что также ускоряет время обработки заявок и освобождает диспетчера, перекладывая на него другие не менее важные операции. 98 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 1 МГТС [ Электронный ресурс] — 2022 — URL:https://mgts.ru/company/ дата обращения: 10.11.2022). 2 OeBS [Электронный ресурс] — 2022 — URL: https://www.oracle.com/cis/applications/ebusiness/ (дата обращения: 14.11.2022). 3 Active Directory [Электронный ресурс] — 2022 — URL: https://learn.microsoft.com/ru-ru/windows-server/identity/ad-ds/get-started/virtualdc/active-directory-domain-services-overview / (дата обращения: 18.10.2022). 4 CUCM [Электронный ресурс] — 2022 — URL: https://www.cisco.com/c/en/us/products/unified-communications/unifiedcommunications-manager-callmanager/index.html (дата обращения: 04.11.2022). 5 Python [Электронный ресурс] — 2022 — URL: https://docs.python.org/3/ (дата обращения: 04.11.2022). 6 HTML [Электронный ресурс] — 2022 — URL: https://developer.mozilla.org/ru/docs/Web/HTML (дата обращения: 10.11.2022). 7 CSS [Электронный ресурс] — 2022 — URL: https://developer.mozilla.org/ru/docs/Web/CSS/Reference (дата обращения: 10.11.2022). 8 JS [Электронный ресурс] — 2022 — URL: https://developer.mozilla.org/ru/docs/Web/JavaScript (дата обращения: 10.11.2022). 9 CMS Strapi [Электронный ресурс] — 2022 — URL: https://docs.strapi.io/developer-docs/latest/getting-started/introduction.html (дата обращения: 10.11.2022). 10 Docker [Электронный ресурс] — 2022 — URL: https://docs.docker.com/ (дата обращения: 12.11.2022). 11 PowerShell [Электронный ресурс] — 2022 — URL: https://learn.microsoft.com/ru-ru/powershell/ (дата обращения: 04.11.2022). 99 12 RPA[Электронный ресурс] — 2022 — URL: https://habr.com/ru/company/uipath/blog/574342/ (дата обращения: 05.10.2022). 13 UiPath [Электронный ресурс] — 2022 — URL: https://docs.uipath.com/ (дата обращения: 05.10.2022). 14 C# [Электронный ресурс] — 2022 — URL: https://learn.microsoft.com/ru-ru/dotnet/csharp/ (дата обращения: 05.10.2022). 15 Asterisk[Электронный ресурс] — 2022 — URL: https://asterisk- pbx.ru/wiki/asterisk/asterisk (дата обращения: 04.11.2022). 16 Робот[Электронный ресурс] — 2022 — URL: https://vc.ru/newtechaudit/120260-avtomatizaciya-s-pomoshchyu-robotov-rpa (дата обращения: 05.10.2022). 17 Oracle Linux [Электронный ресурс] — 2022 — URL: https://www.oracle.com/cis/linux/ (дата обращения: 20.12.2022). 18 PostgreSQL [Электронный ресурс] — 2022 — URL: https://www.postgresql.org/ (дата обращения: 20.12.2022). 19 Linux Debian [Электронный ресурс] — 2022 — URL: https://www.debian.org/doc/ (дата обращения: 20.11.2022). 20 IDEF0 [Электронный ресурс] — 2022 — URL: https://habr.com/ru/sandbox/31234/ (дата обращения: 25.12.2022). 21 BPMN [Электронный ресурс] — 2022 — URL: https://habr.com/ru/company/auriga/blog/667084/ (дата обращения: 25.12.2022). 22 Варианты использования — use-case [Электронный ресурс] — 2022 — URL: https://www.cybermedian.com/ru/use-case-description-example/ (дата обращения: 25.12.2022). 23 ПМИ — программа и методика испытаний [Электронный ресурс] — 2022 — URL: https://docs.cntd.ru/document/1200007650 (дата обращения: 06.01.2023). 24 Тест-кейсы [Электронный ресурс] — 2022 — URL: https://habr.com/ru/post/246463/ (дата обращения: 06.01.2023). 100 25 БоссРеферент [Электронный ресурс] — 2022 — URL: https://portal.pnu.edu.ru/manual/boss_referent/index.html (дата обращения: 10.11.2022). 26 1С:Предприятие [Электронный ресурс] — 2022 — URL: https://its.1c.ru/db/v838doc (дата обращения: 17.11.2022). 27 ТИС-online [Электронный ресурс] — 2022 — URL: https://tis- online.com/instruktsii/ (дата обращения: 17.11.2022). 28 АРМ. Экспедитор[Электронный ресурс] — 2022 — URL: http://www.itmservice.ru/software/arm-expeditor/ (дата обращения: 17.11.2022). 101 ПРИЛОЖЕНИЕ 1— Описание процессов «Прочее» через варианты использования UC01. Взятие задачи в работу Роботом. Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • В Remedy появилась заявка, не подходящая под категории, описанные выше. Постусловие: • Запущен процесс «Диагностика». Основной поток действий: 1. Робот заходит на портал Remedy; 2. Робот отбирает заявку по запросу не подходящую под категории, описанные выше; 3. Робот генерирует на портале Route новую заявку и автоматически определяет логиста, исходя из его местоположения. Статус заявки устанавливается «Диагностика» Переход к UC02. UC02.Диагностика ПК. Действующие лица: • Робот; 102 • Логист. Цели выполнения: • Выявить неисправность в работе ПК. Предусловие: • Создана заявка со статусом «Диагностика». Постусловие: • Компьютер продиагностирован. Проблема решена; • Компьютер продиагностирован. Проблема не решена. Основной поток действий: 1. Логист связывается с пользователем и проводит диагностику ПК: 1.1. Если проблема решена и выявлена. Статус заявки меняется на «Архив»; 1.2. Если проблема не решена. Логист оставляет комментарий в интерфейсе. Статус меняется на «Продиагностировано». Заявка переходит в ручное управление диспетчеру. Переход к UC03. UC03.Ручное управление. Диагностика ПК. Действующие лица: • Диспетчер. Цели выполнения: • Решение проблемы с диагностикой ПК. Предусловие: • Проблема с ПК не была решена. Постусловие: 103 • Проблема с ПК решена; • Проблема с ПК не решена. Требуется повторная диагностика; • Проблема с ПК решена. Требуется модернизация. Сотрудник согласен на модернизацию; • Проблема с ПК решена. Требуется модернизация. Сотрудник не согласен на модернизацию; Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Продиагностировано»; 2. Диспетчер связывается с сотрудником и на основе комментариев сотрудника и логиста делает следующее: 2.1. Если проблема решена. Статус заявки меняется на «Архив»; 2.2. Если проблема не решена и требуется повторная диагностика. Статус заявки меняется на диагностика. Переход к UC02; 2.3. Если проблему не решить диагностикой и требуется модернизация ПК. Статус заявки меняется на «Модернизация». 2.3.1. Диспетчер связывается с сотрудником и сообщает ему о надобности модернизации: 2.3.1.1. Если пользователь согласен на модернизацию. Статус заявки меняется на «Комплектация». Переход к UC04; 2.3.1.2. Если пользователь не согласен на модернизацию. Статус заявки меняется на «Отзыв RA». Переход к UC09. UC04. Комплектация. Действующие лица: • Робот; • Кладовщик. 104 Цели выполнения: • Укомплектовать оборудование. Предусловие: • Пользователь согласен на модернизацию. Постусловие: • Оборудование укомплектовано. Основной поток действий: 1. Заявка переходит в интерфейс кладовщику; 2. Кладовщик собирает комплектующие исходя из представленного списка; 2.1. Если все оборудование подошло. Кладовщик заносит данные об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка. Робот переходит к выполнению UC05; 2.2. Если комплектующие не подходят/их нет в наличии. Кладовщик заменяет комплектующие на другие и заносит информацию об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка» Робот переходит к выполнению UC05. UC05 Доставка Действующие лица: • Робот; • Логист. Цели выполнения: • Доставить оборудование сотруднику. Предусловие: 105 • Оборудование успешно укомплектовано. Постусловие: • Оборудование успешно доставлено сотруднику; • Оборудование не было доставлено сотруднику. Основной поток действий: 1. В интерфейсе отображается заявка 2. Логист выезжает по указанному в интерфейсе адресу 2.1. Если оборудование успешно установлено. Логист фиксирует факт установки в интерфейсе. Статус заявки меняется на «Перемещение» Робот переходит на UC06. 2.2. Если оборудование не было установлено. Логист фиксирует этот факт в своем интерфейсе с комментарием проблемы. Статус заявки меняется на «не установлено». Заявка переходит в ручное управление диспетчером. Переход к UC08 UC06. Перенос оборудования Действующие лица: • Робот. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование успешно установлено Постусловие: • Оборудование успешно перенесено; 106 • Оборудование не было перенесено. Основной поток действий: 1. Робот входит в систему OEBS; 2. Робот находит карточку сотрудника; 3. Робот переносит данные с МОЛ на пользователя: 3.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 3.2. Если оборудование установить не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC07. UC07. Ручной перенос оборудования Действующие лица: • Диспетчер. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование не было автоматически перенесено с МОЛ на пользователя. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 2. Диспетчер находит карточку сотрудника и заполняет ее вручную; 107 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив». 2.2. Если перенести оборудование не удалось. Переход к п.1. UC08. Оборудование не было установлено. Ручное управление диспетчером. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос установки оборудования. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно установлено; • Сотрудник отказался от установки оборудования; • Диспетчер сохраняет заявку для рассмотрения в будущем. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не установлено; 2. Диспетчер связывается с сотрудником: 2.1. Если сотрудник готов принять доставку. Диспетчер отправляет оборудование в доставку. Статус заявки меняется на «Доставка». Переход на UC05. 2.2. Если сотрудник не готов принять доставку. Диспетчер оставляет эту заявку на потом, пока сотрудник не сможет принять доставку. 108 2.3. Если сотрудник хочет отменить заявку. Диспетчер отменяет заявку. Статус заявки изменяется на «Возврат». Переход к UC10. UC09. Отзыв RA Действующие лица: • Робот; Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен» Предусловие: • Статус заявки изменился на «Отзыв RA» Постусловие: • Cтатус заявки успешно изменен на «Отменен» Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен» UC10. Возврат Действующие лица: • Логист; • Кладовщик; • Диспетчер. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование не было установлено. 109 Постусловие: • Оборудование успешно возвращено на склад. Основной поток действий: 1. Логист отвозит оборудование обратно на склад; 2. Кладовщик разукомплектовывает оборудование и заносит информацию в ИМ; 3. Статус заявки меняется на «Отзыв RA». Переход к UC09. 110 ПРИЛОЖЕНИЕ 2—Описание процессов «Диагностика» через варианты использования UC01. Взятие задачи в работу Роботом. Действующие лица: • Робот. Цели выполнения: • Запуск процесса. Предусловие: • В Remedy появилась заявка на диагностику оборудования. Постусловие: • Запущен процесс «Диагностика». Основной поток действий: 1. Робот заходит на портал Remedy; 2. Робот отбирает заявку по запросу «Диагностика»; 3. Робот генерирует новую заявку на портале Route и автоматически определяет логиста, исходя из его местоположения. Статус заявки устанавливается «Диагностика» Переход к UC02. UC02.Диагностика ПК. Действующие лица: • Робот; • Логист. Цели выполнения: 111 • Выявить неисправность в работе ПК. Предусловие: • Создана заявка со статусом «Диагностика». Постусловие: • После диагностики проблема выявлена и решена; • Не удалось выявить проблему. Основной поток действий: 1. Логист связывается с пользователем и проводит диагностику ПК: 1.1. Если проблема решена и выявлена. Статус заявки меняется на «Архив»; 1.2. Если проблема не решена. Логист оставляет комментарий в интерфейсе. Статус меняется на «Продиагностировано». Заявка переходит в ручное управление диспетчеру. Переход к UC03. UC03.Ручное управление. Диагностика ПК. Действующие лица: • Диспетчер. Цели выполнения: • Решение проблемы с диагностикой ПК. Предусловие: • Логист не решил проблему с ПК. Постусловие: • Проблема выявлена и решена; • Проблема выявлена, требуется модернизация ПК; 112 • Проблема выявлена, требуется модернизация ПК. Пользователь отказался от модернизации; • Проблема не решена, требуется повторная диагностика. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Продиагностировано»; 2. Диспетчер связывается с сотрудником и на основе комментариев сотрудника и логиста делает следующее: 2.1. Если проблема решена. Статус заявки меняется на «Архив»; 2.2. Если проблема не решена и требуется повторная диагностика. Статус заявки меняется на диагностика. Переход к UC02; 2.3. Если проблему не решить диагностикой и требуется модернизация ПК. Статус заявки меняется на «Модернизация». 2.3.1. Диспетчер связывается с сотрудников и сообщает ему о надобности модернизации: 2.3.1.1. Если пользователь согласен на модернизацию. Статус заявки меняется на «Комплектация». Переход к UC04; 2.3.1.2. Если пользователь не согласен на модернизацию. Статус заявки меняется на «Отзыв RA». Переход к UC09. UC04. Комплектация. Действующие лица: • Робот; • Кладовщик. Цели выполнения: • Укомплектовать оборудование. 113 Предусловие: • Пользователь согласен на модернизацию. Постусловие: • Оборудование укомплектовано. Основной поток действий: 1. Заявка переходит в интерфейс кладовщику; 2. Кладовщик собирает комплектующие исходя из представленного списка; 2.1. Если все оборудование подошло. Кладовщик заносит данные об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка. Робот переходит к выполнению UC05; 2.2. Если комплектующие не подходят/их нет в наличии. Кладовщик заменяет комплектующие на другие и заносит информацию об оборудовании в свой интерфейс по представленной форме. Статус заявки меняется на «Доставка» Робот переходит к выполнению UC05. UC05 Доставка Действующие лица: • Робот; • Логист. Цели выполнения: • Доставить оборудование сотруднику. Предусловие: • Оборудование успешно укомплектовано. Постусловие: 114 • Оборудование успешно доставлено сотруднику; • Оборудование не было доставлено сотруднику. Основной поток действий: 1. В интерфейсе отображается заявка 2. Логист выезжает по указанному в интерфейсе адресу 2.1. Если оборудование успешно установлено. Логист фиксирует факт установки в интерфейсе. Статус заявки меняется на «Перемещение» Робот переходит на UC06. 2.2. Если оборудование не было установлено. Логист фиксирует этот факт в своем интерфейсе с комментарием проблемы. Статус заявки меняется на «не установлено». Заявка переходит в ручное управление диспетчером. Переход к UC08 UC06. Перенос оборудования Действующие лица: • Робот. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование успешно установлено Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 115 1. Робот входит в систему OEBS; 2. Робот находит карточку сотрудника; 3. Робот переносит данные с МОЛ на пользователя: 3.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив»; 3.2. Если оборудование установить не удалось. Статус заявки меняется на «Ошибка переноса». Заявка переходит в ручное управление диспетчеру. Переход на UC07. UC07. Ручной перенос оборудования Действующие лица: • Диспетчер. Цели выполнения: • Перенести оборудование с МОЛ на пользователя. Предусловие: • Оборудование не было автоматически перенесено с МОЛ на пользователя. Постусловие: • Оборудование успешно перенесено; • Оборудование не было перенесено. Основной поток действий: 1. Диспетчер входит в систему OEBS; 2. Диспетчер находит карточку сотрудника и заполняет ее вручную; 2.1. Если перенести оборудование удалось. Статус заявки меняется на «Архив». 116 2.2. Если перенести оборудование не удалось. Переход к п.1. UC08. Оборудование не было установлено. Ручное управление диспетчером. Действующие лица: • Диспетчер. Цели выполнения: • Решить вопрос установки оборудования. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно установлено; • Сотрудник отменил заявку4 • Диспетчер сохранил заявку для рассмотрения в будущем. Основной поток действий: 1. Диспетчер «проваливается» в заявку со статусом «Не установлено; 2. Диспетчер связывается с сотрудником: 2.1. Если сотрудник готов принять доставку. Диспетчер отправляет оборудование в доставку. Статус заявки меняется на «Доставка». Переход на UC05. 2.2. Если сотрудник не готов принять доставку. Диспетчер оставляет эту заявку на потом, пока сотрудник не сможет принять доставку. 2.3. Если сотрудник хочет отменить заявку. Диспетчер отменяет заявку. Статус заявки изменяется на «Возврат». Переход к UC10. 117 UC09. Отзыв RA Действующие лица: • Робот; Цели выполнения: • Смена статуса с «Отзыв RA» на «Отменен» Предусловие: • Статус заявки изменился на «Отзыв RA» Постусловие: • Cтатус заявки успешно изменен на «Отменен» Основной поток действий: 1. Робот меняет статус заявки с «Отзыв RA» на «Отменен» UC10. Возврат Действующие лица: • Логист; • Кладовщик; • Диспетчер. Цели выполнения: • Вернуть оборудование на склад. Предусловие: • Оборудование не было установлено. Постусловие: • Оборудование успешно возвращено на склад. 118 Основной поток действий: 1. Логист отвозит оборудование обратно на склад; 2. Кладовщик разукомплектовывает оборудование и заносит информацию в ИМ; 3. Статус заявки меняется на «Отзыв RA». Переход к UC09. ПРИЛОЖЕНИЕ 3 — Остальные тест-кейсы Тест-кейс 1. Модернизация. Успешная модернизация оборудования Номер Ошибка! Источник ссылки не найден. Название Модернизация. Успешная модернизация оборудования ВИ Модернизация. Пользователь дал согласие на модернизацию. Оборудование успешно установлено Задействованные Route, Uipath, ВП, OEBS, ИМ системы Подготовка Обнаружена необходимость модернизации оборудования Результат № шага 1 Оборудование модернизировано Система Воздействие Результат Uipath Создать заявку Заявка создана 119 2 3 ВП Route Инициализировать Звонок произведен, звонок-оповещение пользователь пользователю положительный ответ Укомплектовать заказ В интерфейсе кладовщика дал отразилась заявка 4 Route Доставить заказ В интерфейсе логиста отразилась заявка, оборудование успешно установлено 5 OEBS, Перемещение ИМ оборудования Оборудование перемещено в ИС с МОЛ ИТ на пользователя учета 6 Uipath Успешно закрыть Статус заявки изменен на заявку «Архив» Тест-кейс 2. Модернизация. Заявка отклонена пользователем Номер Тест-кейс 2 Название Модернизация. Заявка отклонена пользователем ВИ Модернизация. Пользователь дал отказ на запрос виртуального установлено Задействованные Uipath, ВП системы 120 помощника. Оборудование не Подготовка Обнаружена необходимость модернизации не работы по не было оборудования Результат Пользователь модернизации. согласовал Оборудование модернизировано № Система Воздействие Результат 1 Uipath Создать заявку Заявка создана 2 ВП Инициализировать Звонок звонок-оповещение пользователь пользователю отрицательный ответ Отменить заявку Статус заявки изменен на шага 3 Uipath произведен, дал «Отменено» Тест-кейс 3. Модернизация. Заявка не подтверждена Заявка не подтверждена Заявка не подтверждена пользователем Номер Тест-кейс 3 Название Модернизация. пользователем ВИ Модернизация. пользователем при звонке виртуального помощника 121 Задействованные Route, Uipath, ВП системы Подготовка Обнаружена необходимость модернизации оборудования Результат Пользователь не подтвердил заявку. Заявка передана диспетчеру № Система Воздействие Результат 1 Uipath Создать заявку Заявка создана 2 ВП Инициализировать Звонок звонок-оповещение пользователь не ответил на пользователю звонок шага 3 Route Передать заявку самостоятельное произведен, на В интерфейсе диспетчера появилась заявка рассмотрение диспетчеру 4 Uipath Пометить заявку Статус заявки изменен на переданной в ручное «Не подтвержден», заявка управление передана в ручное управление диспетчеру 5 Route Оповестить пользователя самостоятельно 122 Пользователь оповещен. Если сотрудник отказался от модернизации оборудования– в интерфейсе статус заявки меняется на «Отменен». Если сотрудник согласился на модернизацию оборудования заявки статус меняется на «Комплектация». Переход к кейсу «Модернизация» №1, шагу 3. Если нанятого руководитель сотрудника не ответил на звонок 3 раза с интервалом в 30 минут – диспетчер сохраняет заявку, чтобы вернуться к ней позже. Статус заявки меняется на «Сохранено» Тест кейс 4. Модернизация. Невозможно установить оборудование Номер Тест-кейс 4 Название Модернизация. Невозможно установить Невозможно установить оборудование ВИ Модернизация. оборудование, в виду отсутствия необходимых требований для эксплуатации. 123 Задействованны Route, Uipath, ВП е системы Подготовка Обнаружена необходимость модернизации оборудования Результат № Заявка передана диспетчеру Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок звонок пользователю пользователь шага произведен, дал положительный ответ 3 Route Укомплектовать заказ В интерфейсе кладовщика отразилась заявка 4 Route Доставить заказ В интерфейсе логиста отразилась заявка, оборудование не было установлено в виду отсутствия необходимых требований для эксплуатации. 5 Route Передать заявку ручное управление 124 в В интерфейсе диспетчера отобразилась заявка 6 Route Диспетчер принимает Диспетчер может: решение по заявке • Передать заявку в доставку – статус заявки «Доставка». Переход к кейсу «Модернизация» №1, шагу 4. • Отменить заявку – в интерфейсе статус заявки меняется на «Отменено» • Отправить оборудование на доукомплектацию – статус меняется на «Комплектация», «Модернизация» №1, шагу 3. Тест-кейс 1. Возврат. Успешный возврат оборудования Номер Ошибка! Источник ссылки не найден. Название Возврат. Успешный возврат оборудования ВИ Возврат. Успешный возврат оборудования после подтверждения пользователем Задействованные Route, Uipath, ВП, OEBS, ИМ системы Подготовка В БР пришел обходной лист на увольняющегося сотрудника Результат Оборудование успешно возвращено 125 № Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок звонок пользователю пользователь оповещен Забрать заказ В шага 3 Route произведен, интерфейсе логиста отразилась заявка, заказ забран на склад 4 Route Разукомплектовать В интерфейсе кладовщика заказ отразилась заявка, заказ разукомплектован 5 OEBS, Перемещение ИМ оборудования Оборудование перемещено в ИС с пользователя на МОЛ ИТ учета 6 Uipath Успешно закрыть Статус заявки изменен на заявку «Архив» Тест-кейс 2. Возврат. Сотрудник не подтвердил заявку Номер Тест-кейс 2 Название Возврат. Сотрудник не подтвердил заявку ВИ Возврат. Заявка не подтверждена. Пользователь не ответил на звонок виртуального помощника. 126 Задействованные Uipath, ВП, Route системы Подготовка В БР пришел обходной лист на увольняющегося сотрудника Результат Заказ не был подтвержден. Заявка передана в распоряжение диспетчеру № Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок звонок пользователю пользователь не ответил на шага произведен, звонок виртуального помощника 3 Route Передать заявку Заявка диспетчеру передана в диспетчеру Далее ручные действия – доставка или отмена Тест-кейс 3. Возврат. Оборудование не возвращено Номер Тест-кейс 3 Название Возврат. Оборудование не возвращено ВИ Возврат. Оборудование не возвращено. Не получилось забрать оборудование у пользователя 127 Задействованны Route, Uipath, ВП е системы Подготовка В БР пришел обходной лист на увольняющегося сотрудника Результат Оборудование не возвращено. Заказ переходит в распоряжение диспетчеру № Система Воздействие Результат 1 Uipath Создать новую заявку Заявка создана 2 ВП Инициализировать Звонок звонок пользователю пользователь шага произведен, дал положительный ответ 3 Route Забрать заказ В интерфейсе логиста отразилась заявка, заказ не был забран на склад 4 Route Передать заявку Заявка диспетчеру 5 Route передана диспетчеру Диспетчер вопрос с Диспетчер может заявкой • Отправить логиста на повторный забор – статус заявки меняется на «Забор», переход к кейсу «Возврат» №1, шаг3. 128 • Отменить заявку – статус заявки в интерфейсе меняется на «Отменен» Тест-кейс 1. Внеплановая потребность. Успешная установка оборудования Номер Ошибка! Источник ссылки не найден. Название Внеплановая потребность. Успешная установка оборудования ВИ Внеплановая потребность. Успешная установка оборудования Задействованные CUCM, Route, Uipath, Remedy, OEBS, ИМ системы Подготовка Появилась заявка в Remedy Результат Оборудование успешно установлено № шага 1 Система Воздействие Uipath Создать заявку Результат на Заявка создана портале Route 2 Route Укомплектовать заказ В интерфейсе кладовщика отразилась заявка 3 Route Доставить заказ В интерфейсе отразилась заявка 129 логиста CUCM 4 Настроить ip- Ip-телефония настроена телефонию 5 OEBS, Перемещение Оборудование перемещено ИМ оборудования в ИС с МОЛ ИТ на пользователя учета Uipath 6 Закрыть заявку Статус заявки изменен на «Архив» Тест-кейс 2. Внеплановая потребность. Оборудование не установлено Номер Ошибка! Источник ссылки не найден. 2 Название Внеплановая потребность. Оборудование не установлено ВИ Внеплановая потребность. Невозможно установить оборудование, в виду отсутствия необходимых требований для эксплуатации. Задействованные Route, Uipath, Remedy системы Подготовка Появилась заявка в Remedy Результат Заявка передана диспетчеру № шага Система Воздействие 130 Результат 1 Uipath Создать заявку на Заявка создана портале Route 2 Route Укомплектовать заказ В интерфейсе кладовщика отразилась заявка 3 Route Доставить заказ В интерфейсе логиста отразилась заявка 4 Route Установить Оборудование не было оборудование установлено, в виду отсутствия необходимых требований для эксплуатации 5 Route Передать заявку Заявка передана диспетчеру диспетчеру со статусом «Не установлено» 6 Route Диспетчер решает Диспетчер связывается с вопрос с заявкой пользователем и на основе этого может: • Передать в доставку – статус заявки в интерфейсе меняется на «Доставка», переход к кейсу «Внеплановая потребность» №1, шаг 3 • Отменить заявку – статус заявки в интерфейсе меняется на «Отменен» 131 • Отправить оборудование на доукомплектацию – статус заявки меняется на «Комплектация», переход к кейсу «Внеплановая потребность», шаг 2 132
