SERVICE DESK. СИСТЕМА АНАЛИЗА КАЧЕСТВА РАБОТЫ IT СЕРВИСОВ

Введение

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

Одну из главных ролей играет поддержка пользователей. Сейчас существует большое количество стандартов, которые рекомендуют, как правильно выстраивать процесс управления. Стандарт де – факто в области IT, который явным способом нашел применение в России – это ITIL (IT Infrastructure Library). Он описывает такие процессы, как управление проблемами, управление услугами, управление инцидентами, управление конфигурациями, и другие. Одной из главных идей, которые описаны в ITIL является организация системы Service Desk [1].

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

Основная часть

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

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

Для общей ясности представим ниже рисунок 1 и небольшое пояснение, которые кратко объясняют суть работы Service Desk, кто с ней не знаком:

Рисунок 1. Схема работы системы.

Учитывая все рекомендации методологии ITIL, существует три уровня сложности данного типа системы [3]:

1. «CallCenter»

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

2. «HelpDesk»

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

3. «ServiceDesk»

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

Для того чтобы система работала и приносила реально полезный эффект, для нее нужно прописать реальные нормы качества (SLA).  В соответствии с рекомендациями ITIL, SLA – это основной документ, регламентирующий взаимоотношения IT и клиентов. Цель документа – дать качественное и количественное описание сервисов, как с точки зрения провайдера, так и с точки зрения пользователя [4]. Составление SLA можно подразделить на несколько пунктов, а именно [2]:

1. Сгруппировать пользователей, начиная с 2,3 групп:
2. Установить реальные нормы качества для SLA, с учетом возможностей и целевые показатели (пример):

Решение Инцидента по телефону (тут же) – 85%. Перенаправление звонков на 2 линию – 90%. Перенаправление звонков на 3 линию – 98%;

Поступившие заявки для решения Инцидента по электронной почте – максимальный срок решения 2 дня (когда Инцидент решается через телефонный звонок);

И т.д.

3. Зафиксировать SLA;

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

4. Спланировать внедрение Service Desk;
5. Определить критические IT сервисы;
6. Проинформировать всех без исключения пользователей;
7. Постоянно измерять соблюдения SLA по выбранным параметрам качества;
8. Постоянно анализировать и оптимизировать процессы в Service Desk до достижения целевых показателей.

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

1. Общее количество заявок на устранение инцидента;
2. Количество просроченных заявок на устранение Инцидента (в связи со сбоем в системе Service Desk);
3. Количество заявок выполненных в срок;
4. Время устранения Инцидентов;
5. Количество поступивших заявок на устранение Инцидента одного характера;
6. Процент решенных Инцидентов с 1 раза.
7. И многие другие.

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

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

Во – вторых, повторяемость инцидентов. Если задача на их устранение поступала больше 1/2 раз, значит, ее можно классифицировать.

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

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

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

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

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

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

1. Алехин З. Service Desk – цели, возможности, реализации// Открытые системы. – 2001. – № 05 – 06. [электронный ресурс] – Режим доступа. – URL: http://www.osp.ru/os/2001/05-06/180183/ (дата обращения 02.01.2017)
2. Белошицкая Е.В. Внедрение ITIL процессов на предприятии малого и среднего ИТ – бизнеса средствами «1C: ITIL Управление информационными технологиями»: образовательное проект //Московский государственный университет экономики, статистики и информатики. – Ярославль, – 12 с.
3. Service Desk: плюсы явные и скрытые [электронный ресурс] – Режим доступа. – URL: http://www.itexpert.ru/rus/ITEMS/77-20/, (дата обращения 03.01.2017)
4. SLA – Service Level Agreement: Соглашение об уровне качества [электронный ресурс] – Режим доступа. – URL: http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:SLA_-_Service_Level_Agreement_(%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%
   
   D0%BE%D0%B1_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B5_%D0%BA%D0%B0%
   
   D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0), (дата обращения 06.01.2017)