Вот типичный разговор. Сотрудник службы поддержки Образцов пытается оказать помощь очередному пользователю: «Я не могу распечатать документ». — «То есть ваш принтер не работает. Вы уже проверяли, подключен ли он?» —  «Да». — «В нем есть бумага?». — «Да». — «Сообщения об ошибке не было?» — «Нет». — «Значит, дело может быть только в вашей программе. Из какой программы вы хотите распечатать?» — «Из Word». — «Тогда нажмите кнопку «файл». Нажали?» — «Нажал». — «Выберите подпункт «Печать». —
«Так». — «Какой принтер там указан?» — «HP LaserJet 4000 Plus». — «Это тот принтер, который вы хотите использовать для печати?» — «Да». — «Хм, тогда я не знаю, что можно сделать. Я попробую разобраться и перезвоню вам, хорошо?» — «Только, пожалуйста, как можно скорее!» — «Да, конечно».

Этот пример наглядно демонстрирует те ошибки, которые сотрудники службы технической поддержки совершают при диагностике неполадок. Получение описания проблемы? Нет! Едва лишь услышав, что пользователь не может напечатать документ, специалист Образцов попытался сразу же заняться поиском неисправности. Однако вопросы, необходимые для понимания проблемы, заданы не были. Этот принтер вообще когда-либо использовался? Если да, то когда в последний раз? Работал ли кто-либо другой за компьютером пользователя и мог он изменить настройки Word или Windows? Данный принтер является использовался? Он соединен с сервером? Пользователю не удается распечатать только этот файл *.doc или другие тоже? Все эта информация осталась «за кадром», и неудивительно, что диагностика оказалась бессистемной и неполной.

Так или примерно так протекают будни во многих службах технической поддержки, будь то разработчики ПО, систем или пользователи ИТ какого-либо предприятия, как в вышеупомянутом примере. Ошибки, допускаемые сотрудниками при диагностике неполадок, очень похожи (см. врезку «Частые ошибки при диагностике неполадок»).

МЕТОД ПРОБ И ОШИБОК — СЛИШКОМ ЧАСТО

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

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

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

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

Отсюда вывод: не каждый сотрудник службы технической поддержки с большим опытом работы является опытным в том смысле, о котором здесь идет речь. Никакие стратегии диагностики неполадок не отложатся в долгосрочной памяти, если с самого начала действовать только методом проб и ошибок, не прибегая к системному и аналитическому подходу. Результат будет один — все те же пробы и ошибки. Почти 15 лет мы обучаем сотрудников служб технической поддержки, на протяжении которых имели возможность наблюдать за поведением более 2 тыс. сотрудников Help Desk из компаний-разработчиков ПО и систем ИТ, а также за сотрудниками самых разных компаний. В результате мы пришли к выводу, что количество «хаотичных» технических консультантов составляет более чем 50% от всего числа специалистов с многолетним стажем. Получается, что значительно больше половины всех сотрудников служб технической поддержки (с учетом новичков) нуждаются в повышении своей квалификации в области системной диагностики. К сожалению, они сами так не считают.

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

Приоритетным пунктом в списке мер по оптимизации диагностики неполадок является требование к руководителям команд Help Desk, а также руководителям служб и отделов ИТ, внимательно изучить возможности системного подхода и осознать заложенный в нем потенциал для улучшения качества услуг.

УЛУЧШИТЬ ДИАГНОСТИКУ НЕПОЛАДОК

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

РЕКОМЕНДУЕМЫЕ МЕРЫ

Какие меры следует предпринять руководителю службы технической поддержки? Ниже приводятся некоторые рекомендации.

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

Знания будут оставаться чистой теорией, если не будут применяться в деле. Мы говорим об изменении поведения сотрудников службы техподдержки, а этого невозможно добиться простым «переключением рычага». Необходим регулярный стимул. Например, ежегодный двухдневный тренинг, в течение которого приглашенный инструктор наблюдает за поведением консультантов во время их разговоров с клиентами, а затем сообщает им, что было хорошо, а какие недочеты следует устранить.

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

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

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

ВНЕСЕНИЕ ДАННЫХ В СИСТЕМУ HELP DESK

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

Ежемесячно руководитель отбирает лучшую документацию по диагностике неполадок и с помощью ноутбука и проектора демонстрирует их на командном совещании. Отличившиеся сотрудники поощряются. Таким образом, по принципу «вода камень точит», осуществляется регулярное обсуждение рутинных процедур.

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

ОПТИМИЗИРОВАННАЯ ДИАГНОСТИКА ПОВЫШАЕТ ПРОДУКТИВНОСТЬ

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

Эффективные методы диагностики проблем и их разрешения позволяют на 50% повысить производительность службы технической поддержки. Это способствует удовлетворению растущего спроса на услуги техподдержки. Но прежде всего улучшает качество работы консультантов, а следовательно, больше клиентов остаются довольны результатом, улучшается имидж службы
в целом. Хотя бы только по этой причине командам Help Desk следует активнее двигаться в направлении оптимизации диагностики.

Лотхар Биттнер — владелец компании TCC-Infokom.

Частые ошибки при диагностике неполадок

1. Неполное описание проблемы:

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

2. Недостаточный анализ причин проблем:

  • отсутствие обзора источников неполадок;
  • отсутствие системности и структуры при диагностике неполадок;
  • нерациональный порядок поиска причин;
  • хаотичные метания при диагностике неполадок;
  • игнорирование потенциальных источников неполадок;
  • повторная перепроверка одних и тех же причин;
  • блуждания и концентрация на тупиковых вариантах;
  • слишком быстрое признание своего поражения или необоснованное обнадеживание пользователя;
  • дополнительные затраты усилий на постобработку диагностического случая;
  • удаленная поддержка — тематическое «блуждание»;
  • преждевременное признание своего поражения в пользу оказания технической поддержки на месте.
© AWi Verlag