Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

4 основных причины плохой технической поддержки

4 основных причины плохой технической поддержки

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

Причина 1. Недостаточное использование или намеренный отказ от идеологии тикетов

Многие компании для организации технической поддержки (а точнее, для отправки запросов на обслуживание) используют «доморощенные» системы на базе SharePoint или обычную электронную почту. При небольшом масштабе службы технической поддержки подобные системы отлично справляются с поставленной задачей. Но на этапе масштабирования начинаются сложности. Причем, проблемы эти могут принимать самые разнообразные формы. К примеру, сотрудники службы технической поддержки не могут быстро найти важнейшие задачи среди несрочного мусора, или же некоторые запросы регулярно остаются без ответа (поскольку в ходе разбора огромного количества почты их просто «теряют»). Неэффективные системы отправки/приема запросов на обслуживание создают основу для будущих эксплуатационных проблем в службе технической поддержки, решить которые позволило бы внедрение системы тикетов.

Причина 2. Непрозрачность, а также невозможность оценить и измерить работу службы технической поддержки

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

Причина 3. Слабая клиентская заинтересованность в работе технической поддержки

Вполне распространена практика, когда более технически грамотные сотрудники компании готовы взять на себя ответственность за эксплуатацию определенных технологий и приложений (с согласия ИТ-службы), дабы повернуть «дело» наиболее удобной для себя стороной. Ярче всего эта готовность прослеживается в рамках концепции BYOD (Bring Your Own Device) – головной боли многих ИТ-служб. Но у нее есть и иная сторона (более выгодная ИТ-шникам): рост популярности порталов самообслуживания для оказания технической поддержки. Понимание пользователей внутренней кухни такого портала (какие запросы имеет смысл туда отправлять, как их оформлять и т.п.) – чрезвычайно важно, поскольку снимает часть бюрократической работы с сотрудников технической поддержки, помогая избегать появления лишних тикетов в системе. Кроме того, участие пользователей в этом общем процессе помогает повысить их лояльность по отношению к технарям, получить внятную обратную связь от клиентов и, в конечном счете, улучшить качество их обслуживания.

Причина 4. Неспособность решить фундаментальные проблемы

Самодельные и часто излишне простые инструменты управления работой службы технической поддержки обычно дают организациям не больше преимуществ, чем голая система управления тикетами. Из-за таких нефункциональных решений техническая поддержка может тратить изрядную долю своего времени на обработку сообщений по электронной почте, расстановку приоритетов входящим запросам, поиск стратегии борьбы с основными «глюками» системы и т.п. Все эти действия, безусловно, направлены на снижение времени простоя конечных пользователей из-за возникающих проблем. Но ведь на самом деле загвоздка не в этих маленьких проблемах, а в глобальной неспособности системы справиться с существующим объемом работы. Нежелание взглянуть на проблему в другом масштабе приводит к тому, что техподдержка так и не начинает развиваться. Лечение симптомов в данном случае не приводит к лечению болезни.

Дополнительные материалы:

