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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

· 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 Получение записей из справочников;

3.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. Название контрольного времени;

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

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

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

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

o Актуально;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Модуль НСИ:

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

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

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

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

3.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. Описание работ;

· GroupID. Идентификатор группы исполнителей;

· 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 Расчёт контрольных сроков по запросам на обслуживание.

3.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 Получение записей из справочников;

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

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

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

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

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

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

· 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).

2. ГОСТ 18322-78. Система технического обслуживания и ремонта техники. Термины и определения [Электронный ресурс] / Техэксперт. - URL: http://docs.cntd.ru/. (Дата обращения: 08.02.2017).

3. ISO/IEC 20000-1:2011 [Электронный ресурс] / International Organization for Standardization. - URL: https://www.iso.org/standard/51986.html. (Дата обращения: 15.02.2017).

4. EAM-cистема [Электронный ресурс] / TAdviser. Государство. Бизнес. ИТ. - URL: http://tadviser.ru/a/56380. (Дата обращения: 20.04.2017).

5. The Open Group. The Open Group IT4IT Reference Architecture, Version 2.1. The Open Group: -, January 2017.

6. Cabinet Office. ITIL (2011 edition). London: TSO, 2011.

7. Управление процессами ТОиР: как добиться эффективности? [Электронный ресурс] / KPiLIB. Знания для бизнеса. - URL: http://www.kpilib.ru/article.php?page=379. (Дата обращения: 16.03.2017).

8. CMMS [Электронный ресурс] / TAdviser. Государство. Бизнес. ИТ. - URL: http://tadviser.ru/a/53206. (Дата обращения: 23.04.2017).

9. Building business value with IT4IT [Электронный ресурс] / Trending - News Portal. - URL: http://trendingtalks.info/building-business-value-with-it4it. (Дата обращения: 12.04.2017).

10. Ovidiu S. Noran. Business Modelling: UML vs. IDEF. Griffith University: South East Queensland, 2000.

11. Ovidiu S. Noran. UML vs IDEF: An Ontology-oriented Comparative Study in View of Business Modelling. International Conference on Enterprise Information Systems (ICEIS 2004): Porto, Portugal, 2003.

12. Нотация и семантика языка UML [Электронный ресурс] / Интуит - национальный Открытый Университет. - URL: http://www.intuit.ru/studies/courses/32/32/info. (Дата обращения: 23.03.2017).

13. Pattern: Microservice Architecture [Электронный ресурс] / Microservice Architecture. - URL: http://microservices.io/patterns/microservices.html. (Дата обращения: 02.05.2017).

14. НСИ [Электронный ресурс] / Академик. - URL: http://dic.academic.ru/dic.nsf/ruwiki/302417. (Дата обращения: 06.05.2017).



Приложения

Обзор функциональных возможностей систем CMMS, EAM, Help Desk, FSM

В данной таблице приведен обзор функциональных возможностей CMMS, EAM, Help Desk и FSM систем.

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

· Знак «-/+» означает, что данный класс систем не позволяет полностью автоматизировать указанный в заголовке строки процесс, однако содержит функции, позволяющие это сделать частично;

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

Таблица 1, Обзор функциональных возможностей систем CMMS, EAM, Help Desk, FSM

Функция/Процесс	CMMS	EAM	Help Desk	FSM
Управление инцидентами	-/+	-/+	+	-/+
Управление запросами на обслуживание	-	-	+	-/+
Управление знаниями	-	-	+	+
Управление активами и конфигурациями	+	+	+	+
Управление уровнем услуг	+	+	+	+
Управление поставщиками услуг	-	-	+	+
Учёт складских запасов	+	+	-	+
Планирование проведения технического обслуживания	+	+	-/+	-
Хранение НСИ	+	+	+	-/+
Контроль выполнения задач полевыми инженерами	-	-	-	+



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

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

Размещено на Allbest.ru