Архитектура информационной системы автоматизации бизнес-процессов сервисного обслуживания оборудования

Архитектура информационной системы автоматизации бизнес-процессов сервисного обслуживания оборудования

Оглавление

Введение

Глава 1. Требования к проектируемой системе

Глава 2. Анализ существующих методик и инструментальных средств для управления сервисным обслуживанием

.1 Существующие решения

.2 Лучшие практики управления IT

.3 Выбор языка моделирования информационной системы

Глава 3. Разработка проекта информационной системы

.1 Диаграмма развёртывания

.2 Функциональные модули системы

.3 Ролевая модель системы

.4 Модуль управления объектами

.5 Модуль настройки системы

.6 Модуль НСИ

.7 Модуль управления уровнем услуг

.8 Модуль управления инцидентами

.9 Модуль управления запросами на обслуживание

.10 Модуль управления планированием работ

.11 Модуль управления полевыми инженерами

Заключение

Список литературы

Приложения

Введение

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

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

Другим же вариантом является привлечение различных сервисных компаний c целью аутсорсинга данных задач. В большинстве случаев данная модель подразумевает оплату заключения и пролонгации контракта с обслуживающей компанией, а также оплату каждого отдельно взятого возникающего у клиента инцидента или запроса на обслуживание. Данный вариант взаимодействия двух компаний является наиболее взаимовыгодным по нескольким причинам. Прежде всего, клиентская компания получает подтверждение существования перед ней обязательств у обслуживающей компании по поддержке принадлежащего ей оборудования, снимая тем самым с себя данную задачу, что позволяет её сотрудникам сфокусироваться на основном потоке создания ценности компании. Выгода же обслуживающей компании в данном случае будет заключаться в уплате ей стоимости заключения и пролонгации данных договоров, что позволит ей поддерживать ненулевую выручку даже при отсутствии поступающих от клиента обращений. Более того, при условии агрегации данных по текущей деятельности обслуживающей компании и их анализа, может быть достигнута её максимальная эффективность, которая будет заключаться в поддержании определённого уровня утилизации сотрудников с помощью выработки оптимального числа текущих действующих соглашений. Разрешение инцидентов по данной модели так же является взаимовыгодным: клиентская компания оплачивает работы по факту их выполнения, не возлагая на себя издержки по содержанию недоутилизированных ресурсов, в то время как обслуживающая компания получает с выполнения данных работ прибыль, изначально заложенную в их стоимость.

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

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

Рассмотрим пример: при наличии высокого для небольших и средних компаний ежемесячного количества инцидентов (30), со средней по рынку ценой заключения договора о предоставлении услуг по обслуживанию офисной техники (20 тысяч рублей) и разового выезда по запросу (1500 рублей), обслуживание оборудования сервисной компанией будет более выгодно, чем содержание технического специалиста, способного оказывать тот же перечень услуг (80 тысяч рублей) при нулевой себестоимости технического обслуживания и ремонта оборудования.

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

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

На текущий момент отсутствует единый современный стандарт того, как наиболее корректно и эффективно должны работать процессы сервисного обслуживания оборудования, как то ITIL для поддержки ИТ-инфраструктуры компаний, IT4IT для общих ИТ-процессов, ISO 19770 для управления ИТ-активами или ISO 55000-55002:2014 для управления общими активами компании. Данный факт усложняет создание «коробочных» решений, которые могли бы быть использованы сервисными компаниями для автоматизации как внутренних, так и внешних бизнес-процессов. Как следствие, с целью автоматизации и оптимизации процессов они обязаны использовать связки из нескольких программных продуктов, что негативно сказывается на уровне повышения эффективности их производства; или же заказывать разработку единой информационной системы, которая была бы заточена под их процессы, однако данный вариант требует высоких ресурсных затрат, не гарантируя при этом того, что полученное решение будет полностью удовлетворять требованиям заказчика.

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

Глава 1. Требования к проектируемой системе

Требования к проектируемой системе собирались на основании анализа потребностей компании, производящей техническое обслуживание и ремонт газового оборудования (газосигнализаторы, средства катодной защиты и другие) на территории Московской области. На текущий момент компания обслуживает более 15 тысяч конфигурационных единиц, разбросанных более, чем на 1000 различных местоположениях.

Всего компания занимается выполнением нескольких видов работ:

·        Техническое обслуживание и поверка оборудования, согласно требованиям Ростехнадзора;

·        Разрешение инцидентов, возникающих на обслуживаемых объектах;

·        Обработка запросов на обслуживание клиентов компании (установка нового оборудования, вывод оборудования из эксплуатации, внеочередные технические осмотры и другие работы).

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

Модуль планирования и контроля проведения технического осмотра и поверки оборудования

Одним из ключевых функциональных модулей проектируемой информационной системы должен являться модуль планирования и контроля проведения технического обслуживания и поверки компанией оборудования, находящейся на её балансе. На текущий момент ежегодное планирование проведения надлежащих работ происходит в середине каждого года и представляет из себя совместную работу нескольких специалистов каждого из филиалов компании, которые на протяжении нескольких недель заносят в таблицу план-график с точностью до дня выезды специалистов на обслуживаемые объекты. Данный бизнес процесс несет в себе несколько рисков:

·        Недоутилизация и сверхутилизация трудовых ресурсов. Поскольку специалист, который производит планирование проведения данных работ, может по тем или иным причинам не учитывать план-график отпусков сотрудников компании и выходные дни, а также неравномерно распределять проведение выездов на объекты мобильных инженеров, в определённые моменты времени могут возникать ситуации, в которых будут нарушаться нормы утилизации сотрудников компании.

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

o   Тип технического обслуживания (ТО)

§  ТО 1 - проведение технического обслуживания всего оборудования на объекте, помимо газосигнализаторов

§  ТО 2 - поверка газосигнализаторов на объекте

§  ТО 3 - проведение технического обслуживания газосигнализаторов

o   Дата и проведения предыдущего ТО

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

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

Модуль хранения информации о конфигурационных единицах

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

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

·        Обмен между филиалами. Поскольку у каждого филиала содержится свой склад с техникой и ЗИП, необходимыми для проведения технического обслуживания и поверки оборудования, информационная система с единым справочником категорий и моделей оборудования позволила бы филиалам делать запросы на предоставление им каких-либо активов, что позволило бы избежать нарушения сроков проведения работ в связи с отсутствием необходимых запасов.

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

Модуль контроля выполнения задач полевыми инженерами

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

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

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

Модуль управления договорами

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

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

Модуль управления уровнем услуг

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

·        Длительность маршрутизации запроса;

·        Длительность принятия запроса в работу;

·        Длительность выполнения работ по запросу;

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

Модуль управления инцидентами

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

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

·        Повышение скорости реакции исполнителей. Автоматизация маршрутизации инцидентов повысила бы скорость реакции инженеров на поступающие обращения, что уменьшило бы длительность выполнения работ по инцидентам.

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

Модуль управления запросами на обслуживание

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

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

Модуль хранения нормативно-справочной информации (НСИ)

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

·        Список сотрудников компании

·        Организационная структура компании

·        Список рабочих групп

·        Список предоставляемых ИТ-услуг

·        Список типовых неисправностей

·        Список типовых причины неисправностей

·        Список местоположений

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

Глава 2. Анализ существующих методик и инструментальных средств для управления сервисным обслуживанием

.1 Существующие решения

управление сервисный обслуживание информационный

На текущий момент на рынке информационных систем существует множество различных решений, которые направлены на автоматизацию процессов технического обслуживания и ремонта оборудования. Тем не менее, все данные системы не могут в полной мере закрыть своим функционалом требования рассматриваемой компании. Краткий обзор их функционала приведён ниже, в то время как подробный разбор списка возможных автоматизируемых процессов приведён в приложении (Таблица 1, Обзор функциональных возможностей систем CMMS, EAM, Help Desk, FSM).

Компьютеризированная система управления обслуживанием (Computerized Maintenance Management System, CMMS), также известная как компьютеризированная информационная система управления обслуживанием (Computerized Maintenance Management Information System, CMMIS), представляет собой программное обеспечение, которое поддерживает базу данных об обслуживающих операциях организации [8]. Эта информация предназначена для того, чтобы помочь работникам, занимающихся техническим обслуживанием, более эффективно выполнять свою работу (например, определять, какие машины требуют обслуживания или на каких складах содержатся необходимые им запасные части), а также помочь руководству принимать более обоснованные решения (например, сравнить стоимость ремонта машины со стоимостью её периодического технического обслуживания, что может привести к лучшему распределению ресурсов). Данные CMMS могут также использоваться для проверки выполнения работ соответствию нормативным требованиям.

Примерами систем данного класса являются ServiceChannel, Fixd, Corrigo Enterprise CMMS и другие.

К списку стандартных функций информационных систем класса CMMS относят:

·        Создание базы данных оборудования основных фондов

·        Хранение данных о необходимых запчастях и ремонтном персонале

·        Проработку заявок на закупку деталей

·        Календарное планирование технического обслуживания и ремонтов

·        Составление и хранение информации о расходах и происшествиях на предприятии

·        Составление стандартных и полных отчетов о ремонтах и обслуживании оборудования

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

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

Управление корпоративными активами (Enterprise Asset Management - EAM) - это класс программного обеспечения, который помогает компаниям управлять своими физическими активами. Данный класс решений является результатом развития решений класса CMMS, в связи с чем обладает большими функциональными возможностями. Помимо стандартных функций CMMS, решения EAM также помогают проводить расчёты, связанные со стоимостью владения и обслуживания физических активов, а также напоминают предприятиям, когда необходимо проводить обслуживание определённого оборудования [4]. Кроме того, они могут содержать функции, помогающие проводить списание или замену техники, а также отслеживать сроки гарантии на активы. Данные функции снижают затраты на трудовые ресурсы, производство и обслуживание, одновременно сокращая время простоя и повышая производительность оборудования.

Представителями данного класса решений являются HP Asset Manager, Infor EAM, UpKeep и другие.

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

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

