Service Desk (служба поддержки): что это, роли и чем отличается от первой линии

Что такое service desk и зачем он нужен

Служба поддержки, или service deskСлужба поддержки (service desk)Единая точка контакта между теми, кто пользуется ИТ-услугами, и теми, кто их предоставляет: сюда приходит обращение и здесь оно должно быть зафиксировано.ITIL 4, практическое руководство Service Desk; MOF 4.0, — то место, куда человек идёт, когда с ИТ что-то не так. Через неё проходит всё, с чем приходят: сломалось, нужен доступ, непонятно, как работает, хочу пожаловаться. ITIL и MOF называют её единой точкой контакта между теми, кто пользуется ИТ-услугамиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation, и теми, кто их предоставляет; в русских компаниях говорят проще — сервис-деск. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 существует ради одного: чтобы обращение дошло, было записано и человек понимал, что будет дальше.

ITIL ставит перед практикой две цели сразу. Первая — собрать в одном месте весь спрос: и просьбы починить сломавшееся, и заказы на то, что человеку положено. Вторая — быть для пользователя входом к поставщику услуг, причём единственным 1. MOF говорит то же короче: служба поддержки — точка входа для пользователей, которые хотят обратиться в ИТ со своими вопросами и проблемами 2.

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

Служба поддержки отвечает за то, чтобы обращение дошло. За то, чтобы оно решилось, отвечают INCУправление инцидентами и REQУправление запросами на обслуживание.

Словосочетанием «служба поддержки», как и английским service desk, называют при этом сразу четыре предмета, и добрая половина споров на внедрении — от того, что участники имеют в виду разное. Служба поддержки — это и команда людей, и работа, которую они делают, и программа, в которой живут обращения, и подрядчик, которому приём обращений отдали целиком 1.

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

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

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

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

Человек знает, куда обращаться, и находит это быстро. Как проверить: единый номер, единый адрес почты и единая страница на портале известны без поиска. Когда контакты найти трудно, люди начинают звонить знакомым в ИТ — и дорогой специалист занимается работой первой линии 3.

Записывается всё, включая короткие консультации и звонки не по адресу. Как проверить: по любому обращению есть запись, а не память сотрудника. «Свободный ITIL» формулирует это правилом «сначала регистрируем — потом решаем» 5.

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

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

Команда, работа, программа, подрядчик — что именно имеют в виду

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

Работа — то, чем эта команда занимается в общении: каналы, приём, маршрутизация, информирование. Это и есть практика, о которой идёт речь на странице.

Программа — система, где живут заявки. Её тоже называют службой поддержки, а чаще системой service desk, отчего разговор «нам нужен сервис-деск» может означать и покупку программы, и наём людей, и постановку процесса.

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

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

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

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

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

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

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

Обработка обращения у ITIL состоит из трёх шагов: принять и записать, проверить, распределить 1. MOF ту же работу расписывает подробнее — семью шагами, от регистрации контактов до контроля качества 2. В таблице ниже оба разбора сведены в один порядок: так обращение и правда идёт в системе.

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

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

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

Приоритет назначается по правилу, а не по громкости. Само правило приоритета живёт в INCУправление инцидентами и SLMУправление уровнем услуг, служба поддержки его применяет. Организация, где приоритет ставится по тону разговора, получает очередь, отсортированную по настойчивости.

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

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

Как писать массовое оповещение, чтобы его прочли

Сообщение «WEBAPPS_SRV01 уходит на обновление ядра в субботу ночью» пользователю не говорит ничего. Человеческий вариант из практического руководства Service Desk устроен иначе: в выходные идут работы над системами, интернет-банк не работает с шести вечера субботы до полудня воскресенья, мобильное приложение работает как обычно, и за терпение благодарят 1.

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

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

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

Service desk, help desk и колл-центр

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

Колл-центр, help desk и service desk. Между ними «Свободный ITIL» ставит три ступени, и у каждой своё английское имя — то самое, которое вы встретите в объявлениях о работе 5.

Слова путают постоянно, а объём работы за ними разный, и от него зависит, сколько людей нужно и сколько это стоит. Отличается и главный вопрос: колл-центр меряется временем ответа и длительностью разговора, а у service desk спрашивают другое — дошло ли обращение до того, кто может помочь, и получил ли человек ответ.

Служба поддержки и сопровождение заказчика. Общение с руководством заказчика, обсуждение планов и претензий — работа RELУправление отношениями. Служба поддержки общается с пользователями 1.

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

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

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

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

Местная. Служба сидит там же, где пользователи. Люди приходят ногами, ИТ узнаёт новости первым. Слабое место — привязка к конкретным сотрудникам: обращения идут не в очередь, а «к Диме», и с уходом Димы поддержка обваливается 1. Есть и второе: там, где всё на виду, обращения перестают заносить в систему — и так ведь всем всё известно 1.

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

