Раздел: ITIL и прочее

Организация Service-Desk

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

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

Для начала, разберёмся с наиболее общими определениями.

Сервис - это ИТ-услуга, предоставляемая одному или нескольким Заказчикам Поставщиком ИТ-услуг.

Сам по себе Сервис не однороден, он почти всегда базируется на других ИТ-Сервисах. Например, доступ в Интернет — это Сервис, который содержит в себе(ну, или использует) и сеть (LAN) компании, и сетевое оборудование, и сервера и, уж конечно, компьютер, который тоже является Сервисом. Однако, все эти промежуточные, инфраструктурные сервисы, Заказчика мало интересуют. Их интересуют Сервисы как конечные услуги.

Техподдержка (поддержка IT-Сервисов) тоже является Сервисом.

Поставщиком Сервисов, как правило, является ИТ-Департамент.

Заказчиком Сервисов являются любые другие (не-IT)  отделы внутри компании, которые потребляют Сервисы.

SLA (Service Level Agerrment, Соглашение об уровне обслуживания) — Соглашение между Поставщиком IT-услуг и Заказчиком. Этот документ описывает Сервис, документирует Целевые показатели уровня услуги, указывает зоны ответственности сторон: Поставщика ИТ-услуг и Заказчика.

Service Desk — Отдел, или Служба, которая является единой точкой контакта для Заказчика по поводу обслуживания предоставляемых Сервисов и обслуживающая эти Сервисы, на основе достигнутых с Заказчиком договорённостей.

Основные задачи Службы Service-Desk:

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

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

Виды службы Service-Desk:

  • Call-Center

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

  • Help-Desk

В этом виде организации службы поддержки «первая линия» осуществляет не только приём и распределение обращений, но и непосредственно участвует в их разрешении. Считается, что на первой линии должно разрешаться 70%-80% обращений. Как правило, сотрудник первой линии в данном случае — специалист широкого профиля.

  • Service-Desk

Этот вид поддержки представляет собой интегральный подход — все специалисты работают «в одну линию».

Второе.

Чтобы в дальнейшем формализовать, какие именно Сервисы и с какими параметрами предоставляет Поставщик (IT-Департамент), необходимо выявить Список сервисов (Service catalogue, Сервисный каталог), которые  (IT-департамент) готовы предоставлять. В условиях полной неопределённости, эту задачу логично разбить на две подзадачи. Первая — Описать IT-Инфраструктуру. То есть, составить карту-схему сети, которая будет содержать информацию о сетевом оборудовании, серверах, и основных свойствах этих серверов. Вторая — понять, для кого именно существует тот или иной сервер, какие функции он выполняет, кто использует его ресурсы.

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

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

Сервисы можно представить в виде таблицы.

Стоит прояснить, что Сервис — это то, что потребляет Заказчик в конечном итоге. Например — Почта, принтеры. Техподдержка — тоже сервис.

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

Значение параметра — это конкретная цифра-показатель вышеозвученного параметра.

Таким образом, Сервисный каталог должен представлять собой «Меню» имеющихся и потребляемых сервисов, и набор их текущих, и так же возможных параметров их потребления.

Третье.

Необходим согласованный SLA (Соглашение об уровне обслуживания). Заказчиком Сервисов могут являться бизнес-отделы, которые продают Клиентам готовые решения (продукты или услуги) на основе этих сервисов. В этом случае, Заказчику особенно необходимо понимание использования IT-средств, представленных в виде сервисов, и гарантии их поддержания на определённом уровне.

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

Сам SLA должен содержать потребляемые Сервисы и их требуемые Заказчиком параметры (то есть, конкретный выбор сервисов и их параметров из «меню» Сервисного каталога). Если в компании всего одно подразделение-Заказчик, то SLA будет один. Если подразделений, использующих сервисы, больше, то количество соглашений будет зависеть от разницы в качестве потребления сервисов. Например, если в компании помимо IT — ещё пять отделов, но все они в равной мере потребляют одни и те же сервисы (Почта, Интернет, Компьютеры и Принтеры), и требуют от этих сервисов одного и того же качества, то есть — значения параметров этих сервисов (Доступность интернета и почты, сроки починки компьютеров и принтеров), достаточно будет одного SLA, согласованного со всеми руководителями подразделений (иили Генеральным директором). Если же по объективным причинам разные отделы будут требовать разных сервисов иили разного уровня предоставления этих сервисов, в таком случае понадобится составлять отдельные SLA.

Четвёртое. Инструментарий. Необходимо выбрать соответствующее ПО, на основе которого будет работать служба Service-Desk (тикетная система) и ПО, которым будет осуществляться мониторинг всех параметров по SLA. В идеале, это должен быть либо единый программный комплекс (как, например, семейство продуктов Microsoft System Center, включающее в себя Service Manager для организации ServiceDesk) либо интегрированные между собой программы, позволяющие фиксировать все параметры сервисов, оговоренные в SLA и обрабатывать заявки, поступающие в Service Desk. Связь между программами такого рода необходима для генерирования общей статистики по параметрам сервисов. Например, в SLA могут быть оговорены такие параметры как: количество сбоев и время неработоспособности сервера, среднее время реакции на обращение в Service Desk. Как правило, отдельно взятые системы мониторинга не включают в себя функционал обработки заявок, но их можно запрограммировать на автоматическое инициирование создания задач в системах обработки заявок, а саму систему обработки заявок — на назначение задач соответствующим специалистам при возникновении определённого сбоя или порогового значения какого-либо параметра.

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

——

Небольшое послесловие.
К изучению:

http://www.itil.org/
http://www.itil.org.uk/
http://www.itil-officialsite.com/
http://www.itilfoundations.com/
http://www.pinkelephant.com/

Комментировать

Комментарии

семнадцать + восемь =

  1. Добрый день!
    Меня интересует организация техподдержки!
    Вы рекомендуете использовать именно microsoft service manager для этих целей? Он легко настраивается?

  2. Здравствуйте, Виктор.
    Техподдержка может быть разной.
    Если вы используете или планируете использовать System center, то, конечно же, идеально будет использовать Service manager. В основном этот программный комплекс применяется для внутренней техподдержки в компании с большим количеством пользователей. Учтите, что сам по себе, Service manager изначально не особо гибкий, и его необходимо допиливать.
    Из бесплатных могу посоветовать OTRS, написана на перле, открытая, подходит для ITIL, гибкая в настройке.