Программное обеспечение класса Help Desk автоматизирует множество различных процессов и процедур, включённых в поддержку пользователей. Как правило, среди них обязательно присутствует управление обращениями, перечень средств автоматизации (например, параметризированная маршрутизация и эскалация обращений), а также сбор отчетности и оптимизация службы поддержки.

В системах класса Help Desk обязательно присутствует модуль, через который клиентам организации даётся доступ к функционалу отправки запросов, вокруг которых строится дальнейшая работа службы пользовательской поддержки. Также данные системы могут иметь модуль управления знаниями, который агрегирует в себе информацию по поступающим запросам и их решениям, что даёт возможность пользователям самостоятельно разрешать возникающие у них вопросы, а исполнителям - делиться друг с другом экспертизой без непосредственного взаимодействия. К тому же, за счёт того, что решения класса Help Desk в работе опираются на такие объекты, как обращение, компания, пользователь и рабочая группа, являющихся базовыми для множества бизнес процессов компаний, именно они являются основой для развития на их базисе решений, не имеющих аналогов среди «коробочных» продуктов.

К данным решениям относятся такие программные продукты, как Atlassian JIRA, BMC Remedy, HP Service Manager и другие.

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

Программное обеспечение для управления полевыми работами (Field Service Management - FSM) направлено на управление ресурсами компании, движущимися к заказчику или уже располагающимися на его территории. В качестве примера функциональных возможностей систем данного класса можно привести определение местонахождения транспортных средств, управление работой мобильных инженеров, планирование и диспетчеризация работ, обеспечение безопасности водителя и другие. Решения класса FSM чаще всего используются компаниями, которым необходимо управлять установкой, обслуживанием или ремонтом систем или оборудования.

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

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

Наиболее популярными представителями систем данного класса являются решения от компаний ClickSoftware и ServiceMax.

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

.2 Лучшие практики управления IT

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

Прежде всего, необходимо узнать о лучших практиках управления техническими активами и ИТ-услугами компаний с тем, чтобы определить структуру большинства процессов, которые целевая система должна автоматизировать. С этой целью были рассмотрены такие библиотеки лучших практик, как ITIL, COBIT, а также IT4IT. Их изучение позволит выбрать наиболее подходящие уже существующие на данный момент методы организации бизнес-процессов, что, во-первых, повысит скорость проектирования и создания информационной системы, а также позволит компаниям быстрее внедрять её в текущие бизнес-процессы.

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

Для того, чтобы начинать сбор требований к информационной системе не с нуля, была изучена библиотека ITIL, Information Technologies Infrastructure Library, которая описывает лучшие практики организации работы ИТ-подразделений компаний, занимающихся предоставлением услуг в области информационных технологий. ITIL описывает процессы, процедуры, задачи и контрольные точки, которые могут быть применены при организации процессов любых компаний с целью установления взаимосвязи между ИТ-процессами и стратегией компании, а также производимой компанией ценностью [5].

Наиболее популярными процессами, обеспечивающими поддержку и предоставление ИТ-услуг, которые описывает ITIL, являются:

·        Процесс управления изменениями;

·        Процесс управления релизами;

·        Процесс управления инцидентами;

·        Процесс управления проблемами;

·        Процесс управления мощностями (ёмкостью);

·        Процесс управления запросами на обслуживание;

·        Процесс управления доступностью;

·        Процесс управления активами и конфигурациями;

·        Процесс управления финансами;

·        Процесс управления уровнем услуг;

·        Процесс управления непрерывностью;

·        Процесс управления знаниями.

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

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

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

Процесс управления запросами на обслуживание (или управление запросами) фокусируется на выполнении запросов на обслуживание. Термин «запрос на обслуживание» используется как общее описание для множества различных типов запросов от пользователей, которые поступают в ИТ-подразделения компании. Многие из этих запросов на обслуживание представляют собой небольшие предварительно одобренные, повторяемые, предопределенные изменения с низким уровнем риска. Если изменение не отвечает этим критериям, это не запрос на обслуживание и его следует определить как запрос на изменение.

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

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

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

Управление уровнем услуг направлено на обеспечение постоянной идентификации, мониторинга и пересмотра уровней ИТ-услуг, указанных в соглашениях об уровнях обслуживания (SLA). Управление уровнем услуг контроль соблюдения договорённостей как с внутренними, так и внешними поставщиками ИТ-услуг в форме соглашений об оперативных уровнях обслуживания (OLA) и подкрепляющих контрактов (UC) соответственно. Процесс управления уровнем услуг тесно связан с операционными процессами с целью установки контроля над их деятельностью посредством установки метрик.

Управление уровнем услуг отвечает за:

·        Обеспечение того, чтобы ИТ-услуги предоставлялись в соответствии с установленными договорённостями, включающими непосредственно ИТ-услугу, а также место, время и срок её предоставления;

·        Поддержание связи с управлением доступностью, управлением пропускной способностью, управлением инцидентами и управлением проблемами, чтобы обеспечить необходимый уровень и качество предоставления услуг в рамках ресурсов, согласованных с финансовым управлением;

·        Обеспечение наличия соответствующих планов непрерывности ИТ-услуг для поддержки бизнеса и требований к его непрерывности.

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

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

Control Objectives for Information and Related Technologies (COBIT) - библиотека лучших практик управления информационными технологиями, созданная международной ассоциацией ASACA. Согласно официальной документации, COBIT является набором описаний средств контроля над информационными технологиями и объединяет их в единую структуру IT-процессов.

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

Фокус COBIT направлен на 34 процесса, которые могут быть разбиты на 4 взаимосвязанные группы:

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

·        Приобретение и разработка. Данные процессы нацелены на определение необходимых компании ИТ-решений, их приобретение или разработку, а также дальнейшее внедрение и интеграцию в существующие бизнес-процессы организации.

·        Предоставление и поддержка. Данный процессы описывают корректную организацию предоставления необходимых услуг.

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

Среди данных 34 процессов также содержатся процессы управления уровнями обслуживания, контролем качества, активами и конфигурациями, поставщиками, запросами на обслуживание и инцидентами.

Несмотря на то, что цели фреймворка COBIT совпадают с целями ITIL, принципиальное различие между данными библиотеками заключается в их подходе к описанию целевых процессов. В случае, если ITIL даёт список ключевых объектов, атрибутов, действий и последовательно описывает их целевое взаимодействие, давая инструкции к тому, как должны быть организованы те или иные процессы, COBIT содержит в себе исключительно список необходимых активностей (activities), которые должны осуществляться для поддержания стабильной работы ИТ-подразделений компаний, а также список метрик, по которым можно оценить их эффективность. Таким образом, COBIT даёт большую свободу компаниям, поскольку соблюдать установленные им требования к процессам является более простой задачей, нежели полная замена внутренних, возможно уже устоявшихся процессов на заранее предопределённые и описанные в ITIL.IT

Стандарт архитектуры Open Group IT4IT включает в себя эталонную архитектуру и операционную модель цепочки создания ценности для управления бизнесом в сфере ИТ. Она предоставляет указания к тому, как проектировать и реализовывать функции информационных систем, необходимые для оптимизации работы ИТ-служб компании [6].

Цепочка создания ценности в сфере ИТ - это ряд действий, выполняемых ИТ-службами для повышения ценности предоставляемой услуги. IT4IT описывает задачи в цепочке создания ценности с четырёх сторон, объединяя их в соответствующие модели:

·        Модель обслуживания

·        Информационная модель

·        Функциональная модель

·        Интеграционная модель

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

Каждый поток создания ценности ИТ фокусируется на одном из элементов Сервисной модели, а также совокупности ключевых объектов данных (Информационная модель) и функциональных компонентов (Функциональная модель), которые его поддерживают. Вместе четыре потока создания ценности играют жизненно важную роль в оказании ИТ-поддержки комплексного управления полным жизненным циклом службы:

·        Поток создания ценности Strategy to Portfolio (S2P) получает требования, основывающиеся на стратегии компании, на создание новых или улучшение существующих услуг с целью повышения эффективности её работы, а также разрабатывает Концептуальную Службу, описывающую запрашиваемую услугу. Концептуальная Служба - это мост между бизнесом и ИТ, так как она обеспечивает бизнес-контекст для проектируемой службы наряду с высокоуровневыми атрибутами будущей архитектуры.

·        Поток создания ценности Requirement to Deploy (R2D) на входе получает Концептуальную Службу, после чего проектирует и разрабатывает Логическую Службу с более подробными требованиями, описывающими, как должна быть спроектирована запрошенная служба и ее компоненты. Логическую Службу можно рассматривать как удобное для пользователя имя для «системы обслуживания», которая будет создана или улучшена. Логическая Служба и сопутствующие документы служат артефактами при создании Службы Выпуска (Service Release), которая далее описывается в Проекте Службы Выпуска (Service Release Blueprint), которые в конечном счете определяют, как служба будет функционировать после начала её работы.

·        Поток Request to Fulfill (R2F) на входе получает получает Проект Выпуска Службы и добавляет соответствующую запись (Service Catalog Entry) в каталог служб, где содержится информация о том, как с технический точки зрения будет предоставляться данная услуга. Владельцы услуг формируют предложения на основании технических возможностей (записей в каталоге услуг). Предложения (Offer) доступны для просмотра потребителю и могут быть заказаны по установленной цене в соответствии с контрактом на обслуживание, как указано в Предложении. Как только был оформлен заказ, поток создания ценности R2F переводит службу в производство, где поток создания ценности D2C производит оперативные действия по предоставлению данной услуги.

·        Поток создания ценности Detect to Correct (D2C) создает основу для внедрения мониторинга, управления, восстановления и других эксплуатационных аспектов, связанных с реализованными и находящимися в разработке услугами. Выходные данные из потока ценности D2C входят в жизненный цикл в качестве новых требований в потоке ценности S2P.IT подходит к проблеме управления предоставлением услуг несколько иначе, нежели ITIL или COBIT. В то время, как ITIL или COBIT фокусируют своё внимание на интеграции ИТ-служб и текущих бизнес-процессов компании, IT4IT предлагает относиться к ИТ-службам как к отдельному направлению, функционирующему по законам рынка, создаваемому внутренними или внешними потребителями данной компании, что позволяет идентифицировать реальную ценность, приносимую данными ИТ-службами и сфокусироваться на ней. Описание данных процессов на разных уровнях (концептуальном, функциональном, логическом и физическом) позволяет использовать данный фреймворк большему ряду сотрудников, чем в случае с его аналогами, поскольку концептуальный и функциональные уровни направлены на использование менеджерами компаний, в то время как логический и физический уровни могут использоваться техническими специалистами при разработке системы.

