Pull to refresh
0

Последний рубеж: как работает вторая линия техподдержки в ритейле

Reading time 6 min
Views 24K


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

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

Чем вторая линии поддержки отличается от первой


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

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

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

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

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



Как это работает на практике


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

При постановке в очередь анализируется срочность и критичность заявки — если магазин столкнулся с серьезной проблемой, то заставлять покупателей и персонал ждать решения 40 минут никто не будет, и работа над инцидентом начнется незамедлительно. В договорах между ритейлерами и сервисными компаниями всегда прописывается определенный уровень SLA для срочных задач. Таким образом, если компания отдельно указала, что проблемы определенного типа нанесут серьезный урон бизнесу, то такие заявки будут обрабатываться инженерами вне общей очереди.

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

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



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

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

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

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

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

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



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

Еще одним примером подключения инженеров второй линии к решению заявок, которые не могут быть решены на уровне первой линии поддержки, часто являются сбои серверного оборудования. Оно требует значительной компетенций для обслуживания, а сбои в его работе не всегда выражаются в явном выходе из строя аппаратных компонент сервера. Поэтому заявка передается на вторую линию технической поддержки и ее специалисты пытаются устранить инцидент. Он может выражаться в нарушении теплового режима эксплуатации сервера, выходе из строя отдельных элементов (сбои в работе памяти, сбойные сектора на жестких дисках, выход из строя элементов питания кэш памяти), нарушении работы серверного ПО (СУБД, ERP, BI) или ошибках во взаимодействии с другими, внешними по отношению к этому серверу, системами.

Заключение: почему ритейлеры не обслуживают инфраструктуру сами


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

Ничто не мешает ритейлерам заниматься развитием собственных ИТ-департаментов, однако работа с технологиями — это не бизнес таких компаний, их задача продавать товары.

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

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

Другие материалы по теме:


Tags:
Hubs:
+10
Comments 4
Comments Comments 4

Articles

Information

Website
www.pilot.ru
Registered
Founded
Employees
201–500 employees
Location
Россия