8 шагов на пути к совершенствованию классификации инцидентов

Классификация инцидентов – один из самых важных и все же наименее внедренных аспектов ITIL, считает гость портала ITSM Watch Ханк Маркус из компании itSM Solutions.

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

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

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

Классификация

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

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

Самым простым и правильным выводом будет составлять ваши диагностические скрипты как можно более простыми и целенаправленными.

Чтобы совершенствовать классификацию, рассмотрите 8 следующих моментов:

Используйте диагностические скрипты.

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

Классифицируйте по configuration item (CI), не по симптомам.

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

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

Вместо этого, собирайте информацию (No.1 выше) и стройте решение по затронутому сервису, системе и т.п. Записывайте симптомы в поле для комментариев, но знайте, что разные пользователи видят различные симптомы в одном и том же инциденте. Классификация по симптомам есть скорее худшая, а далеко не лучшая классификация.

Классифицируйте инциденты, а не обращения.

Запись обращений (звонков) – это совершенно другой вид деятельности, отличный от классификации и первоначальной поддержки. В процессе регистрации обращений собираются данные, которые специалисты используют позже. Фиксируя информацию, сообщаемую пользователем по телефону, не пытайтесь осуществлять классификацию инцидентов.

Поступайте проще. Чаще пересматривайте все диагностические скрипты чтобы убедиться, что они не слишком сложные. Лучшее — враг хорошего. Слишком большое количество времени, затраченное на совершенный скрипт, может обернуться тем, что сотрудникам будет трудно выполнить такой «закрученный» скрипт за разумное время.

Используйте опции «прочее» или «неизвестное» в качестве диагностических кодов. Эти коды являются показателем того, что ваши скрипты надо усовершенствовать.

Используйте сервис-каталог.

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

Используйте свои инструменты.

Большинство из доступных сегодня средств программного обеспечения предоставляют по-настоящему хорошо внедренные характеристики классификации инцидентов, но вам надо их использовать! Проверьте возможность ваших систем и по возможности используйте их. Не забывайте о подсказке № 4.

Принимайте в расчет зрелость.

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

Определите область действия процессов.

Очень важно понимать, что не каждое отдельно происходящее событие есть основание для инцидента. Легко ошибиться, установив область действия слишком широко или слишком узко. Установите слишком широко — и любая нормальная автоматизированная система может стать инцидентом и будет занимать ваши ресурсы и системы. Сузите область действия — и вы не будете предоставлять требуемое качество.

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

Простая схема классификации

Как я уже отмечал, единицы конфигурации (CI) должны быть положены в основание для классификации инцидентов. Есть два основных доступных метода: вы можете классифицировать инциденты на основании вышедшей из строя системы или сервиса (например, “электронная почта”); или вы можете классифицировать по единице физической конфигурации (например, “рабочая станция”).

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

Независимо от того, классифицируете ли вы по сервису или по единице конфигурации, вам следует включить в скрипт по крайней мере три поля: Тип, Категория и Под-категория.

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

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

Если вы собираетесь строить систему на основании классификации физических CI, тогда простой список ITIL CI работает хорошо. ITIL описывает следующие категории: Оборудование, Программное обеспечение, Сеть, Люди, Процесс, Размещение и Документация.

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

• Оборудование: Рабочая станция, принтер, монитор, телефон, и т.п. • Программное обеспечение: Ввод заказов, АСУТП, и т.п. • Размещение: Переезды, Добавления, Изменения, и т.п.

Такая система классификации выглядит таким образом:

• Тип: Ошибка • Категория: Программное обеспечение • Под-категория: База данных • Примечание: Пользователь информирует об «SQL error» когда ищет информацию по заказчику «H.Marquis».

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

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

Экономический эффект

Простая, и все же эффективная система классификации достаточно выгодна. Она может помочь совершать следующее:

• Быстро обнаруживать совокупные обстоятельства и определять инцидент. • Правильно направлять инцидент в соответствующую группу поддержки. • Ускорять диагностику путем сбора верной информации. • Помогать формировать и управлять знаниями • Повышать эффективность технических групп. • Повышать удовлетворенность заказчиков • Повышать производительность пользователей • Внедрять сильное основание для инициативных действий

В заключение, следует отметить, что экономический эффект превышает усилия, затраченные на внедрение процессов.

Hank Marquis is a managing partner and CTO at itSM Solutions, an ITSM education and mentoring company.

Hank Marquis, 7 сентября 2006. Перевод Виталия Фролова.
URL: http://www.itsmwatch.com/itil/article.php/3630846

Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.