В IT4IT отсутствует ряд процессов, описанных в ITIL или COBIT, тем не менее, все необходимые процессы, описанные в данных лучших практиках, обозначенные ранее в данном исследовании, присутствуют. Так же, как и COBIT, IT4IT описывает процессы более структурно, нежели ITIL, что одновременно помогает проектировать низкоуровневую архитектуру приложения, однако усложняет наложение модели описываемых процессов на текущую структуру организации. (если нужно, сюда можно вставить картинку)

Обоснование выбора фреймворка

Для разработки архитектуры проектируемой информационной системы был выбран фреймворк ITIL. Данное решение основывается на нескольких причинах. Прежде всего, данный фреймворк на текущий момент является наиболее популярным среди его аналогов, что подтверждается оценкой ресурса Google Trends, предоставляющем информацию о количестве поисковых запросов по соответствующей и смежным тематикам, а также опросом, произведённом среди сотрудников компаний, занимающихся ИТ-консалтингом на территории России. Данный факт позволяет судить о том, что процесс внедрения проектируемой информационной системы может быть сильно облегчён: большинство компаний продолжает использовать адаптированные под свои требования процессы именно данного набора лучших практик, а значит, внедрение информационной системы, автоматизирующей процессы ITIL, повлечет за собой меньшие издержки.

Рисунок 1, Частота поисковых запросов по ITIL, COBIT, IT4IT согласно Google Trends

Помимо этого, из рассматриваемого перечня библиотек лучших практик ITIL является единственной описывающей заложенные в ней процессы путём не задания их структуры, а при помощи описания самой деятельности и задач задействованных в них лиц, что помогает проще оценить необходимость реализации той или иной активности в рамках проектируемой информационной системы [9].

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

2.3 Выбор языка моделирования информационной системы

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

·        Unified Modeling Language

·        IDEF

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

В связи с данными требованиями не рассматривались такие популярные нотации, как Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) и другие, поскольку, несмотря на понятные и удобные механизмы проектирования бизнес-процессов, они не позволяют описать техническую составляющую проектируемой информационной системы.

Unified Modeling Language (UML) - универсальный язык моделирования в области разработки программного обеспечения, призванный стандартизировать различные способы визуализации архитектуры информационных систем.предлагает способы визуализации архитектуры информационной системы, включая такие элементы, как:

·        Деятельности (задачи);

·        Программные компоненты системы и их взаимодействие;

·        Описание бизнес-логики, заложенной в информационную систему;

·        Объекты, которыми оперирует информационная система, и их взаимодействие;

·        Внешний пользовательский интерфейс.

Хотя первоначально UML был предназначен для описания объектно-ориентированной архитектуры информационных систем, позднее он был расширен и на данный момент позволяет описывать большее количество аспектов функционирования программных решений.

Важно различать UML-модель и набор диаграмм системы. Диаграмма - частичное графическое представление модели системы. Набор диаграмм не обязательно должен полностью покрывать модель, и удаление диаграммы её не изменяет. Модель также может содержать описания, определяющие элементы и диаграммы модели.диаграммы описывают систему с двух различных представлений:

·        Статическое (структурное) представление описывает статическую структуру информационной системы, используя объекты, атрибуты, операции и отношения. Данное представление описывается следующими диаграммами:

o   Диаграмма классов;

o   Диаграмма компонентов;

o   Диаграмма составной структуры;

o   Диаграмма кооперации;

o   Диаграмма развёртывания;

o   Диаграмма объектов;

o   Диаграмма пакетов;

o   Диаграмма профилей;

·        Динамическое (поведенческое) представление описывает различные варианты поведения системы, отражая взаимодействие между объектами и изменения их внутренних состояний. Динамическое представление описывается следующими диаграммами:

o   Диаграмма деятельности;

o   Диаграмма состояний;

o   Диаграмма вариантов использования;

o   Диаграммы взаимодействия:

§  Диаграмма коммуникации;

§  Диаграмма обзора взаимодействия;

§  Диаграмма последовательности;

§  Диаграмма синхронизации.

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

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

IDEF (Integration DEFinition) является семейством языков моделирования в области систем и программного обеспечения. Данные языки обладают широким спектром возможностей, от функционального моделирования до разработки архитектуры хранения данных и объектно-ориентированного проектирования. В данное семейство входит 14 различных стандартов моделирования, которые включают в себя:

·        IDEF0: Function modeling;

·        IDEF1: Information modeling;

·        IDEF1X: Data modeling;

·        IDEF2: Simulation model design;

·        IDEF3: Process description capture;

·        IDEF4: Object-oriented design;

·        IDEF5: Ontology description capture;

·        IDEF6: Design rationale capture;

·        IDEF7: Information system auditing;

·        IDEF8: User interface modeling;

·        IDEF9: Business constraint discovery;

·        IDEF10: Implementation architecture modeling;

·        IDEF11: Information artifact modeling;

·        IDEF12: Organization modeling;

·        IDEF13: Three schema mapping design;

·        IDEF14: Network design.

Тем не менее была завершена разработка только 4 из данных стандартов [10], а именно IDEF0, IDEF1X, IDEF2, IDEF3 и IDEF4. Разработка остальных стандартов не была завершена или же вовсе ограничилась только фиксацией первоначального определения их задач.

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

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

Язык моделирования IDEF2 изначально был предназначен для проектирования макетов пользовательских интерфейсов, однако в процессе его разработки фокус сместился в сторону представления изменяющегося во времени состояния ресурсов в информационной системе. Проблемой данного языка моделирования явилась необходимость различать описание того, что должна функционировать система, что в последствии легло в основу IDEF3; и имитационную модель, которая бы предсказывала, как система будет функционировать при тех или иных значениях параметров, что в результате позволяет описывать IDEF2.

Причиной развитию языка моделирования IDEF4 стало признание того, что модульность и повторное использование кода, являющиеся результатом парадигмы объектно-ориентированного программирования, могут быть использованы в процессе разработки программного обеспечения. Основной его задачей является предоставление инструментов для проектирования взаимодействия между различными объектами, функционирующими в рамках единой информационной системы.

Обоснование выбора нотации

В результате проведенного анализа для документирования разрабатываемой архитектуры информационной системы была выбрана нотация UML. Основной причиной данному решению явилась наибольшая популярность данного языка моделирования по отношению к семейству языков IDEF [11]. Помимо этого, UML предоставляет большее количество различных средств описания структуры сложных программных решений, необходимых в данном проекте, а именно:

·        Позволяет описывать заложенные в информационной системе процессы с точки зрения жизненного цикла объектов (диаграмма последовательности);

·        Содержит инструменты для описания взаимодействия пользователей и системы (диаграмма вариантов использования);

·        Позволяет описывать инфраструктуру, на которой будет развернуто программное обеспечение (диаграмма развертывания).

Глава 3. Разработка проекта информационной системы

.1 Диаграмма развёртывания

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

Стоит отметить, что архитектура описываемого решения рассчитана на модель распространения «on-premise», которая подразумевает развёртывание информационной системы в ландшафте ИТ-инфраструктуры организации, собирающейся её использовать, то есть не рассчитана на предоставление к ней доступа по требованию независимых друг от друга компаний, как это принято в модели SaaS (Software as a Service).

Рисунок 2, Диаграмма развёртывания проектируемой информационной системы

Автоматизированное рабочее место. Данный элемент представляет собой обобщение различных технических средств, посредством которых пользователи системы могут осуществлять доступ к проектируемой системе. Примерами таких автоматизированных рабочих мест могут являться персональные компьютеры и мобильные устройства,

Domain Name System (DNS) Server. Данный элемент является общепринятым при рассмотрении общей архитектуры приложения, поскольку служит для обеспечения доступа пользователей к различным ресурсам. Тем не менее, в данной работе его настройка рассматриваться не будет, поскольку данный элемент не является обязательным при развёртывании проектируемой системы, так как взаимодействие с ней может осуществляться с использованием HTTP-запросов по прямым IP-адресам. Более того, настройка данного ресурса будет сильно зависеть от специфики работы компаний, а также установленных в их рамках политик безопасности и средств управления ИТ-инфраструктурой.

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

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

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

Кластер серверов баз данных «ключ-значение». Данный элемент обобщает один или несколько серверов баз данных класса «ключ-значение», которые могут быть использованы для хранения оперативной информации, необходимой для функционирования системы. Стоит отметить, что данный элемент также не является обязательным: данные, которые содержат базы данных «ключ-значения» так же могут быть размещены в соответствующих таблицах используемой реляционной базы данных, содержаться в пользовательской сессии, пересылаться в cookie или храниться в файловой системе - в зависимости от предназначения. К таким данным могут относиться ключи доступа, оперативные сведенья о работе пользователей (например, открытые в данный момент страницы) и другие. Преимуществом баз данных «ключ-значение» по отношению к реляционным базам данных является скорость, с которой они обрабатывают запросы и возвращают данные, что достигается при помощи хранения информации в оперативной памяти, а также возможность автоматического удаления данных по истечению какого-либо времени путём использования встроенных средств СУБД.

Кластер серверов очередей и кластер worker-серверов. Менеджеры очередей позволяют не только управлять нагрузкой на сервера приложений, распределяя её между worker-серверами, делая возможным использование дополнительных вычислительных ресурсов в рамках обработки пользовательских запросов, но также позволяют решать задачу асинхронных вычислений, когда информация, необходимая пользователю уже готова для возвращения, однако процессы, необходимые для функционирования системы ещё не были завершены, в следствие чего пользователь обязан ждать дольше, чем требует его задача. Некоторые технологии разработки, как, например, .NET имеют встроенные средства для решения данной задачи, однако такие языки разработки, как PHP или Python их не содержат, что приводит к необходимости использования сторонних решений.

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