Комментарии (6)

  • Аватар

    Юсов Алексей [alexus], 10 июня 2014, 03:45

    1

    Очередной маркетинговый бред для чайников

    Причина 1. Недостаточное использование или намеренный отказ от идеологии тикетов

    Чем обычное письмо не тикет?

    Причина 2. Непрозрачность, а также невозможность оценить и измерить работу службы технической поддержки

    Если вести НЕтикеты, а просто запросы (поясните мне разницу :-D!!!) XLS-таблице, то можно прекрасно всё измерить и оценить!

    Причина 3. Слабая клиентская заинтересованность в работе технической поддержки

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

    "Уже смешались БЬЁДы, "боли", порталы, службы, технари....

    А CIO слабо, непрозрачно внедряет тупо "почтари" "  )))))))

    Причина 4. Неспособность решить фундаментальные проблемы

    Ну конечно! Всем известно! Решение всех фундаментальных проблем - установка правильного ПО! И все сразу начинаю жить радостно и вприрыжку бегут удовлетворять запросы клиентов! Или лучше тикеты решать? или всё-таки запросы удовлетворять? Не поймешь этих буржуев. Да и надо ли голову забивать такой ерудной. Ставь "одетую" (в смысле - не "голую") систему управления тикетами, и всё будет прекрасно.

    • Аватар

      Дьяков Андрей Владимирович [Dru], 10 июня 2014, 11:04

      1

      - Чем обычное письмо не тикет?

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

      - тикеты в ексель таблице??? ну что сразу не в общем ворде??? Документ на ТО из 5 человек! Ад Данте отдыхает, Сизиф понимает что ему повезло... Глупость видно придумали те, кто писал OTRS. Вот руки никак не дойдут её у себя внедрить, что очень печалит.

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

      - Причина 4. Неспособность решить фундаментальные проблемы 

      а ничего смешного... я наблюдал компании по сорсу, котрые даже VPN не могли добросить до клиента и выезжали даже когда надо было антивирус запустить. Да сапожники без сапог - это встречается на рынке.

      -Очередной маркетинговый бред для чайников 

      К сожалению какой рынок сорса такие и статьи, автор что видит то на обсуждение и выносит.

      всё имхо.

       

      • Аватар

        Юсов Алексей [alexus], 11 июня 2014, 23:42

        1
        Вы не оценили моего тонкого юмора :)! Я сам знаю как с помощью Сами-Знаете-Чего решить проблемы автоматизации техподдержки.
    • Аватар

      Федулов Кирилл [kfedulov], 10 июня 2014, 12:07

      0

      А я, кстати, приветствую статьи для чайников в том числе. Многие люди до сих пор сталкиваются с проблемами, которые нам кажутся пройденными сотни раз. Я сам ежедневно сталкиваюсь с такими компаниями и людьми. И ничего - обсжудаем, рассуждаем, объясняем.

      Если по пунктам, то:

      1. Не очень понятно, причем здесь идеология тикетов и что это такое. В самом пояснении указаны как раз более явные проблемы - отсутствие приоритезации (по вине средства автоматизации или установленных процедур), отсутствие какой-бы то ни было эскалации и/или связанных с ней процедур (если мы говорим про средства автоматизации, то это могут быть хотя бы "напоминалки-пиналки").

      2. Вопрос контроля и отчетности гораздо более глубокий, чем здесь описано. Сама по себе система каких-либо метрик в правильном случае должна быть ассоциирована с конкретными процедурами и ролями в рамках процесса, которые позволяют осуществлять контроль на разных этапах и/или предпринимать определенные воздействия/решения. При правильной схеме метрик процесс действительно становится более прозрачным и управляемым и, по опыту, Excel здесь, конечно, не поможет. Хотя если наша зрелость и наши метрики связаны с измерением лишь количества зарегистрированных/решенных инцидентов, то....

      3. В сухом остатке речь, если я верно понял, о регулярном обучении сотрудников и функциональном и простом портале самообслуживания. Кстати говоря вопрос обучения каким-то техническим вещам сотрудников также очень спорный в части эффективности. На практике зачастую проще, быстрее, дешевле взять пару дополнительных человек и предоставить им на 1-й линии, например, средства удаленного подключения к рабочей станции. Где-то находил любопытную статистику в западных исследованиях насколько это "удешевляет" стоимость регистрации и решения инцидента

      4. Речь опять же о зрелости как самой службы поддержки (их процессов и т.д.), так и самих пользователей. Для небольших компаний средства автоматизации вообще не нужно - там не до оптимизаций процесса - бежать быстрее нужно. Но то, что очень часто компании "перерастают" имеющиеся средства автоматизации класса Service Desk или ITSM (кому как нравится) и действительно получают от их использования больше проблем - факт. В этом случае обычно и назревает вопрос миграции на более зрелые решения

  • Аватар

    [unterschrift], 10 июня 2014, 10:59

    0

    Да проблемы все те же...в статье какие-то частности упоминаются.

    Проблема 1: Нежелание руководства или ИТ-отдела совершать перемены. Ну тут ничего не попишешь. Ставьте жирный крест на этой теме.

    Проблема 2: Безответственные юзеры. У нас уже 2,5 года Сервис-Деск и до сих пор люди прут к локальной поддержке с просьбой починить прогу или разблокировать учетку. Готовы даже ждать час-полтора локального саппорта чтобы разблокировать учетку, когда звонок решает проблему за 5 минут(у нас по статистике в течении пяти минут решается 97% подобных запросов). И тут ругайся, не ругайся, но найдется 10% беспроблемных, понимающих с одного раза, 10% не понимающих вообще и нежелающих никуда звонить и 80%, которые все же с 3-его или 4-его раза все же начинают понимать.

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

    Проблема 4(связанная с проблемой 3): Контроль за следованием правилам юзерами. Есть такое понятие как compliance, то есть соответствие действий команды правилам компании(или команды). Если пользователь тупо ходит к локальной поддержке и не следует общепринятым правилам, которые утверждены высшим руководством, то он так и будет делать, на него нет никакого воздействия. Если же вести статистику приходов, звонков локальной поддержку в обход Сервис-Деска и выдавать это как показатель руководству, то можно просить бороться с негативными проявлениями на верхнем уровне. В моей практике для 50% людей достаточно слова высшего руководителя, для остальных 50% обычно достаточно повторения сказанного устами непосредственного руководителя.

    Проблема 5(связанная с проблемой 3): Мотивация ИТ-команды чтобы они были заинтересованы закрывать запросы вовремя, быстро реагировали и прочее. Если, как минимум, премия ИТ-поддержки не зависит от качества услуг, то смысла делать работу лучше не имеет для них смысла.

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

    Не страдайте карго-культом.

     

    • Аватар

      Васильев Денис [Dissan], 15 июля 2014, 15:20

      -1

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

      2.2. Режим работы службы технической поддержки

      По рабочим дням с 10 до 18 Часов омского Времени (UTC +07:00). 
      Кроме выходных и праздничных дней (по календарю праздничных дней России). Поддержка партнеров по срочным вопросам ( п. 2.5.1 ) осуществляется круглосуточно . Время реакции на обращения включает в Себя Только рабочее ВРЕМЯ (за исключением работы сотрудников техподдержки по "спецобращениям" без привлечения разработчиков). 




      Обращения в службу технической поддержки обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем поддержки ( SLA ). Вне очереди могут обрабатываться обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям могут быть отнесены вопросы восстановления работоспособности системы ЕСТ, или отдельных сервисов данной системы. 

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

       

      2.3. При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта, передаются для решения в отдел разработки компании «Единая служба такси», с последующим выпуском обновления программного продукта. Сроки выпуска обновления определяются в процессе диагностики проблемы и в соответствии с общим планом разработки программного продукта.

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

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

      А эти требования не выполняются...