Что такое управление запросами на обслуживание и как его наладить

Зачем управление запросами на обслуживание

Запрос на обслуживаниеЗапрос на обслуживаниеШтатное обращение пользователя: доступ, оборудование, консультация. Сбоя здесь нет.ITIL 4, практическое руководство по управлению запросами на обслуживание (Service Request Management) — это обращение пользователя за тем, что провайдер и так обязан давать: доступ, оборудование, информация, стандартная услуга из каталога. Ничего не сломано. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 существует ради одного: выдавать заведомо согласованное быстро, предсказуемо и без переговоров каждый раз заново.

Формулировка ITIL прямая: назначение процесса — вести все запросы на обслуживание через их жизненный цикл, а задача — обрабатывать их результативно и профессионально, обеспечивая простой способ заказать стандартную услугуУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation и получая необходимые согласования до выполнения 1.

Отсюда главное отличие от соседней практики. INCУправление инцидентами возвращает то, что сломалось; здесь ничего не ломалось — пользователю нужно то, что положено. ITIL формулирует это разделение жёстко: инцидентыИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами и запросы — работа разной природы, и целевые сроки у них разные 1.

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

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

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

Когда практика работает

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

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

Одинаковые запросы идут одинаково. Как проверить: для массовых типов записаны модели — шаги, согласования, срок. Организация, где два одинаковых запроса прошли разными путями за разное время, ведёт не практику, а переписку.

Согласование встроено, а не приделано сбоку. Как проверить: известно, какие типы требуют согласования и чьего, и это выполняется системой, а не письмом руководителю. ITIL прямо называет получение необходимых согласований частью назначения процесса 1.

Что входит и что рядом

Граница этой практики — самое спорное место в эксплуатации, и провести её надо явно.

Почему эту границу приходится проводить каждый раз

Часть организаций сознательно заводит запросы как разновидность инцидента и обрабатывает их одним процессом. Так делают, и это создаёт трудности в отчётности 1. При большом потоке запросов их выгоднее вести отдельным типом записи, чтобы не путать с инцидентами 1.

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

Что на входе и что на выходе

Отсюда два условия для запуска. Практика работает только там, где уже есть перечень заказываемого: без него неоткуда взять, что именно человек имеет право попросить. Второе условие — понятные права: кто и что может заказывать, и чьё согласование для этого нужно.

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

Как это работает

Практика раскладывается на семь шагов. Первые три занимают минуты, четвёртый — почти всё время.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение работа с людьми и сторонами

Четыре места стоит объяснить отдельно — на них практика чаще всего ломается.

Шаги приёма стоит смотреть и в MOF 4.0: там регистрация обращения разложена подробно — сначала контактные данные заявителя, затем сведения о самом запросе, затем категоризация и проверка того, поддерживается ли предмет обращения вообще 2. Последний шаг у нас обычно пропускают, а он отсекает запросы про то, что провайдер не обслуживает.

Модель запроса покрывает четыре стороны, а не только шаги. Руководство описывает её как повторяемый заранее описанный подход к запросам одного типа. В модели должны быть 6:

• порядок работ — с вариантами и решениями на развилках;
• роли и команды;
• автоматика и средства;
• участие третьих сторон и договорённости с ними.

Модели создают при проектировании услуги, и в работу они выходят вместе с ней, а не дописываются потом 6.

Модель запроса — это не инструкция, а договорённость. Определена она как повторяемый способ обработки конкретной категории запросов с заранее согласованными шагами; модели бывают простыми, без согласования, — например, сброс пароля, — и сложными, с несколькими согласованиями 1. ЦенностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation модели в том, что она фиксирует срок: заранее известно, сколько это занимает.

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

Подтверждает получатель, а не исполнитель. Запрос закрывается, когда заявитель подтвердил, что получил заказанное. Практика, где исполнитель сам ставит «выполнено», меряет собственную уверенность.

Запрос и что с ним путают

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

Запрос и инцидент. Запрос — за тем, что положено; инцидент — о том, что сломалось 1. Тест простой: если бы услуга работала штатно, обращение всё равно было бы? Да — запрос.

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

Запрос и обращение за информацией. Вопрос «как мне сделать» — тоже запрос, и на него отвечает практика 1. Но если такие вопросы повторяются, ответ переносится в базу знанийБаза знанийСобрание проверенных решений и инструкций, которыми пользуются при разборе обращений.Разбор практики управления инцидентами на портале: практика KNWУправление знаниями дешевле, чем ответ человека на один и тот же вопрос сто раз.

Запрос, событие и инцидент — по одной и той же работе. Руководство разбирает это на принтере 6. Пользователь заметил, что кончается тонер, и попросил заменить — это запрос. Принтер сам сообщил о низком уровне тонера, и техник поехал менять — это событие. Никто не заметил вовремя, печать встала, люди позвонили — это инцидент. Техническая работа во всех трёх случаях одна: заменить картридж. Разными их делают то, кто заметил и что при этом почувствовал пользователь.

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

Каталог, витрина и права

Практика опирается на три опоры, которых у неё самой нет.

Перечень заказываемого. То, что пользователь видит и может выбрать. Ведёт его практика SCMУправление каталогом услуг; здесь важно одно: в перечне должно быть только то, что действительно выдаётся, и с честным сроком.

Права. Кому что положено — по должности, подразделению, проекту. Без этого проверка права превращается в вопрос «а можно?», который задают руководителю.