Кластер серверов PUSH-уведомлений. Кластер данных серверов обеспечивает возможность информационной системы уведомлять пользователя о важных для него событиях по мере их реального возникновения. Отличительной особенностью данной технологии является то, что для получения данной информации от пользователя не требуется осуществления рекуррентных запросов на сервер, что не только снижает нагрузку на вычислительные мощности автоматизированного рабочего места пользователя и инфраструктуру, на которой расположена информационная система, но также позволяет уведомлять пользователя о данных событиях с меньшей задержкой, что может быть крайне важным в таких процессах, как управление инцидентами и запросами на обслуживание, когда время получения специалистом необходимой информации является значительным фактором, влияющим на скорость обработки обращений и общий уровень оказываемых услуг. Данный элемент также является необязательным, поскольку при разработке информационной системы могут быть использованы технологии Long Poll или Short Poll, или же функционал мгновенного уведомления пользователей может быть вовсе не реализован.

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

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

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

·        Операционная система: Linux

·        Язык разработки: PHP

·        Фреймворк разработки: Laravel

·        СУБД: PostgreSQL

·        Веб-сервер: Apache

·        Key-Value база данных: Redis

·        Сервер PUSH-уведомлений: Thruway

·        Менеджер очередей: Gearman

·        Система контроля процессов: Supervisor

·        Балансировщик нагрузки: Haproxy

.2 Функциональные модули системы

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

Рисунок 3, Структура функциональных модулей проектируемой информационной системы

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

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

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

В связи с возможностью достаточно чёткого разграничения между функциональными модулями системы, при проектировании системы будут использованы микросервисы. Микросервисы - это вариант сервис-ориентированной архитектуры (Service-Oriented Architecture - SOA), которая представляет приложение в виде набора слабо связанных между собой сервисов [13]. Преимуществом разбиения приложения на различные небольшие сервисы является то, что оно улучшает модульность и облегчает понимание, разработку и тестирование приложения. Оно также позволяет распараллеливать разработку, позволяя небольшим автономным командам самостоятельно проектировать, имплементировать, развертывать и масштабировать доверенные им сервисы.

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

.3 Ролевая модель системы

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

·        Исполнитель. Люди, принадлежащие к данной роли в системе, имеют доступ к функционалу по управлению инцидентами, запросами на обслуживание, а также имеют возможность использовать функционал для контроля работ полевых сотрудников;

·        Оператор. Данная роль предназначена для сотрудников, занимающихся, прежде всего, регистрацией и маршрутизацией пользовательских запросов, а также совершающих по отношению к ним обратную связь;

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

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

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

Назначение данных ролей, за исключением роли «Пользователь» происходит посредством добавления пользователя в рабочую группу с соответствующим признаком - «Тип группы».

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

.4 Модуль управления объектами

Модуль управления объектами позволяет осуществлять просмотр и редактирование данных об объектах, используемых информационной системой. Данный функционал позволяет вынести базовые действия по адаптации системы под предметную область использующей её организации на уровень настроек, что снижает количество ресурсов, отводимое на внедрение и доработку информационной системы. По сути же, данный модуль является набором инструментов для редактирования основных таблиц базы данных, на которые опирается информационная система, с целью упрощения её настройки.

Основными пользователями данного модуля являются администраторы системы, производящие её первоначальную настройку на этапе внедрения.

Структура данных

Рисунок 4, Структура данных модуля управления объектами системы

Несмотря на то, что данная схема является диаграммой классов, а не моделью базы данных, она позволяет продемонстрировать набор необходимых атрибутов каждого из объектов, которые обязаны быть отражены в СУБД для возможности применения технологии ORM. В связи с этим, приведение дополнительно структуры таблиц базы данных будет избыточным, поскольку будет полностью повторять структуру классов данного функционального модуля.

Описание классов

Стоит отметить, что данные классы не содержат в себе интерфейсов для взаимодействия с другими программными модулями, поскольку это нарушало бы принцип работы архитектуры микросервисов. Данные интерфейсы должны быть представлены в виде отдельного сервиса (репозитория), к которому в последствии будут обраться другие программные модули для взаимодействия. Список публичных функций данного сервиса и, в случае необходимости, описания их работы будут приведены после описания объектов, которые в нём используются. Основное же назначение данных объектов - произведение CRUD (Create, Read, Update, Delete) операций.

Object. Объекты данного класса содержат в себе определение отдельно взятого объекта, используемого системой (например, Рабочая группа, Пользователь, Компания и другие). Они могут быть использованы для получения информации об объекте, а также содержать в себе агрегационные функции, не относящиеся каким-либо отдельно взятым элементам объекта, а к их совокупности. Такими функциями могут быть получение списка полей для отображения на форме, удаление объекта, создание с ним связи и другие. В нём содержатся такие атрибуты, как:

·        ID. Идентификационный номер объекта;

·        Name. Системное имя объекта, используется при формировании имени таблицы, хранящей данные об экземплярах данного класса (например, Group);

·        DisplayName. Отображаемое имя объекта (например, Рабочая группа);

·        hasAudit. Ведётся ли аудит внесения изменений в данный объект;

·        hasObjectLog. Требуется ли отображать на форме данного объекта журнал работ;

·        System. Является ли объект системным, то есть необходимым для корректного функционирования системы, или был создан пользователями. В случае, если объект не является системным, администратору системы даётся доступ к редактированию всех атрибутов данного объекта;

·        Deletable. Допускается ли удаление данного объекта;

·        DisplayNameAttribute. Ссылка на атрибут объекта, который содержит отображаемое имя (например, ID атрибута Name в объекте пользователя).

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

·        ID. Идентификационный номер атрибута;

·        Name. Системное название атрибута. Обязано совпадать с именем столбца в таблице соответствующего объекта (например, Name);

·        DisplayName. Отображаемое имя атрибута (например, Имя);

·        isPicklist. Является ли данный атрибут фиксированным списком;

·        ObjectID. Ссылка на объект, содержащий данный атрибут;

·        LinkedObjectID. Ссылка на объект, на который ссылается данный объект;

·        DisplayOnForm. Отображается ли данный атрибут на форме;

·        Editable. Редактируется ли данный атрибут;

·        AttributeTypeID. Ссылка на объект AttributeType, содержащий информацию о типе отображения атрибута;

·        System. Данный атрибут объекта отвечает за то, возможно ли изменение параметров данного экземпляра атрибута пользователями системы. Он служит для того, чтобы такие атрибуты, как ID, дата создания и изменения не удалялись и не изменялись пользователями системы.

AttributeType. Данная таблица содержит список всех возможным вариантов отображения атрибутов на форме. Добавление в неё данных происходит только при внесении правок в программный код информационной системы, поскольку все данные отображения обязательно имеют собственную логику агрегации данных, а также вёрстку их отображения.

·        ID. Идентификационный номер типа отображения;

·        Name. Системное имя типа отображения. Может быть использовано в процессе разработки программного кода;

·        DisplayName. Отображаемое имя типа отображения. Используется при выводе возможных вариантов отображения при редактировании объектов.

AttributePicklistValue. Объекты данного класса содержат информацию о возможных для выбора элементах фиксированных списков.

·        ID. Идентификационный номер записи;

·        AttributeID. Ссылка на атрибут, являющийся фиксированным списком, который содержит данный вариант выбора;

·        Value. Значение данного элемента выбора, которое будет записываться в столбец данного атрибута в таблице, содержащей соответствующий объект.

·        DisplayName. Отображаемое имя данного варианта выбора.

ObjectMap. Экземпляры данного класса содержат информацию о связях типа «Many-to-Many» между различными объектами. Вынесение их в таблицу базы данных позволяет при помощи настроек системы определять данные связи, что позволяет устанавливать взаимоотношения между объектами без прибегания к изменению программного кода.

·        ID. Идентификационный номер типа отображения;

·        SourceObjectID. ID объекта, являющегося источников данной связи;

·        TargetObjectID. ID объекта, являющегося целью данной связи;

·        SourceDisplayName. Название связи, отображающееся в исходном объекте;

·        TargetDisplayName. Название связи, отображающееся в целевом объекте.

Relationship. Объекты данного класса являются экземплярами соответствующих связей, указанных в ObjectMap.

·        ID. Идентификатор экземпляра связи;

·        ObjectMapID. Ссылка на тип связи, экземпляром которой является данная запись;

·        SourceInstanceID. ID объекта-источника данной связи;

·        TargetInstanceID. ID объекта-цели данной связи.

CustomAttribute. Данный класс содержит в себе базовую информацию об условных атрибутах объектов. Условные атрибуты - это поля объектов, которые отображаются при соответствии данного объекта ряду признаков, что позволяет создавать атрибуты объектов, которые являются актуальными только для части их экземпляров. Данный функционал может быть активно использован при настройке CMDB, а также при работе модуля управления инцидентами.

·        ID. Идентификатор определения условного атрибута.

·        ObjectID. Ссылка на объект, которому принадлежит данное определение условного атрибута.

·        DisplayName. Отображаемое имя условного атрибута.

·        isPicklist. Является ли условный атрибут фиксированным списков.

·        LinkedObjectID. Ссылка на объект, на который ссылается данный условий атрибут.

·        AttributeTypeID. Ссылка на тип отображения данного атрибута.

·        Filter. Данное поле содержит строку со вставками, содержащими идентификаторы CustomAttributeCondition, что позволяет сохранять взаимосвязь между условиями отображения. Примером такой строки может являться (({ID1} AND {ID}) OR {ID3}), где ID1, ID2, ID3 - идентификаторы CustomAttributeCondition.

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

·        ID. Идентификатор условия наличия условного атрибута;

·        ObjectAttributeID. Ссылка на атрибут объекта, значение которого будет исследоваться;

·        ComparisonOperator. Оператор сравнения значений. Может являться как простым математическим оператором, так и оператором работы с множествами, такими как «intersect», «IN» и другие;

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

o   Мои группы;

o   Объекты, связанные через определённую связь, указанную в ObjectMap с возможностью указания ID данной связи в вызове;

o   Мои роли.

