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

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

Увы! Далеко не всегда, даже когда есть единая точка контакта счастье наступает быстро и безоговорочно. (Скромно молчу про остальные случаи). Жизнь вносит свои коррективы, выражающиеся порой в довольно забавных казусах. Рассмотрим типичные ситуации для внутренней поддержки:

• "Уход от ответственности". Ситуация встречается, когда служба helpdesk, в силу тех или иных причин (ограниченность бюджета, времени, денег, ресурсов, компетенции) не имеет возможности выполнить SLA. При этом не секрет, что часто мотивация сотрудников helpdesk зависит от скорости выполнения заявок, и прочих количественных факторов (Как это ни странно, но на качественные факторы мало когда обращают внимание). Таким образом, в особо (технологически) сложных случаях, для того, чтобы не портить статистику, сотруднику helpdesk проще закрыть заявку с приемлемой причиной (например, "не предоставлены все требуемые данные"), чем разбираться с конкретной проблемой. И это явление порождает следующую ситуацию:
• "Излишняя формализация". Helpdesk, как инструмент поддержки пользователя, при фиксации и первичной классификации обращения, основывается на информации, предоставленной пользователем. Часто для сбора информации применяют автоматизированный механизм "опросных листов" или самостоятельного заполнения форм пользователем. Чрезмерная формализация этой процедуры позволяет (на вполне законных основаниях) закрыть обращение в случае малейшей ошибки в данных, предоставленных пользователем.
• "SLA в голове". Ситуация, при которой формально SLA есть, но фактически в качестве SLA используются произвольные величины, находящиеся в умах одного-двух сотрудников Helpdesk'a. Вариант: SLA вообще не прописаны, а служба поддержки работает "по понятиям", то есть SLA изменяется от обращения к обращению, или вообще может зависеть от отношения конкретного сотрудника Helpdesk к конкретному пользователю.
• "Размывание зоны ответственности". В этом случае в SLA фиксируются наиболее типовые сервисы, а обращения по нетиповым сервисам игнорируются либо "запускаются по кругу", превращая процесс в классический "футбол заявки". Как вариант, SLA по нетиповым сервисам составляется таким образом, чтобы сотрудник Helpdesk всегда имел возможность закрыть его на основании какой-либо формальной причины. (см. пункт "излишняя формализация")
• Helpdesk представляет собой одновременно первую, вторую, третью и т.д. линии поддержки. Подобная организация сводит на нет преимущества организации многоуровневой поддержки, так как в рамках подобного универсального подразделения будут находиться специалисты разного уровня, и, как следствие, запросы по одному и тому же сервису, в рамках одного SLA, будут выполняться с разной скоростью и различным качеством.

Можно возразить, что в любом Helpdesk'e на одной линии работают специалисты разного уровня. :) Так-то, оно, конечно, так, но уровень их компетенции колеблется у некого среднего уровня, и вряд ли на Helpdesk пойдет работать человек с компетенцией сетевого администратора...

• Helpdesk представляет собой "центр защиты специалистов", то есть низкоквалифицированных сотрудников, которые всеми возможным средствами пытаются не допустить общение пользователя со второй линией поддержки, и, в меру своей квалификации, решать все поступающие к ним инциденты. Обычно подобная картина перерождается в излишнюю формализацию, поскольку задача первой линии в этом случае - найти формальный повод не выполнять требуемых работ. На практике такая картина часто возникает из-за того, что неверно трактуется описанная в ITIL организация службы поддержки.
• "Полный бардак". Helpdesk не организован, но декларируется "жизнь по ITIL". Учет заявок не ведется, или половина заявок проходит вне системы учета. Формально SLA определены, но фактически об этом никто не знает. И все счастливы... (Клинический случай?)

К чему это я? Да к тому, что формально внедрив "что-то из ITIL", организовав Helpdesk, радоваться и расслабляться рано - проблемы будут, только другого порядка, возможно, решаемые более просто - по отношению к тем, которые присутствуют в ситуации, когда Helpdesk'a нет, как класса, а ITIL является магической аббревиатурой...

Кросспост из моего ИТшного блога на ITBlogs.ru