Бизнес план службы технической поддержки
Когда дело касается службы IT-поддержки, нет места пустословию. Эти сотрудники на «передовой» вашего бизнеса, которые имеют прекрасное представление о производительности систем и пользовательском опыте клиентов и сотрудников, что может помочь существенно улучшить работу вашего бизнеса.
Служба поддержки часто считается отправной точкой в карьере новых и неопытных сотрудников, которые стремятся попасть в сферу IT или перейти к другим её областям. Но, если IT-директор серьезно относится к культуре обслуживания, то так быть не должно.
Сейчас как раз нужный момент. Новые технологии в работе службы поддержки наряду с такими тенденциями, как цифровая трансформация, дают возможность стратегически использовать этот недооцененную точку контакта для повышения качества обслуживания клиентов.
Что IT-директора могут сделать для преобразования службы IT-поддержки и создания более продуктивных задач? Начните с понимания влияния вашего собственного восприятия.
Восприятие — это основа
«Самые дальновидные IT-директора рассматривают услуги как стратегическое направление IT, — говорит Стив Стовер, вице-президент по продуктам и интеграции в Samanage, облачном провайдере услуг IT-поддержки. «Они видят службу поддержки в рамках стратегии развития IT-услуг и рассматривают её как основную точку касания для значимого взаимодействия с конечными пользователями».
В этом контексте служба IT-поддержки позиционируется как внешний интерфейс для доступа к различным IT-услугам, которые предоставляет компания.
«Служба поддержки обычно служит единственной точкой контакта для сотрудников, когда речь заходит о любых требованиях, проблемах или помощи, в которой они нуждаются при потреблении технологических услуг», — говорит Прашант Менон, менеджер ManageEngine Service Desk Plus, программного решения для службы IT-поддержки. «В зрелых организациях служба поддержки гарантирует своевременную помощь и быстрое решение проблем на гарантированном уровне качества обслуживания (SLA)».
Как еще использовать потенциал службы поддержки? В этом вопросе организации находят специфические решения.
«Как организация использует службу поддержки, во многом зависит от ее размера, вертикали управления, конкретных требований, соответствующих инвестиций и того, насколько эти инвестиции соответствуют бизнес-целям», — говорит Менон. «Некоторые организации могут использовать свою техподдержку, чтобы просто обеспечить доступ к базовым технологическим услугам для сотрудников, в то время как другие могли бы использовать её стратегически как драйвер внедрения новых технологий».
Организации, которые предпочитают поддерживать работу службы поддержки в качестве платформы для решения проблем, которые функционируют так же, как и 25 лет назад, также имеют тенденцию видеть техподдержку в качестве центра затрат. Другие видят новые задачи и возможности для этой службы.
«Самообслуживание и вовлечение конечных пользователей — это условия, в которых сегодня многие компании преобразуют свои службы IT-поддержки», — говорит Стовер. «Поколение миллениалов выросло в условиях самообслуживания и активности пользователей, поэтому оно ожидает этого».
Изменение культуры «поработал и беги»
Тем не менее, даже когда IT-поддержка использует больше возможностей для автоматизации, развития самообслуживания и внедрения технологий искусственного интеллекта (AI), которые сегодня являются трансформационными для бизнеса, для сотрудников службы поддержки, стремление уйти на лучшие IT-должности сегодня так же велико, как и 25 лет назад.
«Основной задачей для компаний является обеспечение понимания для сотрудников IT-поддержки важности их вклада в достижение целей бизнеса», — говорит Менон. «Техподдержка часто рассматривается как вспомогательная, а не как основная бизнес-функция, поэтому команды IT-поддержки обычно сосредотачиваются только на выполнении своих задач. Служба поддержки и IT-менеджеры не понимают, насколько тесно IT-поддержка должна взаимодействовать с бизнесом в целом и то, как предоставление качественных IT-услуг оказывает глубокое влияние на итоговую прибыль компании».
Признание стратегической значимости IT-поддержки — это то, где IT-директора должны приложить свои усилия. Если IT-директор продолжает рассматривать службы техподдержки в качестве отражателя для вопросов и проблем пользователей, которые не должны беспокоить администраторов баз данных и разработчиков приложений верхнего уровня, культура «отработал и беги» для службы поддержки не изменится.
IT-руководители понимают это. Они включают менеджеров службы поддержки и персонал в сеансы конференц-связи, в которых участвуют администраторы баз данных и прикладных программ. Они хотят, чтобы техподдержка рассказала им историю конкретных систем, чтобы определить, какие из них испытывают наибольшее количество проблем или какие типы интерфейсов больше всего беспокоят пользователей. От службы поддержки можно узнать те ошибки, которых следует избегать при разработке приложений, и то, какие системы следует заменить.
«Поистине зрелая служба техподдержки может также сосредоточиться на том, чтобы конечные пользователи не сталкивались с проблемами в принципе», — говорит Менон. «Менеджеры службы поддержки и персонал могут отслеживать свои собственные показатели производительности с точки зрения пользовательского опыта и удовлетворенности, используя эти показатели для стратегических операций внутри компании, таких как цифровая трансформация».
При такой стратегии персонал IT-службы становится настоящими лидерами. Они наставляют другие подгруппы внутри компании (например, HR, обслуживание клиентов) в том, как использовать технологии службы поддержки для ответа на вопросы пользователей и решения проблем. Они также помогают определить области, где самообслуживание — отличный вариант.
Напротив, менее опытные команды техподдержки, которые не имеют видения и не обладают качеством лидеров, скорее всего, будут заниматься «тушением пожаров» в большинстве случаев, как это было исторически. Борьба с пожарами означает, что у них не останется времени для отслеживания и анализа показателей производительности.
6 способов перезагрузить службу техподдержки
В начале 2016 года кредитный союз реализовал IT-систему для организации своей техподдержки. Благодаря правильному сочетанию форм ввода и автоматизации процессов они смогли улучшить и измерить ключевые показатели техподдержки, такие как открытые тикеты, с нарушением условий SLA, нагрузку на исполнителей, их производительность в соответствии с SLA, а также деление и категоризацию разбивки тикетов. В течение двух лет они расширили концепцию управления услугами за пределы IT — до четырех департаментов, включая HR.
Другие организации могут также «перезагрузить» свою службу техподдержки, рассмотрев шесть лучших практик:
1. Определите стратегическое направление развития службы поддержки и верьте в это.
«Недостаток лидерства в IT — частая причина разочарования в работе службы поддержки», — говорит Менон. «Если руководство не ясно определит ценность, которую несет техподдержка для бизнеса, и вместо этого больше фокусируется на транзакционных операциях, персонал службы IT-поддержки может не знать, почему они должны делать то, что они делают. IT-лидеры должны объяснить разницу между просто кучей кирпичей и строительством собора».
Менон прав. Многие IT-директора продолжают в основном использовать help desk, чтобы отделять вопросы пользователей от IT-функций, которые они считают более ценными, даже осознавая при этом ценность службы технической поддержки.
Как это изменить?
Определите инициативы службы поддержки, которые приносят ощутимую ценность компании и сделают её неотъемлемой частью этой стратегии.
«В одном случае IT-отдел реализовал систему помощи на основе ИИ для своей службы поддержки и сократил среднее время трудозатрат на два часа в неделю», — говорит Стовер. «Компания внедрила основанную на правилах систему, в которой ИИ использовалась для работы с историческими данными техподдержки. Эта система имела 96% коэффициент успеха в случаях, когда агенты техподдержки использовали ее в своей работе».
2. Заручитесь поддержкой внутри службы техподдержки и внедряйте инициативы
Компании, которые погрязли в восприятии техподдержки в стиле старой школы, должны преодолеть точки сопротивления в культуре компании, а также инвестиционные и технологические препятствия.
Преобразование службы поддержки и обеспечение принятия её ценности и роли начинается внутри самой службы.
«Люди в техподдержке действительно не понимают их роли и как лучше всего могут способствовать тому, чего хочет их компания», — говорит Менон. «Когда есть недостаток понимания целей между топ-менеджментом, лидерами департаментов и руководителями IT, производительность может оказаться на нуле».
Чтобы этого избежать, руководители и сотрудники техподдержки могут устанавливать цели и показатели обслуживания, каналы обратной связи для внутренних IT-систем и других целевых областей улучшения, а также SLA для удовлетворения потребностей клиентов. Возможно, стоит размещать персонал службы поддержки вместе с персоналом из более уважаемых IT-дисциплин, таких как работа с базами данных или разработка приложений. Они могут помочь получить друг другу необходимый для развития бюджет.
Вторая очередь признания важности службы поддержки — это представители бизнеса.
В 2017 году American Express опубликовал свой Барометр обслуживания клиентов и обнаружил, что более половины американских потребителей отказались от запланированной покупки или транзакции из-за плохого обслуживания.
Техподдержка является определяющей для лояльности клиентов, которая в свою очередь влияет на итоговую прибыль. Это область, где опыт и технологии службы поддержки могут быть использованы в масштабе всей компании для достижения конкурентных преимуществ. Это также отличная возможность для IT-директоров продемонстрировать технологии и подходы службы IT-поддержки, а также ценность привлечения этих сотрудников к повышению эффективности обслуживания в других департаментах компании.
3. Акцент на непрерывном совершенствовании процесса
«В одном случае компания разработала чат-бота», — говорит Стовер. «Цель заключалась в том, чтобы освободить службу поддержки от запросов первого уровня. Компания переработала свой портал службы поддержки, чтобы интегрировать чат с сообщениями от службы поддержки для формирования более целостного опыта у конечных пользователей и более полного контекста для персонала службы технической поддержки».
Существует множество инструментов для цифровизации, которые могут быть интегрированы в структуру техподдержки и способны повысить её производительность. Тем не менее, следует сфокусировать внимание на том, улучшают ли эти решения жизнь конечных пользователей и персоналу службы поддержки. Если технологии не сделают этого, они не будут приняты людьми.
«Команда IT-поддержки может разработать ботов на основе ИИ, чтобы реагировать на запросы пользователей и быстро решать проблемы, предоставляя сотрудникам время позаботиться о других важных мероприятиях», — сказал Менон. «Эти боты могут понимать и реагировать на голос, а также через текстовые интерфейсы, даже если персонал службы поддержки недоступен или занят другими задачами. Возможности машинного обучения (ML) помогут снизить нагрузку, например, заменив человека в обработке огромных объемов данных, поиске шаблонов и определении требуемых действий для типичной ситуации».
IT-поддержка также может использовать популярные приложения для общения и совместной работы.
«Если команда службы поддержки инвестирует в интеграцию своих инструментов с приложениями, которые пользователи уже применяют и хорошо в них разбираются, это беспроигрышная для обеих сторон ситуация с точки зрения ценности, которую они получат друг от друга», — говорит Менон. «Пример заключается в том, чтобы позволить пользователям отправлять запросы через WhatsApp, а не заставлять их проходить через набор сложных форм на сайте».
4. Сосредоточьтесь на пользовательском опыте
Ваша служба поддержки не будет успешной, если ваши пользователи не будут счастливы.
Отзывы пользователей об эффективности службы поддержки должны постоянно собираться и оцениваться. Если есть области, где необходимы улучшения, то эти улучшения должны быть проведены незамедлительно.
Во-вторых, пользователи должны иметь доступ к ресурсам службы поддержки с помощью удобных им методов. Это могут быть чаты, руководства по самообслуживанию или всплывающие оповещения, инструменты совместной работы и прочее.
Инвестируйте в профессиональное обучение сотрудников службы поддержки. Это обучение должно охватывать коммуникационные навыки и искусство межличностного общения, а также знание систем. Хорошо обученный персонал компетентен, уверен в своих силах и способен осуществлять IT-поддержку пользователей мирового уровня.
5. Наймите подходящих людей
«Фундаментальные черты, которыми должен обладать любой сотрудник службы поддержки, — это сопереживание и терпение», — говорит Менон. «Готовность слушать и решать проблемы других людей в сочетании с глубокими знаниями в своей области, внимательностью для правильного понимания проблемы и опытом для поиска и реализации правильного решения — делает сотрудника службы поддержки чемпионом в глазах пользователей. Двигаясь вперед, сотрудники службы поддержки будут еще более успешными, если их опыт и знания позволят им думать наперед и создавать системы, которые не только обрабатывают повседневные проблемы, но и прогнозируют наилучший способ решения будущих проблем».
6. Создайте карьерный путь для сотрудника службы поддержки
Наконец, для профессионалов службы поддержки необходимо создать возможности продвижения по карьерной лестнице. Эти люди должны знать, что у них есть будущее в компании, если они хотят остаться в техподдержке.
Развитие карьеры в QA, техподдержке и других недооцененных IT-дисциплинах по-прежнему является мечтой многих. Поэтому неудивительно, что даже те люди, кто действительно получают удовольствие от работы в службе поддержки, не полностью вовлечены в свою работу и преданы делу.
Это неправильно. Чтобы создать привлекательный карьерный путь, обеспечьте продвижение по службе и профессиональное развитие. Если IT-директора серьезно настроены по отношению к развитию культуры IT-обслуживания, сохранение ценных сотрудников и менеджеров службы поддержки путем предоставления возможностей карьерного роста — это то, о чем следует подумать.
Другие статьи блога Cloud4Y:
→ Облачный архитектор – кто он? Необходимые навыки, знания и оплата (внешняя ссылка)
→ SD-WAN: причины успеха в корпоративном IT (внешняя ссылка)
→ TCO — это 1990-е годы: поприветствуйте TCS (Общая Стоимость Услуг) (внешняя ссылка)
→ Что происходит с ценами на облачные вычисления последние годы (Хабр)
Добрый день. Хотелось бы поведать небольшую историю, которая произошла со мной не так давно и связана как с карьерными ожиданиями, так и с ошибочным восприятием того, что происходит в реальности. Как работодатель может вводить в заблуждение или неосознанно вредить мотивации команды.
Приехав в провинциальный город из Москвы, я собирался устроиться начальником ИТ-отдела в какую-нибудь фирму. Пройдя в Москве повышение квалификации и все этапы работы от первой линии до третьей, поняв что менеджмент и управление людьмипроцессами мне нравится и мне это по плечу, я начал искать вакансию.
Подробности под катом.
Специально не отвлекался на вакансии трансформеры, когда компании нужен “и спец, и жнец, и на дуде игрец”(это когда человек должен и платы паять и 1С-конфигурации писать) я терпеливо ждал хорошего предложения. Через 2 месяца на меня вышел зам.начальника управления, с предложением, на которое трудно было не согласится. Направление только появилось, компания федерального масштаба, создающая отдел поддержки и разработки в регионе, планы были грандиозные и вполне соответствовали моим ожиданиям. Можно было построить команду и процессы с нуля, оптимизировать и встроить их в существующие процессы. Все называли должность с функциями «координатораначальника Техподдержки». Что ж, я был готов в бой.
Первоначальные цели:
- Поддержка на первой и второй линии.
- Создание базы знаний
- Создание документации пользователей
- Вникнуть в бизнес-процесс для осуществления “бизнес консультаций”
- Подготовить регламент взаимодействий подразделений в рамках методологии ITIL Service Desk(планировал взять оттуда только процесс прохождения заявок и инцидентов + написание SLA, потому как знаю, что в тупую внедрять полностью формализованный процесс никто не даст, да и это не заработает)
- Нанять сотрудников поддержки.
Создание документации
Что хотелось: Так как поддерживать предстояло купленную информационную систему, а я раньше больше имел дело с аппаратной инфраструктурой, я решил входить в курс дела постепенно и с той стороны, какая была для меня самой очевидной – я попросил регламенты процессов, автоматизируемых системой, и документацию к ней. И столкнулся с первым сюрпризом – документации у купленной за “деньги” системы не было. Были набросанные компанией-разработчиком на коленке слайды, как определённые роли участвуют в процессе и на этом всё. У компании было ещё 4 месяца поддержки по договору, когда к ним можно было обращаться с вопросами по работе системы. Внутреннего проекта по внедрению системы не было, сроки устанавливались соглашением и excel-документом, в котором были указаны сроки внедрения определённых доработок. Да, после моего найма система дописывалась ещё 5 месяцев.
Что получилось: С грехом пополам, описаны несколько процессов в виде схем Visio. Частично описаны модули системы. Из-за срыва сроков коммуникация с разработчиками купленной системы стала ещё хуже. Насколько я понял, обязательность документации при покупке не оговаривалась.
Вывод: Недокументированная недописанная система плохо подлежит описанию без помощи разработчиков. Старайтесь наладить процесс коммуникации.
Создание базы знаний
Что хотелось: Поддержка на первой линии предполагала набрать определённый пул вопросов от пользователей, предполагалось, что этот пул уже есть у менеджеров, хотя бы частично. Но после переговоров с начальником отдела продаж стало ясно, что пула нет и процесс будет выглядеть следующим образом: пользователь звонит, если это связано с технической частью, то помогаем, если с бизнес-частью, то перезваниваем. Так как бизнес-части ответов не было совсем, то первым пользователям должно было не очень повезти. Опять же, при разговоре я понял, что бизнес не очень то и дорожит новыми пользователями и готов пойти на эти риски.
Чтобы внести ясность, с такими исходниками картина представлялась довольно туманной, но я воспринимал это как вызов.
Что получилось: Создан документ, позволяющий покрывать первоначальный объем бизнес-консультаций. Порядок работы с бизнесом регламентировать не удалось. На новый вопрос «не из списка» бизнес мог забыть ответить. Приходилось повторно запрашивать, держа на контроле. На базе docuwiki создана база знаний с описанием вопросов, архитектуры системы, основных действий второй линии поддержки и администраторов. Не получилось описать настройку создания нового продукта в системе, т. к. он создавался полупрограммируемым способом и описывать надо было совместно с программистами.
Вывод: Создавать базу знаний жертвуя лояльностью клиента неправильный шаг. Если бизнес на это идет, то на поддержку ложится дополнительная нагрузка в виде оправданий недоработок и сдерживания дополнительного негатива клиентов.
Подбор персонала
Что хотелось: Для подбора сотрудников к себе в команду я подошёл методически: выбрал список компетенций и составил вопросы к телефонному собеседованию по этим компетенциям. Сначала все вопросы имели одинаковый вес и после пары собеседований я понял, что все кандидаты одинаково подходят на вакансию и такими темпами можно долго нанимать людей. Всем компетенциям был дан вес и процесс пошёл веселее.
Таблица компетенций первой линии:
Данный шаблон был отправлен на согласование с руководством, но отклика «применять-не применять» не вернулось.
Первого человека я взял по рекомендации от старого коллеги без шаблона (проработал неделю). Следующего взял шеф. Остальных трёх (девушек) набирали частично с моим участием, но не спрашивая моих рекомендаций и не интересуясь мнением. Допуска к материальной мотивации и бюджетам я не получил.
Что получилось: Набран весёлый, но не полностью соответствующий требованиям отдел, где сотрудники отлично справляются с работой первой линии, но для более глубокого погружения в систему требуются правильно составленный процесс обучения и передачи знаний. При мне люди с ЗП выше средней по рынку на глазах теряли нематериальную мотивацию из-за неверно поставленного процесса работы.
Вывод: готовьте для нового замотивированного сотрудника объем работы. Иначе это плохо влияет на лояльность к работодателю и к системе. Понимайте процесс мотивации персонала — как материальный, так и не материальный.
Процесс работы
Что хотелось: После запуска системы мы начали сталкиваться с первыми трудностями: старый интерфейс выглядел ужасно и работал против всех понятий user-friendly. Основной поток звонков пошёл по недовольству именно интерфейсом, а не бизнес-процессом. Пользователи элементарно не могли завести заявку. До вновь набранной команды разработки сразу были доведены основные ошибки, но тут мы столкнулись со второй проблемой: не было коммуникации не только с теми, кто поддерживал систему извне, но и и не было расстановки приоритетов по исправлению системы — все силы были брошены на написание новых функций и продуктов, не получалось выделить человека для латания элементарных ошибок, которые сократили бы количество звонков вдвое.
Что получилось: После очередного указания на проблемы руководству оно все-таки дало разрешение на внесение правок и поток звонков уменьшился втрое.
Вывод: налаживайте процесс приоритизации задач, обсуждая порядок взаимодействия с группой разработки.
Сталкиваясь с каждой из вышеназванных задач я каждый раз приходил к руководству с предложениями оптимизации процессов и попыткой скоординировать своё видение с видением компании, но всегда натыкался или на занятость руководителя(системная проблема) или получал ответ «пока так» и «мы не хотим излишней формализации». Также я знал, что планируется расширение отдела до 5 человек и видел, что надо понять как будет происходить управление процессом поддержки и ресурсами. Я уже начал подозревать, что начальство изменило планы насчёт меня из-за моих постоянных попыток внедрить изменения. Меня уже не называли координатором или начальником, я не участвовал в митингах, связанных с развитием системы.
После этого я решил подготовить стратегию и понять, тем ли я вообще занимаюсь. Потому что начальник не коммуницировал со мной в плане стратегии совсем. Стратегия была направлена сразу на вышестоящее лицо в ИТ в Москву и, для меня картинка моей работы поменялась. Потом стратегия была направлена из Москвы вниз к моему прямому начальству и я попал в конфронтацию с местным начальником.
Вывод: Проанализируйте стратегию подразделения. Определите краткосрочные и долгосрочные планы. Обсудите видение с руководством.
Вторая часть «марлезонского балета»
После вышеописанного эпизода со мной практически прекратил общаться прямой начальник. И я начал подумывать об уходе. Изначально я видел интересный проект, который после преодоления определённых трудностей при правильном взаимодействии всех участников процесса можно было успешно завершить, получив крепкий мотивированный отдел поддержки с правильными KPI и с чёткими показателями на выходе, понятными безнесу. Сейчас же, я увидел, что отдел сваливается в рутину еще толком не развившись. В приоритете стали две задачи — ответы на звонки и описание багов(не доработок) системы посредством gitlab, которые исправляли разработчики.
Отдельная история — процесс «тестирования», как его называл руководитель, который тоже предлагалось выполнять нам. Понимания этих процедур ни у кого не было, как и отдельного тестировщика. Функциональное тестирование «черного ящика» без каких-либо показателей эффективности всей командой перед релизом. Никаких других методов не применялось. Набранный персонал не мог эффективно участвовать в тестировании из-за нехватки как бэкграунда в сфере разработки, так и из-за отсутствия процесса обучения. Даты релизов постоянно фейлились или релизы выкатывались без тестирования.
Вывод: отдел не может эффективно заниматься двумя крупными процессами параллельно. Будет два процесса идущих кое-как.
Конфронтация продолжалась. Руководитель умудрился зафейлить все элементы менеджмента, которые я считал важным:
- стратегическое видение
- контроль
- управление
- мотивация
Также были озвучены такие волшебные пункты, как «лояльность к компании в виде прихода на работу раньше и ухода позже»
Окончательно потеряв мотивацию, я пригласил начальника на беседу о моем дальнейшем положении в компании и решении ее покинуть, где мне было сказано, что отдел в текущем своём виде всех устраивает и развития отдельных элементов не планируется. В итоге я покинул компанию, получив практический опыт в попытке реализации своего видения работы отдела поддержки.
Что получилось: опыт, опыт и еще раз опыт.
Вывод: Какие ошибки я для себя зафиксировал:
- Чтобы не тратить время — фиксируйте и согласовывайте планы заранее
- Четко определите стратегию. Если возникают недомолвки — решайте вопросы сразу
- Примите решение по комфортному рабочему процессу для себя. Находите компромисс между своей материальной и не материальной мотивацией
- Возможно я слишком много времени потратил на понимание этих вещей. Многое лежало на поверхности
Также хотелось бы услышать от коллег ваши истории внедрения и нюансы, на которые я, по неопытности, не обратил внимания.