CustomAttributeValue. Экземпляры данного класса содержат в себе информацию о значениях, принимаемыми условными атрибутами объектов в привязке к существующим объектам.

·        ID. Идентификатор значения условного атрибута;

·        CustomAttributeID. Ссылка на определение условного атрибута, с помощью которого можно определить класс дополняемого объекта;

·        InstanceID. Идентификатор экземпляра объекта, дополняемого данным значением.

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

Программный интерфейс взаимодействия с модулем

Модуль управления объектами должен содержать следующие функции:

·        Создание объекта. На основании передающихся в функцию данных, должны создаваться соответствующие записи в таблицах объектов, атрибутов, значений фиксированных списков, условных атрибутов, параметров условных атрибутов, а также таблице связи «многие ко многим». Помимо этого, в базе данных должна создаваться таблица, которая в последствие будет хранить значения полей создаваемых экземпляров данного объекта;

·        Редактирование объекта. На основании передающихся в данную функцию параметров, в текущие таблицы описания объектов должны вноситься соответствующие корректировки;

·        Удаление объекта. На основании переданных в данную функцию параметров, из базы данных должны удаляться все связанные с данным объектом записи, а также удаляться сами экземпляры данного объекта;

·        Получение данных об экземпляре объекта. На основании переданных в данную функцию параметров, она должна возвращать данные, необходимые для отображения формы данного объекта. В основном, данная функция будет использоваться при отображении объектов без разработанных специально под них форм;

·        Сохранение данных об экземпляре объектов. На основании переданных в данную функцию параметров, она должна обновлять связанные с данным объектом записи в базе данных;

·        Удаление экземпляра объекта. На основании переданных в данную функцию параметров, она должна удалять соответствующую запись, содержащую информацию об экземпляре данного объекта, а также удалять все записи в базе данных, связанные с данным объектом. Например, записи журнала работ, записи аудита, связи и другие;

·        Получение информации об объекте. На основании переданных в данную функцию параметров, она должна возвращать информацию о данном объекте, включая информацию о том, какие атрибуты в нём содержатся;

·        Добавление записей в журнал работ данного объекта и их удаление;

·        Прикрепление вложений к данному объекту и их удаление;

·        Получение вложений, прикреплённых к данному объекту;

·        Получение журнала работ по данному объекту.

Список форм к разработке

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

·        Форма создания и редактирования объектов. Она должна позволять в автоматическом или полуавтоматическом режиме создавать все перечисленные выше объекты и заполнять их данными.

·        Форма универсального объекта. Данная форма должна состоять из отдельных атрибутов, вёрстка которых формируется на основании параметров их отображения, содержащихся в таблице атрибутов (Приложение, Рисунок 10).

Взаимодействие с другими модулями

·        Модуль НСИ:

o   Получение роли пользователя;

.5 Модуль настройки системы

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

Структура данных

Рисунок 5, Структура данных модуля настройки системы

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

·        ID. Идентификационный номер пункта меню;

·        Address. URN перехода данного пункта меню;

·        DisplayName. Отображаемое имя данного пункта меню;

·        Disabled. Данный параметр показывает, включён ли данный пункт меню и влияет на его отображение в графическом интерфейсе информационной системы;

·        Filter. По аналогии с механизмом фильтрации, применяемом в условных атрибутах, данное поле содержит строку, содержащую структуру условия фильтра и ссылки на его составные части - экземпляры MenuFilter;

·        Icon. Данное поле содержит в себе строку, являющуюся набором CSS-классов (Font Awesome, Glyphicons или другие), которая может быть вставлена в соответствующий HTML-тег для отображения в нём иконки данного пункта меню;

·        ParentID. Данное поле ссылается на родительский объект того же типа, что позволяет обеспечивать бесконечную вложенность уровней дерева меню.

MenuFilter. Данные объекты являются отдельно взятыми условиями, совокупность которых позволяет определить, является ли данный пункт меню доступным пользователю.

·        ID. Идентификатор условия видимости пункта меню;

·        ComparisonUserValue. Данное поле содержит вызов некой функции из заранее предопределённого перечня, который возвращает какую-либо информацию о текущем пользователе. Примеры данных функций приведены ниже, однако стоит учитывать, что данный список может пополняться в процессе разработки информационной системы в соответствии с требованиями компании:

o   Мои группы;

o   Объекты, связанные через определённую связь, указанную в ObjectMap с возможностью указания ID данной связи в вызове;

o   Мои роли;

·        ComparisonOperator. Данное поле содержит оператор сравнения ComparisonUserValue и ComparisonValue.

·        ComparisonValue. Данное поле содержит определённое пользователем значение, которое будет сравниваться с ComparisonUserValue. Примером такого значения может быть список ID каких-либо групп, пользователей или просто литералы.

View. Данный объект отвечает за отображение представлений, которые являются основным компонентом, через который осуществляется доступ к различным объектам информационной системы. Основными возможностями, которыми должен обладать данный компонент, являются: фильтрация вывода объектов в списке, настройка выводимых полей в данном списке, а также управление видимостью данных списков для разных пользователей.

·        ID. Идентификатор преставления;

·        MenuID. Идентификатор меню, в котором выводится данное представление;

·        ObjectID. Идентификатор объекта, экземпляры которого отображаются в данном представлении;

·        DisplayName. Выводимое название данного представления, при помощи которого можно будет ориентироваться в списках представлений. Например, при их переключении;

·        Filter. По аналогии с ранее описанными полями, содержащими условия фильтрации объектов, в данном поле также содержится строка, содержащая ссылки на объекты ItemFilter;

·        ViewPermissionsFilter. По аналогии с ранее описанными полями, содержащими условия фильтрации объектов, в данном поле также содержится строка, содержащая ссылки на объекты ViewFilter;

·        FormName. Имя формы, при помощи которой происходит отображение объектов данного представления. При помощи данного параметра можно регулировать, запрос на какой адрес будет поступать при попытке открытия данного объекта, что позволит открывать экземпляры одного и того же объекта в различных формах.

ViewItem. Данный объект содержит информацию о том, какие именно значения должны выводится в столбцах представления, отображаемого в графическом интерфейсе информационной системы. Тип и вид отображения должны определяться исходя из типа отображения элемента, являющимся конечным в данном пути. Так, в случае, есть AttributePath указывает на фиксированный список, в представлении должен выводиться выбранный в нём элемент; связанный объект - его отображаемое имя (например, атрибут Name из объекта пользователя); дата должна приводиться к часовому поясу текущего пользователя. Полный список преобразований должен быть сформирован при получении полных требований к информационной системе;

·        ID. Идентификатор поля представления;

·        AttributePath. Путь к значению, отображаемому в данном столбце представления. Поскольку часто требуется в представлении выводить не только поля данного объекта, но и связанных с ним, появляется задача, заключающая в том, чтобы путём настроек задавать то, по какому пути можно до них добраться. С этой целью необходимо разработка внутреннего языка информационной системы, которая позволила бы производить данную настройку. Один из путей решения данной задачи будет описан далее при разборе функционала данного сервиса;

·        ViewID. Идентификатор представления, в котором содержится данный элемент;

·        FormatID. Идентификатор функции форматирования данного элемента;

·        Order. Порядковый номер данного элемента представления, который служит для упорядочивания элементов;

·        DisplayName. Название столбца, который будет выводиться в данном представнии.

Format. Данный объект содержит информацию о том, какая функция должна вызываться для преобразования хранимых в базе данных данных для выведения её представлении. Примерами таких преобразований могут являться приведение даты к периоду до текущего момента, обрезание строки или удаление из неё какого-либо содержимого и другие.

·        ID. Идентификатор преобразования;

·        DisplayName. Отображаемое имя преобразования, которое может быть использовано при настройке представлений;

·        Function. Имя функции, которая содержит логику преобразования данного элемента представления.

ItemFilter. Данный объект содержит логику фильтрации записей для выведения в представлении, что является одним из наиболее востребованных функциональных требований к информационным системам. Работа данного механизма фильтрации не отличается от описанных ранее, за исключением того, что поле ComparisonAttributePath в данном случае является путём, который опирается на запись в представлении, при помощи которого можно получить доступ к значению, содержащегося в связанном объекте, а ComparisonValue является заранее предопределённым значением, вводящимся пользователем или же также является вызовом функции из списка доступных.

ViewFilter. Данный объект содержит логику фильтрации доступных пользователю представлений, что может служить для ограничения доступа к представлениям, содержащим записи, которые должны быть недоступны пользователю. В данном случае поле ComparisonUserValue будет содержать вызов функции, возвращающей информацию о текущем пользователе, а ComparisonValue - предопределённым значением. Таким образом, можно будет реализовать фильтрацию, при которой представление «Все заявки» будет доступно только пользователям с ролью «Администратор».

Механизмы к реализации

Основным механизмом, необходимым к реализации при данной архитектуре данных будет являться механизм разборе путей, указанных в полях, вроде AttributePath. Задачей, которую должен решать данных механизм, является получение на основании данной строки, а также параметров, содержащих информацию о том, от какого объекта происходит «движение», значения, содержащегося в объекте, связанном с данным. Например, для получения имени компании заявителя и выведения его в представлении заявок, может использоваться следующая строка:.Company.Name

Данная строка может быть трактована, как «возьми из заявки заявителя, достань из него компанию и отобрази её имя». Таким образом данный механизм должен преобразовывать передаваемую его строку в последовательность присоединений различных таблиц и сбору из них значений.

Данный функционал позволит избежать необходимости создания различных представлений в базе данных, что позволит изменять параметры отображения различных объектов в информационной системе сотрудникам, не знакомым с языком запросов СУБД, с которой работает данная система, или же просто не имеющим к ней доступа.

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

Программный интерфейс взаимодействия с модулем

Модуль настройки системы должен содержать следующие функции:

·        Создание пункта меню. Данный интерфейс должен позволять создавать новые пункты меню для последующей привязки к ним различных представлений;

·        Редактирование пункта меню. Данный интерфейс должен позволять вносить в существующие представления какие-либо изменения;

