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

Вопрос из зала: упрощение эскалации

Опубликовано 1 октября 2012
Рубрики: ITSM, Вопрос из зала, Всё это - ЛЮДИ, Практика и опыт, Управление инцидентами, Эксплуатация ИТ
Комментарии

Наш коллега Евгений запросил совета у профессионалов. Вам, уважаемые читатели realitsm.ru, мы и адресуем следующий кейс:

Добрый день!

Хотелось бы спросить совета у профи. Наша компания занимается IT аутсорсингом. Из персонала мы имеем следующее: команда технической поддержки (первая линия – операторы, вторая линия – инженеры руки-ноги, третья линия – умные инженеры), команда сетевиков, которая занимается монтажом кабелистики, шкафов, ИБП, электрики и т.д., команда связи, которая занимается организацией работы IP телефонии на базе CISCO и команда виндовых серверов и сервисов, которая занимается серверами, почтой, фаерволами и прочими серверными компонентами.

Суть проблема вот в чем: например, поступило обращение от пользователя: не звонит IP телефон. Чтобы решить это обращение необходимо:

1. Отправить инженера второй линии на предварительный анализ (может просто нажата кнопка DND)

2. Если проблема не решилась, то обращение минуя третью линию поддержки, попадает в команду связи

3. И хорошо бы если обращение решится на уровне телефонистов… Но может случиться так, что телефон работает от локальной сети, и вроде бы нужно тестировать сеть

4. Телефонисты отправляют на это обращение монтажников, которые после тестов сети устраняют проблему, а потом …

5. … все повторяется снова, то есть инженер второй линии поддержки снова идет к пользователю, чтобы убедиться в том, что проблема с IP телефоном решилась…

Итог: слишком много телодвижений ради одного подобного обращения… одно дело когда у пользователя случилась беда с ноутбуком или принтером, здесь все просто: обращение регистрируется на первой линии и эскалируется на вторую линию, и практически до 95% обращений решается на второй линии поддержки. Но вот как быть со случаями, которые я описал выше? Заранее благодарю за помощь.

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

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Станислав Уштей

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

  • Vladimir Kapustin

    Может, стоит чуть заумнить первую линию? Сделать им базу знаний и опросник, чтоб не гонять выключать DND на телефонах?

    • Олег Скрынник

      Согласен с Владимиром.

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

      Всё же мне не верится, что много обращений связано с аппаратной поломкой, тем более обрывом сети.

    • Евгений

      По опроснику: ввели это явление относительно недавно. Сейчас боремся с пользователями, чтобы они могли адекватно ответить на задающие им вопросы… К сожалению, пока пользователь не привык к такому процессу обработки обращения…
      Что касается БЗ… Она есть. В виде руководства пользователя для телефонов CISCO… Причем руководство есть как на стороне хелпдеска, так и на стороне конечных пользователей. Но за совет все равно благодарю.

      • Евгений

        Сорри… по моему не на тот пост ответил..))… Вроде бы отвечал на пост Владимира…

      • Олег Скрынник

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

        Уверяю Вас, Евгений, самая бесполезная книжица – это руководство пользователя для современного телефонного аппарата. Нормальному человеку без спец.подготовки там почти ничего непонятно. Термины голову взрывают, сочетания кнопок похожи на заклинания. Самое неприятное – на простой человеческий вопрос “а как мне сделать то-то” руководство понятного ответа не даёт.

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

        • Евгений

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

  • Георгий

    Евгений, я бы начал с того, что посмотрел, сколько вообще обращений по сервису IP – телефонии
    Далее так, если количество их совсем минимально (1 заявка в квартал), то не стал бы делать ничего, ваш процесс и так нормально работает, всякие способы уменьшить время обработки этой заявки встанут дороже, чем все ваши телодвижения
    Если количество довольно существенно, то начал бы собирать базу знаний относительно того, в чем чаще всего лоежит причина инцидента и далее после первой линии сразу бы отправлял на ту группу, где чаще всего “лежит” подобный инцидент. Тут есть нюанс, что если хотя бы процентов 20 заявок вообще решаются без выхода на место (например вариант “может просто нажата кнопка DND”), то я бы дал описание решения подобной заявки на первую линию, вы сразу сэкономите 20% выходов на место инженера второй линии

    Ну как-то так

    • Евгений

      Если брать статистику за прошлые 3 месяца… то статистика говорит о том, что вопросы по использованию IP телефонов возникает не чаще чем 6 обращений в месяц…

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

      • Георгий

        Т.е. чаще всего случается так, что регистрируется инцидент на IP-телефонию, а в реале – с самой телефонией что-то не так 6 раз в месяц, а чаще всего, что-то не так с локалкой?
        Тогда можно попробовать
        1. дать на первую линию три-четыре простых совета пользователю, чтобы по проверке этих советов с высокой вероятностью понять, что проблема не в нажатой кнопке, не в работе винды и она не решается без выхода на место (кстати удаленный доступ к компу пользователя невозможен?)
        2. Дальше
        а) дать инженерам “руки-ноги” базовые знания по исправлению обрывов и/или других типовых неисправностей в локальной сети и выводить все же их, как вторую линию на место,
        б) сразу выводить инцидент на монтажников, чтобы они работали с локальной сеткой.
        Здесь надо также считать сопоставима ли допнагрузка на монтажников (а она будет, тк ошибки при диагностике все равно будут находится + 6 инцидентов в месяц как мы помним все же с телефонами, т.е. к связистам) с экономией за счет того, что вторая линия зря не бегает, пользователь зря не ждет итп

      • Vladimir Kapustin

        Выведите первой линии веб-мордочку с простейшими диагностиками. Тот же порт спросить по snmp, логи состояний этого порта за последние 2-3 дня,…

        • Евгений

          немного подумав … возник вопрос: а не пропадет ли надобность в первой линии поддержки если на вторую линию поддержки повесить задачи по регистрации обращений? теоретически вторая линия поддержки может и принять звонок и сразу подключиться удаленно к железке пользователя и т.д.

          вопрос 2: не лишиться ли вторая линия поддержки нагрузки если первая линия поддержки будет стараться решать обращения путем простейшей диагностики?

          • Vladimir Kapustin

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

          • Pavel Solopov

            А у вас и так с линиями что-то не понятно. Зачем третья линия, например, не понятно. А монтажники у вас вообще не линия…
            То что первая линия отберёт работу у второй ничего страшного, переместите освободившихся людей со второй линии на первую, ибо на первую нагрузка возрастёт.
            Вообще надо заниматься разработкой технологических карт траблшутинга. Продумывать как диагностировать и локализовать причины инцидентов. Ну да об этом собственно уже не раз говорилось выше.

            • dik

              Мне кажется вопрос поднят глубже, чем обсуждение вопроса с IP-телефонией. Описание ситуации стандартное для многокомпонентных сервисов

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.