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

Размещено на http://www.allbest.ru/

Оглавление

Введение

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

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

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

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

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

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

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

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

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

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

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

3.6 Модуль НСИ

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

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

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

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

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

Заключение

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

Приложения



Введение

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

CMMS

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

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

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

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

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

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

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

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

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

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

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

EAM

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

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

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

Help Desk

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

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

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

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

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

FSM

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

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

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

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

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

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

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

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

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

ITIL v3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

COBIT

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

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

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

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

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

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

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

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

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

IT4IT

Стандарт архитектуры 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.

IT4IT подходит к проблеме управления предоставлением услуг несколько иначе, нежели 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) и другие, поскольку, несмотря на понятные и удобные механизмы проектирования бизнес-процессов, они не позволяют описать техническую составляющую проектируемой информационной системы.

UML

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

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

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

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

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

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

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

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

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

UML-диаграммы описывают систему с двух различных представлений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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