Как ускорить решение инцидентов на 40%?

achievementМы все время от времени сетуем на то, что, при всей своей разумности и логичности, ITSM страдает нехваткой числовых подтверждений пользы. Поэтому достижения, которые выражены в цифрах, всегда вызывают интерес. На днях один из наших заказчиков поделился с нами своим достижением: за полгода ему удалось сократить среднее время решения инцидентов на 40%. Достойный результат, не правда ли?

Основа решения – организация такого способа обращения за техподдержкой, при котором существенно сокращается время на сбор информации по инциденту и на его маршрутизацию до нужной группы. Технически это было реализовано посредством некоторой программы, которая должна была постепенно вытеснить такие способы обращения в Service Desk, как e-mail (о чём мы уже писали ранее) и телефон. Эта программа предполагает самостоятельное обращение пользователя, последовательный ответ на несколько контекстно-зависимых вопросов, автоматический сбор некоторой технической информации и затем регистрацию обращения в ITSM-системе с корректной классификацией по ИТ-услуге и маршрутизацией на наиболее подходящую группу ИТ-специалистов.

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

Через полгода статистика показала, что около 90% всех обращений регистрируются через новую программу. При этом среднее время решения инцидентов сократилось на 40%.

А поскольку речь идёт о коммерческой компании (где рабочее время людей может измеряться получаемой прибылью, а простой оборачивается операционными потерями), сокращение времени решения инцидентов с известными допущениями можно выразить в рублях. Чем вам не кейс?

Причём, речь идёт не о каких-то «магических» цифрах из отчётов зарубежных консультантов и аналитиков, а о том, что сделано в наши дни и у нас «под боком», нашими же знакомыми-коллегами. При этом заметьте, реализация не потребовала каких-либо длительных долгосрочных проектов, а фактически была выполнена в духе CSI – своими силами, в текущем режиме.

На конкурс "ITSM-проект года" эта история, к огромному сожалению, не попадёт, хотя результат, на мой взгляд, более чем достойный. И потому поддержим коллег аплодисментами. Абсолютно заслуженными.

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Станислав

    Хороша история, но, честно говоря, без подробностей стоит не больше тех самых " отчётов зарубежных консультантов и аналитиков". Можно уточнить хотя бы сколько человек в компании, каков объем каталога услуг и как поднимали культуру использования портала?)

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

    1. Дмитрий Исайченко Автор

      было бы очень интересно почитать полный отчет с обзором внедрения

      Это люди делали сами, для себя, консультантов не привлекали — нарядных отчётов писать некому 🙂 Про остальные вопросы я уточню у заказчика. Если будут ответы, опубликую.

    2. Дмитрий Исайченко Автор

      Докладываю (со слов заказчика):

      Количество пользователей на момент внедрения – около 1200 человек.

      В каталоге 26 услуг, в каждой по 5-9 типов обращений.

      Как меняли практику обращения за техподдержкой:

      1. Отключили возможность писать обращения старым способом (через Outlook).

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

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

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

      5. После полугода использования – опрос пользователей на портале – что в новом интерфейсе удобно/что неудобно, по результатам которого проводился анализ как функционала нового интерфейса, так и работы ServiceDesk в целом (см. п.6).

      6. Анализ результатов опроса, категоризация требований пользователей (т.е. отделили «мух от котлет» — что относится непосредственно к техническому решению, а какие вопросы просто по улучшению организации работы SD)

      7. Разместили на портале ответы на те вопросы и требования, которые были уже удовлетворены к тому времени, плюс план доработок нового интерфейса под оставшиеся требования.

      8. Далее периодически по мере доработки нового интерфейса публиковали на портале анонсы доработок.

      9. По мере роста интереса пользователей к такому способу работы завели в новый интерфейс регистрацию обращений в АХО, финансовый департамент и департамент маркетинга и рекламы.

       

      1. Андрей

        Дмитрий, так речь идёт об обращениях(заявках) или инцидентах? Согласитесь, это не одно и то же. Если об обращениях, то я сам отношусь к яростным сторонникам разделения:

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

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

  2. Андрей

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

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

    2. Как основной бизнес относится к тому, что его сотрудники выполняют, судя по всему бесплатно, работу, за которую платят ИТ? И чьё рабочее время дороже? Хотя, если исполнители основных процессов в компании не очень заняты, о почему бы и нет. Но это уже вопрос к эффективноссти бизнеса этой компании вообще.

    Сейчас еще один модный подход нарисовался — чтобы пользователи самостоятельно искали решение инцидентов в базе знаний или, что еще современнее, в соцсетях, пока частных, а там как кривая вывезет. Тут можно и 100% сокращения времени решения инцидентов добиться:)))

    Так вот и вижу — заболело у человека что-то, он открыл медицинскую энциклопедию, нашел симптомы и курс лечения, применил их и "вуаля".  

    1. Дмитрий Исайченко Автор

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

      Ребята добились результата. Результат имеет значение для бизнеса — услуги восстанавливаются быстрее (регистрация через новый интерфейс отнимает меньше времени, чем телефон + поиск доп. информации + иногда переназначения). А порассуждать — это да, это все могут 😉

      Так вот и вижу — заболело у человека что-то, он открыл медицинскую энциклопедию, нашел симптомы и курс лечения, применил их и "вуаля"

      Не бьётся с примером — решение и ищут, и применяют специалисты. Просто это теперь отнимает меньше времени.

      1. Андрей

        "(регистрация через новый интерфейс отнимает меньше времени, чем телефон + поиск доп. информации + иногда переназначения) " - 

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

        1. Дмитрий Исайченко Автор

          хотя тоже странно — в нормальной системе автоназначение делается по факту классификации инцидента

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

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

        2. Алексей Юсов

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

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

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

          1. Андрей

            Нет идеального инструмента на все случаи жизни. Портал самообслуживания- прекрасная вещь,  но не для инцидентов. Есть два ПРИНЦИПИАЛЬНО разных типа обращений: заявка на услугу и инцидент. 

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

            Инцидент — происходит неожиданно и пользователь НЕ ЗНАЕТ что реально произошло. Он знает только то, что не работает услуга. Вы можете сформировать прекрасный вопрос, содержащий 99% ответа, но, поскольку пользователь НЕ ЗНАЕТ ответа, то остальной 1% вы так и не получите. Более того, вы вероятнее получите ответ, удаляющий вас от решения. В случае с инцидентом специалист первой линии, обладая знаниями и опытом в ИТ, имея доступ к CMDB и системе мониторинга, может максимально точно классифицировать инцидент, используя общение с пользователем в качестве инструмента сбора недостающей информации. Чтобы с таким же качеством провести классификацию инцидента и сопроводить его требуемой информацией, пользователь должен:

            1. Обладать знаниями и опытом в ИТ не ниже соответствующих у сотрудника ИТ

            2. Иметь доступ к CMDB и системе мониторинга и обладать навыками работы с ними.

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

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

            1. Алексей Юсов

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

              И ещё вопрос немного в сторону. Сколько у вас было максимально сотрудников в службе поддержки? Это важно понимать, потому что на определённых объёмах можно получить существенный финансовый выигрыш.

              1. Андрей

                Мы типа консультанты-внедренцы, так что своих сотрудников мало. А вот  у заказчиков порядка 700-800 человек, разбросанных по почти сотне городов, включая забугорье. 

                По поводу регистрации инцидентов через портал — был опыт на крупной забугорной табачной компании в России еще в 2005 году. В результате получилось окошко, в котором пользователь в свободной форме описывает проблему и всё. Дополнительные чек-боксы (срочность, степень влияния и т.д.) пришлось повыкидывать, поскольку использовались некорректно. Даже привязку к сервису, уж вроде чего проще, не всегда получалось. Пример: инцидент от пользователя — сервис печать, не печатается отчет AP329. Назначается естественно на группу печати, а поскольку покопийный контракт, то вообще уходит к аутсорсеру. Выясняется, что что-то в  ERP не докрутили. Так что, да, регистрацию отдали пользователю, но в таком виде, что потом первой линии всё равно приходилось доуточнять. Вот почему в 40% по инцидентам для меня выглядят весьма сомнительно. По завкам — верю. Даже в большую цифру верю.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
20
ДЕК
24
Учебный курс:
Основы ITIL (очно) 
ЯНВ
14
Учебный курс:
Основы ITIL (очно)