Виртуальная. Операторы физически не сидят рядом с пользователями: они могут работать хоть из дома, а человек видит один вход. Так устроена поддержка у поставщиков массовых услуг — интернет-провайдеров, разработчиков программ для широкой публики. Личных встреч не бывает вовсе, и вместо них нужны хорошие каналы связи: вкладываться в них придётся постоянно 1. Взамен на оператора меньше давят — между ним и раздражённым человеком стоит экран, и разговор идёт размереннее. И обращение обходится дешевле: в переписке и чате один сотрудник ведёт несколько разговоров сразу, чего телефон не позволяет 1.

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

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

Здесь стоит быть внимательным к словам. «Свободный ITIL» виртуальной службой называет как раз круглосуточную — несколько местных служб, сшитых одной системой и общими правилами 5. У ITIL 4 виртуальная — это служба без живого контакта с пользователем, и часовые пояса тут ни при чём 1. Встретив это название, уточняйте, что за ним стоит.

Отдельное предупреждение из практики: перенос поддержки в регионы подешевле у нескольких крупных организаций дал экономию и резкое падение удовлетворённости — вплоть до ухода заказчиков к конкурентам 3.

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

Сколько людей нужно

Единой методики нет — так и написано в руководстве ITIL 1. И это честно: нагрузка зависит от того, сколько людей обслуживается, насколько сложны услуги и что служба делает сверх приёма обращений.

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

В обратную сторону штат сокращает автоматизация: учебное руководство прежней редакции ставит её вместе с уровнем самообслуживания — сброс пароля и прочие типовые запросы — в один ряд с числом пользователей и сложностью инфраструктуры 3. Чем больше таких обращений закрывается без человека, тем меньше людей нужно держать на линии.

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

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

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

Почему доля решённых на первой линии — плохая единственная цель

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

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

Каналы и удобство

Каналов у службы обычно несколько, и главное свойство набора — связность. Удобство отдельного канала ITIL раскладывает на восемь признаков 1. Это доступность; доверие — канал настоящий, защищённый и не нарушает правил; возможность обратиться в нужное время и из нужного места; знание контекста; эмоциональная составляющая; привычность; встроенность в остальные системы; понятность.

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

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

Отсюда и вес практики. У ITIL для этого есть название — момент истины: любой эпизод, в котором человек соприкасается с организацией и составляет мнение о качестве её работы 1. Разговор с service desk — ровно такой эпизод, и он влияет на общее впечатление сильнее, чем доля этой работы во всей поддержке. Оговорка тут же, и её стоит помнить при разборе опросов: удовлетворённость складывается из многого, и качество самих услуг обычно весит в ней больше, чем удобство общения 1.

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

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

В таблице нет ещё одной фигуры, которая встречается почти везде, — продвинутого пользователя. Это сотрудник того же подразделения, которого обучили чуть глубже остальных: он подсказывает соседям по мелочи, разбирается в их работе лучше любого оператора и заодно снимает со службы часть простых вопросов 3. Условий два. Первое: даже когда вопрос решил он, обращение всё равно заводится в системе — иначе поток снова известен наполовину 3. Второе: роль надо описать и договориться с его руководителем о времени на неё, а без этого желающих не найдётся 3. «Свободный ITIL» добавляет про мотивацию: чаще всего хватает выросшего авторитета среди коллег 5.

Что должно быть в заявке

Два слова тут легко спутать. Обращение — то, с чем человек пришёл: звонок, письмо, сообщение в чате. Заявка — запись об этом обращении в системе: у неё есть номер, исполнитель и срок. Одно обращение обычно даёт одну заявку; когда это не так, в учёте непорядок, и у Брукса на такой случай заведён отдельный показатель — о нём ниже, в разделе про измерения. В программах её нередко зовут тикетом, а в отчётах — запросом: предмет один, слова разные.

Минимум, без которого заявка бесполезна:

• кто обратился — контактные данные и способ связи 2;
• с чем обратился — описание словами человека, а не переводом на язык систем 2;
• когда — время обращения и длительность разговора 1;
• категория — тип обращения, от него зависит маршрут заявки 2;
• обслуживаем ли мы это — отметка о поддерживаемости 2;
• приоритет — по правилу, с указанием, откуда он взялся;
• куда ушло — исполнитель или группа;
• чем закончилось — итог и подтверждение от обратившегося 2.

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

Системы service desk: что они автоматизируют

Программу, в которой всё это живёт, так и называют — системой service desk, или сервис-деском; в объявлениях попадаются ещё «help desk система» и «учёт заявок». Класс один: приложение, где обращение превращается в заявку с номером, исполнителем и сроком, а из заявок собирается отчётность. Автоматизация тут не самоцель — она снимает с людей повторяющееся, а решения об отказе, о приоритете и о тоне разговора всё равно остаются за ними.

