Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

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

Комментариев: 13

  • Станислав

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

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

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

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

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

      Количество пользователей на момент внедрения – около 1200 человек.
      В каталоге 26 услуг, в каждой по 5-9 типов обращений.

      Как меняли практику обращения за техподдержкой:
      1. Отключили возможность писать обращения старым способом (через Outlook).
      2. Естественно, опубликовали статьи на портале о целях внедрения новой практики, ее преимуществах плюс подробные инструкции по использованию (в т.ч. видео).
      3. На автоответчик ServiceDesk повесили достаточно длительное сообщение о том, что для более быстрого обращения в ДИТ необходимо оформить обращение через новый интерфейс – чтобы пользователю было «скучно» каждый раз его слушать и он понял, что быстрее нажать на кнопку.
      4. Тем, кто все-таки дозвонился, «ненавязчиво» рекомендовали в следующий раз использовать новый интерфейс, а по некоторым обращениям (например, требующим авторизации доступа или приложения скриншотов), просто отказывали в регистрации по телефону.
      5. После полугода использования – опрос пользователей на портале – что в новом интерфейсе удобно/что неудобно, по результатам которого проводился анализ как функционала нового интерфейса, так и работы ServiceDesk в целом (см. п.6).
      6. Анализ результатов опроса, категоризация требований пользователей (т.е. отделили «мух от котлет» – что относится непосредственно к техническому решению, а какие вопросы просто по улучшению организации работы SD)
      7. Разместили на портале ответы на те вопросы и требования, которые были уже удовлетворены к тому времени, плюс план доработок нового интерфейса под оставшиеся требования.
      8. Далее периодически по мере доработки нового интерфейса публиковали на портале анонсы доработок.
      9. По мере роста интереса пользователей к такому способу работы завели в новый интерфейс регистрацию обращений в АХО, финансовый департамент и департамент маркетинга и рекламы.

       

      • Андрей

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

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

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

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

          Соглашусь 🙂 Но речь в данном конкретном примере идёт и о том, и о том.

  • Андрей

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

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

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

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

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

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

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

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

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

      • Андрей

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

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

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

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

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

        • Алексей Юсов

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

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

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

          • Андрей

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

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

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

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

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

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

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

            • Алексей Юсов

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

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

              • Андрей

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM