Инциденты и услуги — зачем эта разница

• «Боже, пользователь никогда не отличит инцидент от запроса на услугу! У него всегда все «не работает», и все!»

• «Мы замучаемся переквалифицировать неправильно указанные пользователями сервисы!»

• «Давайте вообще не будем у сервиса выделять элементы и услуги!»

И да, и нет.

Зачем нужна классификация заявок; почему чем раньше мы ее сделаем, тем лучше для всех; что мы предлагаем для того, чтобы сделать задачу ранней классификации заявок реальной — читайте в этом выпуске.

Зачем вообще классифицировать заявки?

У заявок есть два вида классификации: по типу (инцидент/запрос) и по сервису. Важна и та, и другая классификация, и вот почему:

• Без классификации по типу вы никогда не узнаете, а как на самом деле работает ваша служба поддержки и ИТ-сервисы в целом: правда ли, что все время все ломается, или у пользователей все время возникает куча «хотелок». Правда ли, что решение всех обращений в службу поддержки происходит неприлично долго, или же малейшие неработоспособности ИТ-сервисов всегда устраняются мгновенно, а вот предоставить дополнительное оборудование или ПО — действительно проблема.

• Без классификации по ИТ-сервису вы не сможете автоматизировать хотя бы частично функции 1-й линии поддержки — назначение заявки в нужную группу ответственных. Вы вынуждены будете держать штат операторов, которые должны будут так или иначе разбираться во всех ИТ-сервисах, чтобы разбираться, о чем идет речь в заявке пользователя и к какому сервису ее надо отнести.

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

Сокращение пути до требуемого специалиста — есть одно из немаловажных мероприятий на пути повышения эффективности работы вашей службы поддержки.

С общей идее классификацией понятно. Почему не убрать у ИТ-сервисов элементы и услуги?

Каталог ИТ-сервисов в ПО «ИнфраМенеджер» — это не просто справочник. Это ключевой элемент построения и автоматизации процессов поддержки. Это:

• возможность автоматизировать требования и облегчить заполнение разных форм заявок (для доступа к общим папкам одна форма; для предоставления дополнительной гарнитуры — другая);

• возможность автоматизации различных процедур обработки заявок (на новое рабочее место один перечень согласующих лиц и количество этапов работ, на видеоконференцсвязь — другой);

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

ИТ-сервис — это бизнес-возможность, которая обеспечивается определенными ИТ-активами и возможностями автоматизации бизнес-процессов. Например, автоматизированное рабочее место – это сервис. А вот стандартное оборудование или ПО – это компонент сервиса, за работоспособность/поддержку которых, вообще говоря, могут отвечать разные группы ИТ-специалистов. И с точки зрения задачи ускорения рассмотрения заявки достаточно компетентным ИТ-специалистом — категорически важно в рамках одного ИТ-сервиса выделять эти компоненты и при поступлении инцидентов по ним направлять их в разные группы.

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

Как светлое будущее сделать реальностью?

Что мы предлагаем нашим клиентам для того, чтобы облегчить внедрение ранней классификации заявок?

1. Типы заявок, определяемые вами для классификации, вы можете скрыть от пользователей (оставив пользователю только два варианта – инцидент или запрос). Необязательно пользователя нагружать дополнительной классификацией – достаточно у типа убрать свойство «Показывать в Web-интерфейсе».

2. Названия этих типов для пользователей вы можете переопределить. Назвав инцидент «Не работает», а запрос на услуги «Хочу» — в том же поле «Показывать в Web-интерфейсе».
   
   
   

3. При разработке вашего каталога ИТ-сервисов мы предлагаем отталкиваться от типового каталога, сформированного нами на основе 15-летнего опыта реализации проектов по автоматизации служб поддержки. Ибо, конечно, возможность классификации пользователем во многом зависит еще и от того, как сервисы сформулированы.
   
   
   

   
   
   

4. Пользователям при регистрации заявок системой предлагаются несколько вариантов облегчения классификации по каталогу сервисов:

   1. Поиск по ключевым словам в каталоге сервисов:
      
      

   2. Возможность использовать справочник кратких описаний (тем) заявок, которые уже связаны с элементом или услугой сервиса:
      
      

   3. Возможность повторно оформить заявку, аналогичную предыдущей:
      
      

   4. Отображение топ 10 последних использованных пользователем в заявке элементов/услуг сервисов:
      
      

   5. Возможность отобрать для себя избранные услуги из каталога сервисов и всегда видеть их «под рукой»:
      
      

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