Где проходит граница, практическое руководство Service Desk разбирает по каждому шагу отдельно 1. Приём обращения автоматика берёт на себя охотно: заранее записанное приветствие, выбор темы в голосовом меню, объявление о текущем сбое, голосовая почта, проверка личности звонящего — всё это происходит до того, как пользователь дойдёт до оператора. Автоматическая регистрация вдобавок надёжнее ручной: главный источник данных о качестве услуг — полнота заявок, а она держится не на дисциплине оператора 1.

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

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

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

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

И про шаблоны уведомлений: их стоит регулярно проверять, потому что изменение в связанных данных превращает подставляемые поля в пустые места, и пользователь получает письмо с дырами 1.

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

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

Как измерять

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

Про опросы есть проверенное правило: короткий опрос собирает больше. MOF формулирует прямо: четыре вопроса с откликом 80% полезнее десяти вопросов с откликом 25% 2. Учебное руководство ITIL советует держаться в пределах пяти-шести вопросов 3.

Отдельный приём оттуда же — оповещение по порогу: система предупреждает владельца обращения, когда истекло 80% отведённого времени, и это работает лучше, чем разбор просроченного постфактум 2.

Часть показателей Брукс считает на одного специалиста, а не на службу. Счёт на человека меняет разговор. Общий счёт по службе растёт от найма и падает от увольнений, ничего не говоря о работе; счёт на человека показывает нагрузку и выучку — и сразу делает видимой разницу между сменами. Так посчитаны доля заявок, решённых с первого раза, и число звонков, закрытых без эскалации: у второго цель 20 звонков на специалиста при тревоге в 40 8.

Один порог стоит разобрать целиком — долю заявок, решённых с первого раза. У Брукса цель 65%, тревога — если опустилось ниже 40% 8. Кому такая планка впору: службе, где первая линия действительно решает, а не только регистрирует. У неё есть база знаний, диагностические сценарии и права на типовые действия — сбросить пароль, разблокировать учётную запись, выдать стандартный доступ. Две трети обращений там и правда закрываются в первом разговоре.

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

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

Остальные пороги — к тому, что уже стоит в таблице. Время ожидания ответа — 10 секунд при тревоге в 20; звонки, брошенные до ответа, — 3% при тревоге в 5; неправильно эскалированные заявки — 5% при тревоге в 15; обращения «не по адресу» — 3 при тревоге в 8 8. Первые три зависят от того же, что и доля решённых с первого раза: от прав и подготовки линии. Последний — ещё и от того, где проходит граница обслуживаемого: чем яснее записано, чего служба не делает, тем меньше обращений «не по адресу» до неё вообще доходит.

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

А одну стоит взять смыслом, а не числом. У доли инцидентов, пришедших из EVNМониторинг и управление событиями, Брукс пишет в обосновании, что чем она выше, тем меньше у службы ручной регистрации, — а целевым значением ставит ноль 8. Обоснование и число тут расходятся, и правым выглядит обоснование: автоматически заведённый инцидент экономит работу, а не создаёт её. Случай полезный сам по себе — он показывает, что числа из книги проверяются здравым смыслом, а не переносятся молча.

Зрелость службы поддержки

✕

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

Шесть мест — по нашим наблюдениям, начиная с самого частого.

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

Записывают не всё. Короткие консультации и «я только спросить» остаются в голове. Через полгода выясняется, что треть рабочего времени уходит на то, чего в системе нет 5.

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

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

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

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

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

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

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

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

ITIL v3 описывал службу как функцию Service Desk — подразделение, которое ведёт инциденты и запросы и общается с пользователями 3. Именно это понимание закрепилось в русскоязычном обиходе, и оно объясняет большую часть споров о границах.

MOF называет службу поддержки рабочей группой внутри обслуживания заказчиков и расписывает её работу по шагам вплоть до контроля качества 2.

ГОСТ Р ИСО/МЭК 20000-1 службы поддержки не упоминает: требования предъявлены к регистрации, классификации и приоритизации обращений, а не к подразделению 4. Определение было в редакции 2005 года и из действующей ушло.

COBIT отдельной цели для службы поддержки не содержит: запросы и инциденты сведены в один процесс домена поставки и поддержки 6.

FitSM обходится без службы поддержки и как процесса, и как роли 7.

Вывод для практики: ссылаться на стандарт в споре о том, нужен ли организации сервис-деск, бесполезно — ни один из разобранных здесь его не требует: ни ГОСТ Р ИСО/МЭК 20000-1, ни COBIT, ни FitSM. Требования начинаются там, где речь идёт о полноте записей и единообразии обработки, а устройство приёма обращений каждый выбирает сам.

Где описано

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

Три соседние практики, без которых эта не работает: INCУправление инцидентами — что происходит с обращением о сбое, REQУправление запросами на обслуживание — что происходит с заказом, KNWУправление знаниями — откуда операторы берут ответы.