В статьях попробую раскрыть особенности внедрения практик ITIL, в том числе и с использованием OTRS.
Что хочет пользователь от ИТ отдела в первую очередь?
Попробую ответить, с оглядкой на ITIL, словами пользователя (это должен быть очень хороший пользователь), следующим образом: Пользователь хочет, чтобы ИТ-услуги предоставлялись в соответствии с согласованными с ИТ-отделом или внешней организации, предоставляющей услуги, ожиданиями. Если есть сбои в предоставлении услуг, то он должен знать куда обратиться и услуга должна быть восстановлена максимально быстро. Кроме этого пользователь хочет хочет получать некие ИТ-услуги, такие как установка ПО, поэтому в качестве базовых процессов, которые можно внедрять сразу, это:
Incident management (Управление инцидентами)
Request Fulfillment (Управление запросами на обслуживание)
Примеры инцидентов: не включается ПК, ошибка при запуске приложения и пр.
Примеры запросов на выполнение услуг: установка ПО, предоставление прав к корпоративным ресурсам и пр.
Чтобы предотвратить холивар в комментариях: установка ПО может быть как изменением, так и запросом на обслуживание, а предоставление прав может регулироваться Access Management (Управление доступом). Все это зависит от задач, стоящими перед ИТ отделом и описания тех Услуг, которые отдел предоставляет.
Немного терминологии ITIL
Инцидент-незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.
Цель процесса Incident Management: скорейшее восстановление ИТ-услуги для пользователей.
Немного об OTRS
На Habr были упоминания данной системы, тем не менее немного напомню о ней:
Как говорит Wiki — это открытая система обработки заявок, хотя ее функционал выходит далеко за рамки только обработок заявок.
Скачать систему можно на официальном сайте www.otrs.com Там же можно найти руководства по установке, настройке.
Настройка OTRS
Определяем типы ticket’ов. Точнее оставляем те, которые нам необходимы для внедрения указанных выше процессов, так как система уже имеет предопределенный набор настроек.
При желании можно определить очереди, например Аппаратное обеспечение, Печать, Программное обеспечение. К каждой очереди есть возможность настроить доступ агентов. Агенты — это сотрудники, которые выполняют работу по устранению инцидентов, как правило, это сотрудники ServiceDesk.
Для очередей должны быть определены календари, т.е. время доступности агентов, отвечающих за конкретную очередь, в соответствии с их графиком работы.
Настройки календаря производятся в модуле:
Core::Time::Calendar1
Таких календарей может быть назначено до 10 штук и для каждого можно указать часы работы агентов для каждого дня недели, ежегодные и разовые праздники и выходные дни. Время в соответствии с SLA будет учитывать доступность агентов.
Определяем Услуги (т.е. Каталог услуг) и соглашение об уровне услуг SLA.
Минимально достаточно одного SLA, в котором будут определены время первой реакции и время решения.
Заявки поступают через WEB-Interface, по телефону, через интерфейс агентов ИТ-отдела.
Не смотря на то, что в OTRS есть пользовательский интерфейс для работы с запросами, мы реализовали взаимодействие через внутренний сайт, который крутится на joomla, которая имеет плагин OTRS Gateway (в доме, который построил Джек). Плагин позволяет создавать заявки, и просматривать “свои”, ранее созданные запросы.
OTRS Gateway
Поступившая заявка получает состояние new. В агентском интерфейсе доступно время до первой реакции и до решения.
Факт начала работы с заявкой фиксируем ответом, созданном на основании шаблона
После чего заявка блокируется и она получает состояние open. В этот же момент пользователю отправляется сообщение о том, что заявка поступила на рассмотрение. Счетчик времени до первой реакции сбрасывается.
Запрос должен быть описан, при необходимости исправлены неверно введенные пользователем данные.
После решения переводим заявку в состояние pending auto close+.
Время ожидания устанавливается параметром:
$Self->{'Ticket::Frontend::PendingDiffTime'} = '14400'
В случае если от пользователя не поступит дополнений к запросу она будет переведена в состояние closed successfull. Да, может не совсем честно, но с другой стороны не будешь просить пользователя вынуждать дополнительно заходить в WEB-Interface и писать комментарии к выполненному запросу.
$Self->{Ticket::StateAfterPending} = {
'pending auto close+' => 'closed successful',
'pending auto close-' => 'closed unsuccessful'
За перевод состояний отвечает Unix-планировщик cron, в котором необходимо установить частоту обновления статусов меньшее чем, указанное по-умолчанию 2 часа:
check every 120 min the pending jobs
45 */2 * * * $HOME/bin/PendingJobs.pl >> /dev/null
Меняем параметр, в нашем случае установив время, равное 5 мин. При этом помним о производительности системы.
check every 5 min the pending jobs
*/5 * * * * $HOME/bin/PendingJobs.pl >> /dev/null
Для удобного отображения запросов в агентском интерфейсе выставляем параметр:
Core::Ticket::ViewableStateType,
оставив только состояния new и open, тем самым скрыв состояния ожидания в агентском интерфейсе.
Challenges
Описание запроса частично перекладываем на плечи пользователя, не раздувая при этом диалог описания, дабы не утомлять пользователя. В качестве обязательных полей указываем Сервис и Тип. Неправильно описанные запросы исправляем силами ServiceDesk.
Необходимо обязательно записывать все обращения пользователей, эту проблему решаем через мотивацию сотрудников Service Desk.
Отчетность
Отчетность формруется при помощи стандартного функционала при помощи мастера создания отчетов, например такие:
Среднее время реакции по исполнителям
Среднее время реакции по услугам
Среднее время решения по исполнителям
Среднее время решения по услугам
Количество запросов за отчетный период (месяц) по исполнителям
Количество запросов за отчетный период (месяц) по услугам
Процентное соотношение выполненных в соответствии с SLA запросов к общему числу запросов.
Отчетность по исполнителям необходима для оценки(мотивации) специалистов, вовлеченных в Эксплуатацию Услуг.
Отчетность по Услугам предоставляется заинтересованным лицам.
Кроме этого используются отчеты, полученные путем SQL запросов к базе данных и именно они являются основным показателем работы ИТ-службы:
Процент выполненных запросов в соответствии с SLA. (в нашем случае это 80%, стремимся к 90%)
Что дальше
Далее рассмотрим Problem Management, Service Catalogue Management, Change Management, Configuration Management и пр…
Можно сместиться как в сторону ITIL в целом, так и в сторону OTRS в частности.
Автор: vvhabr