·        Удаление пункта меню. Данный интерфейс должен позволять удалять существующие пункты меню. После удаления пункта меню, должны также удаляться и его дочерние элементы;

·        Создание представления. Данный интерфейс должен позволять создавать новые представления, создавая при этом все необходимые для его корректного функционирования объекты;

·        Редактирование представления. Данный интерфейс должен позволять вносить изменения в существующие представления;

·        Удаление представления. Данный интерфейс должен позволять удалять существующие на данный момент представления.

Список форм к разработке

·        Форма редактирования меню;

·        Форма редактирования представления.

Взаимодействие с другими модулями

·        Модуль управления объектами:

o   Получение информации об объекте;

·        Модуль НСИ:

o   Получение роли пользователя;

.6 Модуль НСИ

Нормативно-Справочная информация (НСИ) - условно-постоянный компонент корпоративной информации, являющийся основой для унификации и нормализации данных, сопровождающих протекающие бизнес-процессы, а также регламентацию деятельности организации [14]. В связи с этим, основной функцией данного модуля будет являться хранение, а также актуализация информации, использующейся в информационной системе.

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

Структура данных

Рисунок 6, Структура данных модуля НСИ

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

User. Данный объект и соответствующая ему таблица содержит информацию о пользователях, заведённых в системе.

·        ID. Идентификационный номер пользователя;

·        Email. Email пользователя, по которому происходит авторизация в информационной системе;

·        PhoneNumber. Контактный телефон пользователя. В случае, если данная необходимость присутствует, объект «User» может быть дополнен такими атрибутами, как MobilePhone или WorkPhone;

·        Password. Пароль, по которому пользователь входит в систему. Данное моле может не заполняться в случае, если пользователь авторизуется посредством интеграции с Active Directory или другим методом, не требующим непосредственного введения пароля;

·        SubdivionID. Идентификационный номер структурного подразделения компании, в котором на данный момент работает сотрудник.

Location. Данный объект и соответствующая ему таблица в базе данных содержит информацию о местоположениях, которые используются при работе обслуживающей организации. Это могут быть местоположения компаний-клиентов или местоположения конфигурационных единиц.

·        ID. Идентификационный номер местоположения;

·        Address. Адрес местоположения для отображения пользователям системы;

·        Latitude. Широта, совпадающая с данным местоположением. Может использоваться для более точного указания местоположения, а также для отображения на карте без использования API сторонних сервисов;

·        Longitude. Долгота, совпадающая с данным местоположением. Может использоваться для более точного указания местоположения, а также для отображения на карте без использования API сторонних сервисов.

Subdivision. Данный объект и соответствующая ему таблица в базе данных содержит информацию о структурных подразделениях компаний, заведённых в информационной системе. Данная информация может быть полезна при получении информации о том, к какому структурному подразделению компании относится данный пользователь с целью ограничения доступного ему функционала системы. Например, на основании того, в каком подразделении работает данный сотрудник, можно ограничивать список доступных ему запросов на обслуживание.

·        ID. Идентификатор структурного подразделения;

·        Name. Название структурного подразделения;

·        ParentSubdivisionID. Идентификатор родительского структурного подразделения. Данный параметр служит для сохранения взаимосвязи между структурными подразделениями.

Company. Данный объект и соответствующая ему таблица в базе данных содержит информацию о компаниях, заведённых в информационной системе.

·        ID. Идентификационный номер компании;

·        Name. Название компании;

·        LocationID. Идентификатор местоположения, на котором располагается офис данной компания.

·        ContactUserID. Идентификатор пользователя, который является контактным лицом в данной компании;

·        HeadSubdivisionID. Идентификатор головного структурного подразделения.

Group. Данный объект и соответствующая ему таблица в базе данных содержит информацию о рабочих группах, заведённых в информационной системе.

·        ID. Идентификатор рабочей группы;

·        Name. Название рабочей группы;

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

·        Type. Тип группы. Как следует из описания ролевой модели, всего в системе присутствует 5 статических ролей, определяемых типов группы, в которую входит пользователь:

o   Пользователи;

o   Операторы;

o   Исполнители;

o   Администраторы.

·        CompanyID. Идентификатор компании, к которой относится данная рабочая группа.

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

·        ID. Идентификатор производителя;

·        Name. Название производителя.

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

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

·        ID. Идентификатор категории оборудования;

·        Name. Название категории оборудования;

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

Model. Данный объект и соответствующая ему таблица в базе данных содержит информацию о моделях оборудования, заведённых в информационной системе.

·        ID. Идентификатор модели оборудования;

·        VendorID. Идентификатор производителя оборудования данной модели;

·        ConfigurationItemCategoryID. Идентификатор категории оборудования, к которой относится данная модель.

ConfigurationItem. Данный объект и соответствующая ему таблица в базе данных содержит информацию о конфигурационных единицах, содержащихся на балансе компании.

·        ID. Идентификатор конфигурационной единицы;

·        InventoryNumber. Инвентарный номер единицы;

·        SerialNumber. Серийный номер единицы;

·        LocationID. Идентификатор местоположения, на котором находится данная конфигурационная единица;

·        ModelID. Идентификатор модели данной конфигурационной единицы;

·        OwningCompanyID. Идентификатор компании, владеющей данной конфигурационной единицей.

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

·        ID. Идентификатор графика работ;

·        Name. Отображаемое название графика работ для упрощения ориентации в списках.

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

·        ID. Идентификатор элемента рабочего графика;

·        WorkDayStart. Время начала рабочего дня;

·        WorkDayEnd. Время окончания рабочего дня;

·        DayOfWeek. Номер соответствующего дня недели;

·        BreakStart. Время начала перерыва;

·        BreakEnd. Время окончания перерыва.

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

·        ID. Идентификатор календаря;

·        Name. Название календаря, использующееся для упрощения ориентации в списках выбор календаря;

·        Year. Год, к которому относится данный календарь.

CalendarItem. Так же, как и график работ, объект календаря разбит на составные части, показывающие изменения в рабочих графиках.

·        ID. Идентификатор элемента календаря;

·        Date. Дата, которую описывает данный элемент календаря;

·        WorkDayEndChange. Изменения во времени окончания рабочего дня. Данное поле может приобретать как положительные, так и отрицательные целочисленные значения, выраженные в минутах.

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

·        ID. Идентификатор услуги;

·        Name. Название услуги.

Программный интерфейс взаимодействия с модулем

Модуль настройки системы должен содержать следующие функции:

·        Получение всех дочерних структурных подразделений данного;

·        Получение всех родительских структурных подразделений данного;

·        Получение сотрудников, входящих в данную группу;

·        Получение сотрудников, входящих в данное структурное подразделение;

·        Получение сотрудников, работающих в данной компании;

·        Получение групп, где данный сотрудник является менеджером;

·        Получение списка конфигурационных единиц данной компании;

·        Получение информации, где на данный момент расположено оборудование данной модели;

·        Получение информации, где на данный момент расположено оборудование данной категории;

·        Получение записи из какого-либо справочника;

·        Получение роли пользователя.

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

Список форм к разработке

·        Форма отображения текущей организационной структуры компании;

·        Форма отображения текущей структуры категорий конфигурационных единиц;

·        Форма с картой, на которой будет возможность отобразить текущие местоположения конфигурационных единиц с возможностью их фильтрации по моделям и категориям;

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

Взаимодействие с другими модулями

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

.7 Модуль управления уровнем услуг

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

Структура данных

Рисунок 7, Структура функционального модуля управления уровнем услуг

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

·        ID. Идентификатор контракта;

·        Name. Название контракта, которое может быть использовано при поиске;

·        ClientCompanyID. Идентификатор компании-клиента;

·        ContractorCompanyID. Идентификатор компании-подрядчика.

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

Specification. Объект спецификации содержи сведения об условиях и соответствующих уровнях обслуживания по данному контракту, содержа совокупность нескольких элементов спецификации.

·        ID. Идентификатор спецификации договора;

·        ContractID. Идентификатор договора, которому принадлежит данная спецификация;

·        Name. Название спецификации, служащее для осуществления поиска.

SpecificationItem. Элемент спецификации является ссылкой, указывающей или на условие, определяющее то, подходит ли данная спецификация для работы по ней, или указывающей на параметр обслуживания данной спецификации. Механизм маршрутизации обращений будет рассмотрен далее.

·        ID. Идентификатор элемента спецификации;

·        Type. Тип элемента спецификации. В зависимости от указанного в данном поле значения, элемент спецификации может указывать на:

o   Ограничивающие условия:

§  Модель оборудования;

§  Категорию оборудования;

§  Оказываемую услугу;

§  Местоположение;

§  Конкретную конфигурационную единицу.

o   Параметры обслуживания:

§  Рабочая группа;

§  Уровень обслуживания;

§  График обслуживания;

§  Календарь.

·        InstanceID. Идентификатор соответствующего объекта.

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

·        ID. Идентификатор соглашения об уровне обслуживания;

·        Name. Название соглашения об уровне обслуживания, использующийся для осуществления поиска.

SLAItem. Данный объект сопоставляет приоритет запроса на обслуживание или инцидента со временем, за которое необходимо осуществить принятие запроса в работу или его разрешить.

·        ID. Идентификатор элемента соглашения об уровне обслуживания;

·        SLAID. Идентификатор соглашения об уровне обслуживания;

·        Priority. Приоритет запроса на обслуживание или инцидента, к которому относится данный элемент;

·        ResolutionTime. Время, выраженное в минутах, за которое должно быть разрешено данное обращение;

·        ReactionTime. Время, выраженное в минутах, за которое поступившее обращение должно быть принято в работу.

Механизмы к реализации

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

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

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

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

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

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

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

Программный интерфейс взаимодействия с модулем

Модуль управления уровнями облуживания должен содержать следующие функции:

·        Получение списка подходящих спецификаций по заданным параметрам;

·        Вычисление крайних сроков на основании переданных значений;

·        Проверка запросов на необходимость проведения эскалаций в соответствии с их контрольными временами;

·        Сложение даты с периодом с учётом рабочего времени.

Список форм к разработке

