CC BY
581
ITSM В ITIL - СТРУКТУРНО-ОБРАЗУЮЩИЙ ПОДХОД К ПРОЕКТИРОВАНИЮ, ВНЕДРЕНИЮ И УПРАВЛЕНИЮ ИТ-СИСТЕМАМИ КЛАССА HELP (SERVICE) DESK Р.В. Иванов, А.Е. Михайленко Научный руководитель - к.т.н., доцент Н.Ф. Гусарова
Представлен анализ применения идеологии ITIL для информационного сопровождения обслуживания заявок в подразделениях технической поддержки.
Введение
В работе [1] рассматривалась задача моделирования процесса обработки заявок в службе технической поддержки (СТП) сложных технических систем. В ней было показано, что подавляющее большинство предприятий, входящих в сегмент малого и среднего бизнеса (SMB), не имеют четкого регламента работы службы технической поддержки. Такая ситуация связана с тем, что немногие компании готовы инвестировать средства в управление ИТ-инфраструктурой, а свои убытки, связанные с нарушением функционирования сервисов, считают допустимо-приемлемыми.
Большие компании, напротив, понимают важность ИТ-процессов и влияние их на бизнес в целом, поэтому вкладывают немалые средства в поддержание ИТ-инфраструктуры. Успешный опыт таких компаний нашел обобщение в библиотеке инфраструктуры информационных технологий ITIL [2]. В настоящей статье представлен анализ применения идеологии ITIL для разработки системы информационного сопровождения (ИТ-системы) обслуживания заявок в подразделениях технической поддержки.
Проблемно-ориентированный анализ структуры ITIL
ITIL (англ. Information Technology Infrastructure Library) - библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий [3], являющаяся де-факто общепризнанным стандартом управления информационными системами.
Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000) [4, 5]. Он не имеет себе равных по обеспечению измеримости и управляемости деятельностью предприятия, акцентирует внимание предприятия на достижении поставленных целей, а также на ресурсах, затраченных на достижение этих целей. Со временем из библиотеки ITIL выросла значительная часть принятых во всем мире стандартов построения ИТ-процессов.
ITIL (версия 2) состоит из 7 томов (рис. 1), в которых изложена методика управления ИТ-инфраструктурой предприятия [6]. Целями этой методики являются предоставление и обеспечение высокого качества ИТ-услуг, которые должны соответствовать бизнес-требованиям организации и повысить степень удовлетворенности пользователей. Каждый том библиотеки ITIL охватывает отдельную область управления ИТ-инфраструктурой.
В мае 2007 года Агентство Office of Government Commerce [7] (Великобритания) выпустило стандарт ITIL v.3 [8], включающий в себя только пять книг: Service Strategy, Service Design, Service Transition, Service Operation, Continuai Service Improvement. На сегодняшний день не существует общепризнанного русскоязычного глоссария, поэтому использование методик этой версии стандарта только начинается.
Наиболее известная часть ITIL v.2 — десять базовых процессов (рис. 2), обеспечивающих поддержку и предоставление ИТ-сервисов - Information Technology Service Management или ITSM [9, 10, 11, 12].
Планирование внедрения управления услугами (Planning to Implement Service Management)
Управление услугами (Service Management)
Поддержка услуг (Service Support)
Предоставление услуг (Service Delivery)
Управление приложениями (Application Management)
Рис. 1. Структура ITIL v.2
Service Support
Information Technology Service Management Service Delivery
l^J Incident Management I^J Problem Management
Configuration Management 111 Change Management
l^j Release Management Service Desk
Service Level Management Capacity Management
^J Availability Management ^ IT Service Continuity Management IM Financial Management
Рис. 2. Структура ITSM
Кроме того, в структуре процессов ITSM важную роль играет служба поддержки пользователей «Service Desk».
В аспекте задачи моделирования процесса обработки заявок в СТП наибольший интерес представляют такие части книги «Service Support» (поддержка услуг) библиотеки ITIL, как «Service Desk» (служба поддержки пользователей), «Incident Management» (процесс управления инцидентами) и «Problem Management» (процесс управления проблемами).
Анализ подходов к парированию неопределенностей бизнес-процесса
на базе концепции ITIL
Многие компании предложили свои подходы к реализации идей, заложенных в ITIL. Наибольшую известность получили модель Hewlett-Packard - ITSM HP Reference Model [13] и методология Microsoft Operations Framework (MOF) [14, 15]. Внесенные в
MOF, по сравнению с ГТГЬ, дополнения и изменения позволяют использовать ее в гетерогенных средах (рис. 3). Отметим, что все модификации, вносимые конкретными фирмами, отражают специфику рассматриваемых ими конкретных бизнес-процессов.
Windows ХР
Windows mobile
Symbian OS
Рис. 3. Пример гетерогенной среды
Как показано в работе [1], специфика бизнес-процесса СТП состоит в наличии в нем неопределенностей различного происхождения (в частности, совмещение ролей акторами СТП, семантические неопределенности формулировок и др.). Рассмотрим возможности вышеописанных функций управления «Service Desk», «Incident Management» и «Problem Management» для парирования неопределенностей бизнес-процесса.
Service Desk - Служба поддержки
Проактивное взаимодействие. При управлении запросами клиентов важную роль играет понятие единой точки доступа. HelpDesk, являясь единой точкой доступа, должен представлять собой последовательный интерфейс между пользователями и техническими специалистами ИТ-отдела, реализуемый, например, посредством традиционных видов связи (телефон, e-mail, факс, веб-форма и др.).
Независимо от конкретной технологии реализации интерфейса, ITIL рекомендует предусмотреть в ИТ-системе тактику «проактивных взаимодействий», являющуюся предупреждающим действием. Служба поддержки должна заранее (проактивно) обеспечивать клиентов информацией, например, о запланированной остановке сервиса, профилактических или аварийных работах. Эта информация может включать в себя известные проблемы, которые, вероятно, вызовут трудности или прерывания сервиса в будущем.
Как показал анализ, в разрабатываемой ИТ-системе наиболее эффективным является реализация проактивного взаимодействия в виде информирования группы пользователей, на работу которых могут быть наложены ограничения, связанные с недоступностью сервисов, или работа которых может быть полностью парализована, посредством e-mail. Кроме того, целесообразно предусмотреть информационную полосу на главной странице портала службы поддержки (рис. 4) для публикации информации о предстоящих мероприятиях и событиях, по которым в данный момент идет оператив-
ное реагирование, что уменьшит или исключит вовсе поступление заявок, на которые службе поддержки пришлось бы реагировать ответом о проведении работ.
Рис. 4. Пример информационной полосы на главной странице портала
службы поддержки
Организация системы ролевых функций. Как особо отмечено в 1ТГЬ, успешная работа службы поддержки возможна только при четком понимании каждым ее актором своей роли1 и ее важности в общем деле. При создании ролей на этапе проектирования системы необходимо исходить из размеров самого предприятия, ИТ-инфраструктуры и ИТ-отдела. На этой основе следует определить вид структуры службы поддержки (СП):
1) централизованная СП, для которой не имеет значения географическое положение пользователя, использующая децентрализованные группы реагирования и разрешения заявок на местах;
2) децентрализованная СП, состоящая из нескольких служб в различных географических местах, например, оказывающая поддержку на разных языках в разных временных зонах;
3) виртуальная СП, объединяющая элементы централизованной и децентрализованной СП, основанная на развитии сетей и телекоммуникаций, использующая общий язык и стандарт записи запросов.
Однако все эти варианты подходят для организаций с достаточно развитой ИТ-инфраструктурой. Небольшие и малые организации, на которые, в первую очередь, ориентирована данная статья, используют схему «одна поддержка (операторы) + одна группа реагирования (в данном случае - технические специалисты)».
Для устранения неопределенностей, связанных с отсутствием закрепления должностного функционала за конкретными сотрудниками, в разрабатываемой ИТ-системе предлагается организовать систему ролевых функций, которая позволит создать конеч-
1 Подробнее в [6] раздел «Service Desk» / Пункт «Service Desk responsibilities, functions, staffing levels etc».
ную матрицу должностных обязанностей в СТП и поставить ее в соответствие каждой роли (набору функций) конкретного сотрудника СТП.
Кроме того, для совершенствования модели обслуживания в СТП целесообразно организовать динамическое разделение и совмещение ролей в зависимости от состояния базы знаний ИТ-системы и других факторов. Формами такой организации могут являться совмещение ролей и введение второй линии поддержки пользователей.
Совмещение ролей. Такая форма организации может встречаться, например, на начальных этапах внедрения ИТ-системы, когда происходит начальное накопление базы знаний и поток входящих заявок является небольшим. В этом случае технические специалисты (класса «Эксперт») выполняют функции по приему, регистрации и разрешению заявок пользователей, т.е. выполняют функции оператора ИТ-системы и технического специалиста как такового (рис. 5).
При росте количества сотрудников в компании увеличивается поток заявок, направляемых в СТП. Это может вызвать задержки в обслуживании вновь поступающих заявок. В такой ситуации становится очевидным, что введение роли оператора разгрузит технических специалистов от выполнения рутинных операций и позволит им заниматься техническими вопросами заявок.
Кроме того, при достаточном накоплении информации в базе знаний, как и в ситуации, описанной выше, целесообразно переложить часть функций на сотрудника с ролью «оператор». Даже не имея высокой квалификационной подготовки в предметной области, он, используя сформированную базу знаний, сможет разрешать входящие заявки и, тем самым, отсеивать поток заявок, решения по которым уже имеются.
Именно эти показатели говорят о необходимости перехода в стадию эксплуатации по схеме «оператор + технические специалисты». Однако при эксплуатации ИТ-системы происходит усложнение входящих запросов. Эти запросы могут быть не в компетенции оператора, но могут быть разрешены, с большой долей вероятности, более опытными операторами, поэтому, при наличии расширенного штата сотрудников СТП, рекомендуется введение второй линии поддержки.
Введение второй линии поддержки пользователей. Разделение функций и многоступенчатая обработка входящей заявки предполагает, что задачей команды первой линии является попытка разрешить поступивший запрос либо при первом контакте, либо используя известные обходные решения1, а также собственные опыт и знания. Если запрос не будет разрешен описанными способами, то будет сформирована заявка и передана в группу реагирования - вторую линию поддержки, которая попытается решить
1 обходное решение - временное решение, не устраняющее причины инцидента или проблемы.
Рис. 5. Пример совмещения ролей
вопрос, а при невозможности это сделать присвоит заявке соответствующие классификаторы и отправит ее в работу к техническим специалистам. Структуры группы реагирования могут различаться в зависимости от конкретного предприятия и быть организованы, например, по платформам и приложениям (группа серверов, десктопов, сетей или баз данных).
Таким образом, в ИТ-отделе динамично развивающейся компании можно будет выделить 3 ступени поддержки (рис. 6): первая линия поддержки, вторая (группа реагирования) и технические специалисты (заметим, что рекомендации 1Т1Ь не запрещают введения и большего числа уровней поддержки).
Рис. 6. Рекомендуемая структура службы поддержки
Следует отметить, что могут возникать ситуации, когда операции по каким-либо функциям могут быть временно переподчинены, переданы или упразднены, а, следовательно, и роли, в чью ответственность входили соответствующие работы. В первом случае снова может возникать совмещение ролей.
Для реализации перечисленных выше форм организации СТП в разрабатываемой ИТ-системе должны быть предусмотрены механизмы динамического управления ролями:
• механизм для создания и изменения структуры и иерархии ролей в службе поддержки в целях её более эффективной организации;
• механизм динамического изменения роли, который будет использоваться, например, в случае совмещения ролей (роль более высокого уровня иерархии может быть изменена на разрешенную роль более низкого или смежного, для совершения необходимых функций поддержки).
Работа механизма отслеживания позволит контролировать выполнение заявки в разрезе информации о том, кем она была выполнена, и в какой роли был исполнитель, а также даст возможность динамически регулировать количество персонала в той или иной роли, выделять новые роли, исходя из потребностей ИТ-инфраструктуры.
Использование рекомендаций раздела Service Desk применительно к разрабатываемой ИТ-системе помогает наиболее целесообразно организовать работу в СТП, распределить работы по ролям и создать четко формализованную матрицу ответственности в привязке к конкретным сотрудникам СТП.
Incident Management & Problem Management -Управление инцидентами и проблемами
Переходя к предоставлению ИТ-услуг, введем понятия инцидента, запроса сервиса и проблемы в нотации библиотеки ITIL [6, 16]:
• инцидентом называется любое событие, снижающее качество ИТ-услуги или ограничивающее полноту ее предоставления;
• проблемой называется группировка одного или более инцидентов, имеющих схожие характеристики и неизвестную причину (заметим, что при поступлении новой заявки невозможно сразу определить, является ли она заявкой по инциденту или по проблеме);
• запросом сервиса называется любое событие, не относящееся к выше перечисленным, в т. ч. запрос на смену пароля, подключение рабочего места нового сотрудника и т. п.
Известно, что на практике 20% проблем, которые приходится решать ИТ-специалистам, являются причиной 80% инцидентов, поэтому заблаговременное выявление проблем не менее важно, чем своевременное устранение инцидентов. В связи с этим управление инцидентами является важным процессом. Цель этого процесса - как можно скорее устранить любой инцидент.
Схема организации этого процесса, согласно рекомендациям раздела Incident Management (управление инцидентами), в котором освещаются проблемы восстановления работоспособности системы или отдельных ее компонентов при минимальных потерях для бизнеса, представлена на рис. 7.
Многие организации, действуя в соответствии с этой схемой, достигают высоких показателей в разрешении инцидентов, снижающих производительность, и уменьшении перерывов в работе, разрабатывая в высшей степени действенные процессы и процедуры управления инцидентами. Но при таком варианте развития событий в компаниях поддержка клиентов часто концентрируется на восстановлении после инцидентов, а не на устранении их основных первопричин. Это ведет к повторению инцидентов, что снижает как степень удовлетворенности клиентов, так и экономическую эффективность бизнес-процесса.
Для решения этой проблемы в разрабатываемой ИТ-системе предлагается после обработки заявки по схеме рис. 7 автоматически заносить максимально возможный
объем информации об инциденте и методах его разрешения в базу знаний для последующего ее использования. Это в дальнейшем приведет к тому, что многие сервисные запросы и инциденты будут обработаны и решены без выхода за пределы деятельности поддержки, т.е. без обращения к инженерам ИТ-отдела.
Процедура по серьезным инцедентам
/ Разрешенные ^инц^ и сервисныеу
Рис. 7. Блок-схема управления инцидентами
Для выявления проблем (причин инцидентов) предлагается использовать ресурс линий поддержки. Выполняя повседневное координирование процесса управления инцидентами, они выявляют многократно повторяющиеся инциденты, которые указывают на основную проблему, т. е. линии поддержки являются важным источником информации для групп реагирования и ИТ-специалистов, которые занимаются управлением проблемами. В случае небольшого штата службы поддержки эти функции реализуются конкретными исполнителями в ходе совмещения ролей.
Выявленные таким образом проблемы будут фиксироваться в специальном разделе базы знаний, который будет доступен для использования как всем линиям поддержки, так и ИТ-специалистам. Первым - для установления соответствия новых инцидентов существующим проблемам, вторым - для возможного объединения нескольких проблем в одну или решения одних проблем на основе знаний о других.
Типовая схема управления проблемами, согласно разделу Problem Management, представлена на рис. 8. Управление проблемами направлено на поиск и фиксирование обходных путей и решений, которые могут заключаться в изменении ИТ-инфраструктуры (рис. 9). Эти решения и изменения должны применяться службой поддержки при первоначальной обработке новых инцидентов.
Управление инцидентами и проблемами тесно связаны, но имеют совершенно разную направленность в рамках организации поддержки. Если управление инцидентами направлено на как можно более быстрое восстановление нормальной работы сервиса, то управление проблемами концентрируется на выявлении и устранении основных проблем и их первопричин.
Данные о проблеме и инциденте
Регистрация и классификация проблемы
I
Исследование и диагностика
роТ
Контроль ошибок
Закрытие проблемы
I
Активный анализ и оценка
/ Разрешенные \ ( проблемы и J
Рис. 8. Блок-схема управления проблемами
Рис. 9. Цикл событий проблемы Заключение
В статье рассмотрены рекомендации библиотеки ITIL, являющиеся базовыми в аспекте разработки систем класса Help (Sevice) Desk. Сформулированы функциональные требования для эффективного управления инцидентами, проблемами и СТП в целом, что позволяет наиболее эффективно использовать потенциал СТП. Кроме того, выявлено, что накопленная информация по инцидентам и проблемам может являться источником знаний для самостоятельного решения пользователями возникающих проблем; использовать эту информацию также можно для упреждающих советов, тем самым, реализуя концепцию проактивности.
В долгосрочной перспективе использование разработанной ИТ-системы позволит повысить эффективность работ по обслуживанию заявок, сократить простои оборудования и, следовательно, связанные с ними расходы.
Литература
1. Иванов Р.В., Маятин А.В., Михайленко А.Е. Моделирование процесса обработки заявок в службе технической поддержки сложных технических систем // Научно-технический вестник СПбГУ ИТМО. - 2007. - Вып. 44. Современные технологии. - С. 268-274.
2. The Official ITIL ® Website [Electronic resource]. - Electronic data. - APM Group Ltd., cop. 2007-2008. - Mode access: http://www.itil-officialsite.com/
3. Многоязычная общедоступная универсальная энциклопедия Википедия // ITIL [Электронный ресурс]. - Электрон. дан. - Режим доступа: http://ru.wikipedia.org/wiki/ITIL
4. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования. Введ. 31.08.2001. - М.: Госстандарт России: Изд-во стандартов, 2001. - V, 22 с.
5. ГОСТ Р ИСО 9004-2001. Системы менеджмента качества. Рекомендации по улучшению деятельности. Введ. 31.08.2001. - М.: Госстандарт России: Изд-во стандартов, 2001. - VI, 48 с.
6. Service Management - ITIL® Version 2. - London.: Office of Government Commerce (OGC): TSO (The Stationery Office), 2000. - 312 pages
7. Office of Government Commerce [Electronic resource]. - Electronic data. - Crown, cop. 2008. - Mode access : http://www.ogc.gov.uk/guidance_itil.asp
8. An Introductory Overview of ITIL ® v.3 [Electronic resource]. - Electronic data. -itSMF Ltd., cop. 2007. - Mode access : http://www.best-management-practice.com/gempdf/itSMF_An_Introductory_Overview_of_ITIL_V3.pdf
9. IT Service Management - ITIL® [Electronic resource]. - Electronic data. - TSO. -Mode access : http://www.best-management-practice.com/IT-Service-Management-ITIL/
10. Информационный портал по управлению ИТ [Электронный ресурс]. - Электрон. дан. - М.: Компания IT Expert. - Режим доступа: http://www.itsmportal.ru/
11. Независимый ITSM портал [Электронный ресурс]. - Электрон. дан. - М.: Бизнес-сеть "Kinetics", cop. 2006-2008 - Режим доступа: http://www.itsmonline.ru/
12. Многоязычная общедоступная универсальная энциклопедия Википедия // ITSM [Электронный ресурс]. - Электрон. дан. - Режим доступа: http://ru.wikipedia.org/wiki/ITSM
13. HP Services // ITSM HP Reference Model [Electronic resource]. - Electronic data. -Hewlett-Packard Development Company, L.P., cop. 2008. - Mode access: http://h20219.www2.hp.com/services/cache/78360-0-0-0-121.html
14. Microsoft TechNet // Microsoft Operations Framework (MOF) [Electronic resource]. - Electronic data. - Microsoft Corporation, cop. 2008. - Mode access: http://www.microsoft.com/mof
15. MOF Service Management Functions [Electronic resource]. - Electronic data. - Microsoft Corporation, cop. 2008. - Mode access: http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/
16. Таблица соответствия терминов ITIL v.2 и их русских аналогов [Электронный ресурс]. - Электрон. дан. - М.: Компания IT Expert. - Режим доступа: http://www.itsmportal.ru/articles/itil/2003-09-26%2000:00:00-18printable.html