Что показывает витрина. ITIL называет её видом каталога услуг со стороны пользователя. По каждому запросу видно: к какой услуге он относится, при каких условиях его можно подать, какие сведения нужны, кто согласует и за какой срок его выполнят 6. Витрина показывается с оглядкой на соглашение, которое действует для этого пользователя, — то есть сроки в ней настоящие, а не средние по компании 6.

Витрина самообслуживания. Практика очень хорошо подходит для самообслуживания: понятный интерфейс с готовыми полями лучше, чем оператор, вручную выясняющий, что человеку нужно 1. Здесь же лежит и главный выигрыш по деньгам.

Сроки и приоритет

Срок запроса задаётся моделью, а не приоритетомПриоритизацияВыбор задач, которыми займутся первыми, когда ресурсов не хватает на все.ITIL 4, практическое руководство по управлению инцидентами по влиянию. Это отличает практику от INCУправление инцидентами: там срок считается от того, насколько сильно мешает сбой, здесь — от того, сколько объективно занимает выполнение.

Того же требует и FitSM: инциденты и запросы регистрируются, классифицируются и приоритизируются единообразно, с учётом целевых показателей из соглашений; эскалация и закрытие тоже выполняются единообразно 3.

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

Кто участвует

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

Что должно быть в записи

Минимальный состав, без которого запись бесполезна для отчётности:

• кто заявитель и от чьего имени подан запрос;
• тип запроса и применённая модель;
• отметки времени: подача, согласование, выполнение, подтверждение;
• кто согласовал — с датой;
• что именно выдано, включая инвентарные и лицензионные признаки;
• канал подачи: витрина, почта, звонок.

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

Чем автоматизируется

Три уровня, и они окупаются по-разному.

Витрина с формами. Даёт структурированные данные и снимает половину уточняющих вопросов. Окупается почти всегда.

Маршрутизация и согласования. Модель запроса выполняется системой: сама отправляет на согласование, сама передаёт исполнителю, сама считает срок.

Автоматическое выполнение. Сброс пароля, доступ к папке, выдача типовой лицензии — без человека вообще. Здесь и лежит основная экономия, но требует зрелых прав и учёта.

Проверять эффект стоит по одному числу: доля запросов, закрытых без участия человека.

Как измерять

Шесть показателей, которых достаточно для управления практикой.

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

Половина показателей меряет не выполнение, а сам порядок. ITIL 4 привязывает показатели к двум факторам успеха. Первый — «порядок выполнения запросов по всем услугам оптимален» 6. Держится он на пяти опорах:

• полнота каталога запросов и число запросов, для которых порядка выполнения нет вовсе;
• число запросов, которые не удалось выполнить по согласованному порядку из-за ошибок в нём;
• удовлетворённость самих исполнителей выданными им инструкциями;
• среднее время и стоимость выполнения по типам и моделям;
• доля запросов с полностью или в основном автоматизированным выполнением — в штуках, в доле каталога, в доле общего числа и по времени выполнения 6.

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

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

• доля запросов, выполненных в срок по соглашению об уровне услуг;
• последствия инцидентов, которые случились из-за неправильного выполнения запроса;
• удовлетворённость пользователя;
• доля запросов, выполненных в обход согласованного порядка 6.

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

Зрелость управления запросами

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Запросы ведут как инциденты. Один процесс, один срок, общая отчётность. Есть прямое предупреждение о трудностях с отчётностью при таком выборе 1.

Каталог пишут от систем, а не от нужд. «Заявка на изменение прав в системе учёта» вместо «доступ к отчётам по продажам». Пользователь не находит нужное и звонит — самообслуживание не взлетает.

Согласование не описано. Каждый запрос требует индивидуального выяснения, кто должен одобрить. Срок раздувается ожиданием, а не работой.

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

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

Закрывают без подтверждения. Исполнитель отмечает выполнение, пользователь узнаёт об этом из письма о закрытии. Повторные обращения по тому же поводу растут, а в отчётности всё хорошо.

Что говорят своды

Практика есть у всех сводов управления услугами, но границы они проводят по-разному, и это стоит знать до того, как ссылаться.

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит запрос отдельным процессом и настаивает на разделении с инцидентами 1. В текущей редакции у практики своё руководство: выполнение запросов там прямо связано со стандартными изменениями, а сами запросы предписано стандартизовать и автоматизировать настолько, насколько получится 6.

FitSM объединяет их в один процесс с общими требованиями к регистрации, классификации, эскалацииЭскалацияПередача инцидента тем, у кого больше компетенции, либо уведомление руководителя об угрозе срока.Разбор практики управления инцидентами на портале и закрытию 3. Для небольшой службы это осознанное упрощение.

COBIT сводит их в одну цель управления — обработку запросов и инцидентов 4.

USM, метод пяти процессов, идёт дальше: любое обращение — вызов, а тип выясняется по ходу; сначала принимаем и расставляем приоритет, потом разбираемся 5.

Вывод для практики: если в вашей организации потока запросов мало, объединение с инцидентами — законный выбор, и на него можно сослаться. Если поток большой, разделение окупается на первой же отчётности.

Где описано

Первоисточники, по которым написан этот разбор, с указанием доступности.

Что почитать дальше

Три соседние практики, без которых эта не работает: SDKСлужба поддержки — кто принимает и ведёт запрос, SCMУправление каталогом услуг — что вообще можно заказать, INCУправление инцидентами — что делать, когда обращение оказалось не запросом.