·        Форма создания нового контракта. Данная форма должна позволять не только создавать объект контракта, но также и все его дочерние объекты, такие как спецификации и элементы спецификаций. При создании элементов спецификации должен быть реализован поиск по существующим объектам системы, а также должна присутствовать возможность создания новых объектов с целью управления всеми соглашениями из одной формы;

·        Форма редактирования и создания экземпляров календаря. С тем, чтобы у администраторов системы был доступ к редактированию данных объектов из пользовательского интерфейса, должна быть реализована форма, которая позволит создавать экземпляры объектов CalendarItem;

·        Форма редактирования и создания экземпляров графика работ. Несмотря на то, что редактирование графиков работ может осуществляться через автоматически сгенерированную форму объекта, с целью упрощения данного процесса необходимо создать функцию, которая будет позволять более наглядно редактировать данные объекты;

·        По возможности могут быть реализованы отдельные специализированные формы для создания объектов SLA.

Взаимодействие с другими модулями

·        Модуль НСИ:

o   Определение текущих прав пользователя;

o   Получение записей из справочников;

.8 Модуль управления инцидентами

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

Структура данных модуля

Рисунок 8, Структура данных модуля управления инцидентами

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

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

·        ID. Идентификатор инцидента;

·        Title. Тема инцидента. Обычно она содержит его краткое описание;

·        Description. Полное описание инцидента;

·        ConfigurationItemID. Идентификатор конфигурационной единицы;

·        ConfigurationItemCategoryID. Идентификатор категории конфигурационных единиц;

·        ResolutionTime. Время разрешения инцидента;

·        ReactionTime. Время реакции на инцидент;

·        ServiceID. Идентификатор услуги, которая должна быть предоставлена в процессе разрешения данного инцидента;

·        PlannedResolutionTime. Планируемое время разрешения;

·        PlannedReactionTime. Планируемое время реакции;

·        Number. Номер инцидента. Используется для упрощения коммуникации между исполнителями и операторами;

·        RequesterID. Идентификатор пользователя, который завёл данный инцидент. Данное поле может оставаться пустым в случае, если бизнес-процессы компании подразумевают получение обращений от людей, чьи пользователи не заведены в информационной системе;

·        ContactUserID. Идентификатор контактного лица. Поскольку часто отправка обращений происходит не самим заявителем, а его представителем, связь с которым должна осуществляться в процессе разрешения инцидента, данные 2 лица заносятся в разные поля объекта;

·        AssigneeID. Идентификатор пользователя, разрешающего данный инцидент;

·        AssignedGroupID. Идентификатор группы, на которую назначено разрешение данного инцидента;

·        Priority. Приоритет разрешения данного инцидента;

·        SpecificationID. Идентификатор спецификации договора, согласно которой должно быть произведено разрешение данного инцидента;

·        SolutionCode. Код разрешения инцидента. Часто данное поле содержит краткую информацию о том, успешно ли он разрешён;

·        SolutionDescription. Описание разрешения;

·        CloseReason. Код закрытия. Данное поле часто содержит причину закрытия данного обращения. Например, оно может потерять свою актуальность в случае его разрешения самим заявителем, или может быть просто успешно разрешено исполнителем;

·        CloseDescription. Описание причины закрытия;

·        Status. Статус инцидента. Варианты значения данного поля должны быть согласованы с владельцем системы, однако стандартными являются:

o   Новый. Данный статус назначается инцидентам, которые были только что заведены в информационной системе и ещё не были маршрутизированы на исполнителя;

o   Назначен. Данный статус назначается инцидентам, которые были назначены на исполнителя или группу исполнителей, однако ещё не были взяты в работу;

o   В работе. Данный статус назначается инциденту после принятия его в работу;

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

o   Выполнен. Данный статус назначается инциденту, когда исполнитель завершает работы по разрешению инцидента;

o   Закрыт. Данный статус назначается инциденту, когда заявитель подтверждает, что инцидент был успешно разрешён. Также данный статус может проставляться инциденту по истечении какого-либо времени;

o   Отменён. Данный статус назначается инциденту в случае, если пользователь отменил своё обращение. Это действие требует обязательного комментария со стороны пользователя;

o   Отклонён. Данный статус назначается инциденту в случае, если исполнитель по какой-либо причине не имеет может разрешить данный инцидент.

·        RequestedBy. Способ поступления данного инцидента. Варианты значений данного поля могут варьироваться в зависимости от количества каналов связи, с которыми работает данная информационная система и её компания-владелец в целом;

·        ResponseBy. Предпочитаемый способ обратной связи;

·        LocationID. Идентификатор местоположения, на котором произошёл данный инцидент.

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

ControlTime. Данные объекты и соответствующая им таблица содержат информацию о том, какие времена должны быть зафиксированы в информационной системе. Необходимыми для корректного функционирования системы являются только:

·        Время прибытия на объект;

·        Время реакции;

·        Время переназначения;

·        Время разрешения.

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

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

·        ID. Идентификатор контрольного времени;

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

·        ID. Идентификатор факта контрольного времени;

·        InstanceID. Идентификатор экземпляра объекта, к которому относится данное время;

·        Status. Статус факта данного времени. Может принимать два значения:

o   Актуально;

o   Не актуально.

·        ControlTimeID. Идентификатор контрольного времени;

·        Time. Время возникновения факта контрольного времени;

·        Type. Идентификатор объекта, к которому относится данная записать. Может так же принимать два значения:

o   Идентификатор объекта Incident;

o   Идентификатор объекта ServiceRequest.

Программный интерфейс взаимодействия с модулем

Модуль управления инцидентами должен содержать следующие функции:

·        Получения списка инцидентов данного пользователя;

·        Создания инцидента;

·        Редактирования инцидента;

·        Проставления контрольного времени;

Список форм к разработке

·        Форма инцидента. Данная форма должна позволять заносить всю необходимую информацию об инциденте, а так же обеспечивать доступ ко всему необходимому функционалу, при помощи которого исполнители могут осуществлять движение инцидента по его жизненному циклу;

Взаимодействие с другими модулями

·        Модуль НСИ:

o   Определение текущих прав пользователя;

o   Получение записей из справочников;

·        Модуль управления уровнями обслуживания:

o   Расчёт контрольных сроков по запросам на обслуживание.

.9 Модуль управления запросами на обслуживание

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

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

Отличительной особенность реализации данного модуля в проектируемой системе является то, что администраторам системы даётся инструмент для настройки процесса разрешения данных обращений, что является функционалом, не присутствующем ни в одном решении класса Help Desk, FSM, CMMS или EAM.

Структура данных модуля

Рисунок 9, Структура данных модуля управления запросами на обслуживание

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

ServiceRequestTemplate. Данный объект содержит базовую информацию о доступность для пользователя запросе на обслуживание. Информация именно из данного объекта будет выводится на странице, содержащей доступные запросы на обслуживание.

·        ID. Идентификатор шаблона запроса на обслуживание;

·        Name. Название шаблона запроса на обслуживание, отображаемое пользователю;

·        ServiceID. Идентификатор услуги, соответствующей данному запросу на обслуживание. Используется для определения крайних сроков данного обращения;

·        FilterString. По аналогии с ранее описанными механизмами фильтрации, данное поле содержит строку, содержащую зависимости между различными фильтрами, применяемым к данному объекту.

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

·        ID. Идентификатор фильтра;

·        UserComparisonValue. Название функции из заранее предопределённого списка, возвращающей информацию о текущем пользователе;

·        ComparisonOperator. Оператор сравнения UserComparisonValue и ComparisonValue;

·        ComparisonValue. Предопределённое значение. Может содержать идентификатор компании, сотрудникам которой доступен данный запрос на обслуживание, роль и другую информацию, при помощи которой можно определить права пользователя.

WorkflowStepTemplate. Данные объекты представляют из себя последовательность шагов, необходимых для выполнения в процессы разрешения данного запросами на обслуживание. Они содержат в себе информацию о том, какие именно работы и в какой последовательности должны быть выполнены.

·        ID. Идентификатор шага;

·        StepType. Тип шага. Данный параметр может принимать 2 значения:

o   Идентификатор объекта ApprovalTemplate;

o   Идентификатор объекта WorkOrderTemplate.

·        Order. Порядковый номер данного шага;

·        WaitFor. Список порядковых номеров шагов, завершения который дожидается данный. В случае, если данный параметр не задан, шаг принимается в работу сразу;

·        RequireOne. Данный флаг показывает, требуется ли для принятия в работу данного шага завершение всех шагов, которых он дожидается или достаточно только одного;

·        TemplateID. Идентификатор экземпляра объекта, указанного в параметре StepType.

WorkOrderTemplate. Данный объект содержит информацию, необходимую исполнителю для начала осуществления работ по наряду, содержащемуся в цепочке обработки запроса на обслуживание.

·        ID. Идентификатор шаблона наряда;

·        Name. Название данного наряда;

·        Description. Описание работ;

·        AssigneeID. Идентификатор исполнителя данного наряда;

ApprovalTemplate. Данный объект содержит информацию о том, какое согласование должно быть создано при отправке соответствующего запроса на обслуживание.

·        ID. Идентификатор шаблона согласования;

·        ApprovalType. Данный параметр указывает, является ли данное согласование согласованием группы или же отдельного пользователя.

·        ApproverID. В зависимости от значения параметра ApprovalType данное поле может содержать либо идентификатор группы, на которую будет назначено данное согласование, либо идентификатор пользователя;

·        RequireOne. Данный флаг показывает, достаточно ли решения одного для принятия решения по данному согласию. Если флаг не поднят, то результат согласования считается положительным только в том случае, если все его участники его согласовали;

·        Description. Описание предмета согласования.

ServiceRequest. Данный объект содержит информацию об уже созданном запросе за обслуживании, который подлежит разрешению. Как можно заметить, большинство полей шаблона запроса на облуживание копируется в реальный объект.

·        ID. Идентификатор запроса на обслуживание;

·        Name. Название запроса на обслуживание, которое копируется из шаблона запроса;

·        ServiceID. Идентификатор услуги, соответствующей данному запросу;

·        Requester. Заявитель;

·        ResolutionTime. Время завершения работ по запросу;

·        ReactionTime. Время принятия данного запроса в работу;

