Уже не один раз на наших курсах я сталкивалась с утверждением слушателей, которое произносилось как нечто совершенно очевидное: пользователь должен правильно выбрать тип своего обращения, например является ли оно инцидентом или запросом на обслуживание. Более того, такой подход время от времени встречается мне и в личной жизни при контакте с некоторыми поставщиками услуг: например, при обращении в поддержку одного фотоцентра висит предупреждение вроде: «Выберите тему обращения. Мы обязательно ответим на ваши вопросы, но только если они касаются указанной темы».
Так вот, когда я отлавливаю такое утверждение на курсе, мы обязательно останавливаемся и детально разбираем данный вопрос, причем иногда имеем очень жаркую дискуссию. Такие ситуации и подтолкнули меня написать эту заметку. Давайте разберемся, нужно ли заставлять пользователей разбираться в различиях между инцидентами, запросами на обслуживание, изменениями или нет.
Зачем мы вообще разделяем обращения на инциденты, запросы на обслуживание и изменения?
Чтобы ответить на основной вопрос, сначала стоит разобраться, зачем вообще существуют инциденты, запросы на обслуживание, изменения и другие сущности в ITSM. Часто на такой вопрос отвечают, что «так написано в ITIL и этого достаточно». Но в том же ITIL (да и других стандартах и сводах знаний) это написано не просто так.
Все эти объекты — объекты управления ИТ-организации. Мы выделяем их не для того, чтобы дать больше разнообразных названий тем или иным ситуациям, а потому, что разные ситуации требуют разных подходов к управлению: разных процессов обработки, исполнителей, правил приоритизации, сроков выполнения и показателей эффективности. Именно поэтому и появляются разные объекты управления.
Например, при обработке инцидента заранее не всегда известно, какие действия позволят быстрее восстановить работу сервиса, поэтому специалистам нередко приходится искать решение уже в ходе работы. Запросы на обслуживание, напротив, в большинстве случаев выполняются по заранее определенной последовательности шагов. Выполнение такого запроса уже согласовано в рамках SLA, тогда как изменение может потребовать дополнительной оценки, согласований и планирования сроков.
Если же для двух типов ситуаций применяются одинаковые правила управления, нет особого смысла выделять для них разные объекты управления.
Так что классификация объектов (в нашем случае, обращений пользователей) — это не самоцель и не дань терминологии. Это один из инструментов управления ИТ-услугами.
Кто определяет, как именно нужно классифицировать обращения?
Следующий вопрос, который возникает: а кто определяет, какой должна быть эта классификация? Ответ прост, но тем не менее иногда удивляет: сама организация.
Даже самые известные своды знаний не предлагают единственно правильную классификацию. Например, в ITIL v3 запросы на доступ и запросы на обслуживание были разными объектами, а начиная с ITIL 4 запросы на доступ стали разновидностью запросов на обслуживание, поскольку для них применяется схожая модель обработки.
Другой пример — инциденты. В ITIL выделяются инциденты и их особый класс — значительные (Major) инциденты, для которых предусмотрен отдельный порядок управления. А в недавно представленном процессе управления инцидентами РИТМ предлагается дополнительно использовать такой тип инцидентов, как «родительские» для работы с массовыми сбоями.
В других случаях организация может выделить отдельный класс инцидентов информационной безопасности или инцидентов, связанных с производственной инфраструктурой, если для них требуется особый порядок обработки.
Все эти варианты имеют право на существование, и отражают они выбранную модель управления. Организация сама определяет, какие объекты ей нужны, какие связи между ними существуют и как именно ими управлять.
Тогда при чем здесь пользователь?
Итак, вернемся к вопросу, с которого мы начали: нужно ли пользователю разбираться, является ли его обращение инцидентом, запросом на обслуживание, изменением или чем-то еще?
Если исходить из того, о чем мы говорили выше, ответ выглядит достаточно очевидным. Классификация нужна для того, чтобы поставщик услуг мог правильно организовать свою работу, а значит, именно поставщик услуг и должен определять, каким объектом управления станет конкретное обращение.
У пользователя же, обратившегося в ИТ, всегда есть потребность, связанная с выполнением его рабочих задач: возможно, у него что-то не работает, или ему нужен определённый функционал или, например, консультация (просто так он вряд ли будет обращаться).
Получается, самое главное для пользователя — иметь возможность высказать свою потребность так, чтобы она была реализована. А вот как именно эта потребность будет называться внутри ИТ-подразделения – инцидентом ли, запросом на обслуживание или изменением, не должно иметь для него значения. (Более того, попытка погрузить пользователей в специфические ИТ-термины часто выливается в их недовольство тем, как работает ИТ).
Это проявление одной их главных идей сервисного подхода: услуга предоставляется поставщиком для того, чтобы потребителю не приходилось понимать специфические внутренние механизмы данной деятельности. Если пользователю приходится изучать, чем инцидент отличается от запроса на обслуживание, значит, часть внутренней модели управления оказалась переложенной на пользователя.
Как сделать так, чтобы пользователю не пришлось выбирать?
И последнее, с чем нужно разобраться – это как реализовать работу так, чтобы пользователю вообще не приходилось выбирать тип обращения?
Современные ITSM/ESM-системы уже позволяют это сделать. Вместо того чтобы заставлять пользователя выбирать между инцидентом, запросом на обслуживание или изменением, они предлагают каталог запросов, понятный с точки зрения потребностей пользователя (например, подключить электронную почту, починить принтер и тому подобное). Пользователь выбирает нужный вариант или описывает свою проблему, а система на основании настроенных правил определяет, какой объект управления необходимо создать, какой маршрут обработки запустить, каких исполнителей назначить и какие сроки применить.
Конечно, никакая система не заменит методологию. Если организация сама не понимает, какие объекты управления ей нужны, чем они отличаются и в каких случаях должны использоваться, автоматизировать будет нечего. Но когда модель управления определена, современная ITSM/ESM-система позволяет скрыть эту сложность от пользователя, оставив ее внутри процессов поставщика услуг.