·        PlannedResolutionTime. Плановое время завершения работ по запросу;

·        PlannedReactionTime. Плановое время принятия запроса в работу;

·        ServiceRequestTemplateID. Идентификатор шаблона, на основании которого был создан данный запрос на обслуживание;

·        Number. Порядковый номер данного запроса на осблуживание, который служит для упрощения коммуникации между исполнителями и операторами.

WorkflowStep. Экземпляры данного объекта почти ничем не отличаются от своих шаблонных аналогов, за исключением того, что поле StepType содержит идентификаторы объектов WorkOrder и Approval, вместо их шаблонов. Помимо этого, поле TemplateID заменяется на StepInstanceID, в котором содержится идентификатор наряда или согласования, который относится к данному шагу. Помимо этого добавляется поле ServiceRequestID, содержащее информацию о том, к какому запросу на обслуживание относится данный элемент цепочки.

WorkOrder. Экземпляры данного объекта так же слабо отличаются от своих шаблонных вариантов, за исключением того, что им добавляется система статусов, а также описание решения, необходимое к заполнению по завершению работ по данному наряду.

Approval. Так же как и объект WorkOrder, Approval почти ничем не отличается от ApprovalTemplate за исключением системы статусов.

Системы статусов данных объектов не приводятся в данной работе, поскольку они могут сильно варьироваться в зависимости от требований компаний6 внедряющей себе описываемую систему.

ApprovalItem. Экземпляры данного объекта создаются при формировании согласований. Они созданы для того, чтобы, в случае, если согласование было создано на группу лиц, можно было учитывать голоса каждого из участников группы.

·        ID. Идентификатор элемента согласования;

·        ApprovalPersonID. Идентификатор пользователя согласующего;

·        Status. Статус согласования;

·        DecisionComment. Комментарий, вводимый при отклонении или приостановке согласования.

Программный интерфейс взаимодействия с модулем

Модуль управления запросами на обслуживание должен содержать следующие функции:

·        Получения списка запросов на обслуживание данного пользователя;

·        Создания запросов на обслуживание и внесение в них корректировок;

·        Получения информации о данном запросе на обслуживание;

·        Изменение статуса данного запроса на обслуживание;

·        Получение списка запросов на обслуживание, доступным данному пользователю;

·        Изменение статуса элемента согласования;

·        Изменение статуса наряда;

·        Добавление в цепочку выполнения запроса на обслуживание нового элемента.

Список форм к разработке

·        Форма списка доступных запросов на обслуживание;

·        Универсальная форма запроса на обслуживание;

·        Форма наряда;

·        Форма согласования;

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

Взаимодействие с другими модулями

·        Модуль НСИ:

o   Определение текущих прав пользователя;

o   Получение записей из справочников;

·        Модуль управления уровнями обслуживания:

o   Расчёт контрольных сроков по запросам на обслуживание.

.10 Модуль управления планированием работ

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

Основными функциональными возможностями данного модуля должны являться:

·        Планирование работ;

·        Оперативное управление работами, включая переносы их дат и удаление;

·        Контроль выполнение задач.

Структура данных модуля

Рисунок 10, Структура данных модуля управления планированием работ

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

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

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

·        ID. Идентификатор правила проведения работы;

·        ConfigurationItemID. Идентификатор конфигурационной единицы, работы по которой необходимо провести;

·        WorkPeriod. Период проведения данной работы в днях;

·        ServiceRequestTempleateID. Идентификатор шаблона запроса на обслуживание. Данный шаблон запроса на обслуживание во создания экземпляра работу будет преобразован в реальный запрос на обслуживание, выполнение которого будет отслеживаться в последствии;

·        LastWorkDate. Дата последнего проведения данной работы;

·        CreateBefore. Период, за который должна создаваться данная работа в днях. Данный параметр служит для того, чтобы работы создавались не в день их проведения, а заранее, что может быть использовано исполнителями для грамотного распределения собственного рабочего времени;

PlanWorkFact. Данный объект содержит информацию о реальном экземпляре регламентной работы. Именно по информации, хранящейся в данном объекте будет проводиться контроль выполнения плана. По умолчанию данные запросы на обслуживание попадают в список нераспределённых, после чего операторами маршрутизируются на конкретные рабочие группы.

·        ID. Идентификатор факта проведения работ;

·        Date. Запланированная дата проведения работ;

·        PlanWorkRuleID. Идентификатор правила проведения работ, в связи с которым был создан данный экземпляр;

·        Status. Статус проведения работ. Может принимать несколько значений:

o   Запланирована. Данный статус назначается, когда работа только была создана;

o   Проведена. Данный статус назначается после того, как работа была проведена;

o   Отменена. Данный статус назначается в тех случаях, когда экземпляр работы был создан, однако было принято решение её не проводить;

o   В работе. Данный статус назначается, когда запрос на обслуживание принимается в работу;

o   Не может быть выполнена. Данный статус назначается в тех случаях, когда задачи по работе начали выполняться, однако не могли быть завершены по тем или иным причинам. Данный статус требует комментария от исполнителя;

o   Перенесена. Данный статус назначается, когда работа была перенесена на другую дату;

·        ServiceRequestID. Идентификатор запроса на обслуживание, связанного с данным фактом проведения работ.

·        AssignedGroupID. Идентификатор группы, которая отвечает за выполнение данной работы;

·        AssigneeID. Идентификатор пользователя, который отвечает за выполнение данной работы. Может быть пустым.

Механизмы для реализации

Прежде всего, необходимо реализовать механизм, который на основании заведённых в системе объектов PlanWorkRule будет производить планирование работ на определённый пользователем период. Кроме того, у пользователя должна быть возможность автоматической актуализации данного плана в случаях, когда были созданы новые экземпляры PlanWorkRule и они должны создать работу в периоде, на который уже был сгенерирован план.

Программный интерфейс взаимодействия с модулем

Модуль управления планированием работ должен содержать следующие функции:

·        Произведения планирования на данный период;

·        Корректировка текущего плана проведения работ;

·        Просмотр план/факта работ, содержащего информацию о запланированных работах на данный период, а также сводящим информацию о том, какие из них не были выполнены;

·        Просмотр плановых работ, связанных с данной конфигурационной единицей;

·        Создание и редактирование правила проведения работ;

·        Удаление правила проведения работ.

Список форм к разработке

·        Форма плана работ;

·        Форма план/факта работ;

·        Форма факта проведения работ.

Создание формы для правил проведения работ не является обязательным, поскольку все CRUD операции могут быть осуществлены посредством использования формы универсального объекта, описание которой приведено в описании модуля управления объектами (Приложение, Рисунок 10).

Взаимодействие с другими модулями

·        Модуль НСИ:

o   Определение текущих прав пользователя;

o   Получение записей из справочников;

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

.11 Модуль управления полевыми инженерами

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

Структура данных модуля

Рисунок 11, Структура данных модуля управления полевыми инженерами

. Данные объекты, будучи прикреплёнными к конкретным моделям оборудования содержат в себе инструкции, которыми могут воспользоваться полевые инженеры в процессе проведения работ. Соответственно, данный модуль должен обладать функцией прикрепления документов к моделям оборудования.

·        ID. Идентификатор прикреплённой инструкции;

·        ModelID. Идентификатор модели, к которой прикрепляется данная инструкция;

·        Content. Закодированное содержимое файла. Поскольку базы данных не позволяют хранить файлы в виде, в котором их можно было бы отправлять конечному пользователю, файлы необходимо преобразовывать в строковые данные. С этой целью можно использовать преобразование base64;

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

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

·        ID. Идентификатор местоположения во времени;

·        UserID. Идентификатор пользователя информационной системы;

·        Latitude. Географическая широта точки, на которой находился пользователь в данный момент;

·        Longitude. Географическая долгота точки, на которой находился пользователь в данный момент;

·        Time. Время фиксации местоположения пользователя.

Механизмы для реализации

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

Помимо этого, в приложении должна присутствовать возможность отправки его пользователям PUSH-уведомлений, что позволит максимально эффективно управлять трудовыми ресурсами компании, незамедлительно направляя им указания о том, чем им стоит заняться в данный момент, что может помочь при разрешении инцидентов с высоким приоритетом.

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

Программный интерфейс взаимодействия с модулем

Модуль управления полевыми инженерами должен содержать следующие функции:

·        Получение запланированных на сегодня работ;

·        Получение маршрута объезда;

·        Получение списка задач по данному запросу на обслуживание;

·        Получение списка инструкций по данной модели оборудования;

·        Получение конкретной инструкции для открытия;

·        Фиксация местоположения мобильного инженера;

Список форм к разработке

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

Взаимодействие с другими модулями

·        Модуль НСИ:

o   Определение текущих прав пользователя;

o   Получение записей из справочников;

·        Модуль управления планированием работ:

o   Получение списка работ, назначенных на данного пользователя;

·        Модуль управления инцидентами:

o   Получения списка инцидентов, назначенных на данного пользователя;

Заключение

В процессе выполнения данной работы было сформулировано описание объектов и верхнеуровневых алгоритмов, которое могло бы быть использовано командами разработки информационных систем по автоматизации процессов сервисного обслуживания оборудования с целью снижения трудозатрат на разработку архитектуры разрабатываемого решения. Отличительной особенностью описанного проекта информационной системы является то, что она не направлена на автоматизацию какой-либо конкретной сферы процессов сервисного обслуживания оборудования, а может являться и внешней системой, через которую происходит сбор обращений клиентов компании, чего не хватает решениям классов EAM, CMMS и FSM, а также может быть системой, автоматизирующей процессы разрешения данных инцидентов, что зачастую отсутствует в решениях класса Help Desk.

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

Список литературы

1.      ISO 55000-55002:2014 [Электронный ресурс] / International Organization for Standardization. - URL: <https://www.iso.org/standard/55088.html>. (Дата обращения: 14.04.2017).

.        ГОСТ 18322-78. Система технического обслуживания и ремонта техники. Термины и определения [Электронный ресурс] / Техэксперт. - URL: <#"897313.files/image021.gif">

Рисунок 12, Макет формы универсального объекта