Через тернии к SLA: как техподдержке быстрее закрывать заявки сотрудников
Специалисты технической поддержки компании каждый день берут в работу десятки заявок: компьютер не включается, программа не загружается, браузер не открывается (вдруг), принтер не печатает. В общем, все как обычно.
В такой рутине важно не только закрыть заявку и решить проблему сотрудника, но и уложиться в определенное время, то есть держать SLA на нужном уровне и не давать ему стремительно падать вниз.
Все это привычные условия, но скоро появится и новая проблема ― ускоренное и для многих компаний обязательное импортозамещение софта.
Просто представьте: сотрудники десятилетия работали в родных Windows и Microsoft Office, а тут надо перейти на непривычный российский софт, офисные пакеты и даже операционные системы. Процесс адаптации обещает быть нелегким: кнопки непонятные, программы лагают, весь шаблон рутинных операций ломается. В результате поддержку засыпят тикетами.
Эта статья для всех, кто работает с заявками сотрудников, утопает в рутине и отвечает за сорванные дедлайны. Разберем несколько уровней организации работы с заявками и рассмотрим решения, как закрывать тикеты быстрее, чтобы выполнять SLA.
Это база ― автоматизация заявок и Service Desk
Это базовый уровень в организации работы с заявками. Для этого используют решения класса Service Desk или Help Desk. Не будем долго останавливаться, это и правда база: сотрудники заполняют по шаблону заявку, специалисты техподдержки получают тикет и берут в работу.
Уже на этом этапе, как правило, бизнес устанавливает SLA для саппорта. Теперь техподдержка автоматизированно работает с заявками, а компания отслеживает скорость решения проблем.
Однако большую часть данных на этом уровне приходится собирать вручную. Сотрудники заполняют только базовую информацию в заявке и при этом не всегда корректно. Поэтому специалисты техподдержки звонят для сбора информации, пишут на почту и подключаются удаленно к рабочему месту сотрудника. Из-за этого техподдержка медленнее закрывает заявки, к тому же сотруднику приходится отрываться от работы. В общем, процесс неоптимальный.
Мы в «Инферит ИТМен» провели исследование и выяснили, что до 30% заявок специалисты техподдержки возвращают обратно сотрудникам для уточнения информации. Это существенно снижает скорость и «роняет» SLA.
Проблема в том, что у специалиста технической поддержки нет прямо здесь и сейчас информации о состоянии конечного устройства. Чтобы решить ее, нужно переходить на новый уровень и автоматизировать сбор данных с конечных устройств.
1 уровень для продвинутых ― получать информацию с конечных устройств
Итак, уровень «вижу тикет ― беру тикет ― опрашиваю сотрудника ― закрываю тикет» прошли, переходим на новый, где специалист техподдержки самостоятельно получает детальную информацию о ПК сотрудника и быстрее закрывает заявки.
Представим типичную ситуацию: специалисту техподдержки на первой линии падает тикет ― «Не запускается офисный пакет» или «Отвалился ViPNet Client». Инвентарной информации о конфигурации ПК и установленном ПО нет. Тут можно или связываться с сотрудником и вручную собирать данные или получить самостоятельно.
Есть два основных варианта, как получить инвентарную информацию:
1. Удаленный рабочий стол
Это инструмент самой операционной системы, который позволяет администрировать удаленный компьютер в режиме реального времени.
Плюсы
Это стандартный инструмент, который не нужно выбирать с рынка, закупать и осваивать работу в нем. Достаточно использовать протокол RDP и интернет-сеть.
Минусы
Если архитектура гео-распределенная, в ней есть закрытые периметры, порты или протоколы, то подключиться по RDP и собрать данные с конечного устройства встроенными инструментами ОС не получится. Снова придется звонить сотруднику, идти самому к устройству и решать вопрос вручную.
2. ПО для сбора инвентарной информации с устройств
Это софт, который собирает информацию со конечных устройств: ПК, рабочие станции, серверы, подключенное оборудование, сетевое оборудование.
Программа автоматически собирает и инвентаризирует данные, благодаря чему у специалиста технической поддержки всегда есть необходимая информация о конфигурации устройства, установленном софте, версиях ОС и других программах. Это помогает быстро и без лишних хлопот решить проблему сотрудника, закрыть заявку и повысить SLA.
Если же вы раньше не проводили инвентаризацию определенных параметров, таких как тот же корневой сертификат, то ее можно собрать за пару секунд с помощью этого ПО.
Плюсы
Это гибкий инструмент, который собирает данные с заданной периодичностью, поэтому у специалиста техподдержки всегда под рукой нужная информация. Если же необходимо получить специфичные данные для закрытия заявки, можно сделать это в режиме реального времени.
Также такой софт может собирать данные с любой инфраструктуры, даже если у компании филиалы в разных городах и странах и есть жесткие ограничения от ИБ.
Это вездеход в мире сбора данных ― никакие порты и каналы ему не помеха.
Минусы
ПО для сбора данных нужно купить с рынка и согласовать на него бюджет. Также специалисты техподдержки должны освоить новый софт.
Одним из решений для сбора и инвентаризации данных является «Инферит ИТМен».
Это полностью российская разработка без использования Open Source. Продукт работает на конвергентной (смешанной) архитектуре, которая обходит инфраструктуру любой сложности, и собирает данные с помощью гибких скриптов (сенсоров).
Карточка устройства с инвентарной информацией в «Инферит ИТМен»
Итак, первый уровень преодолели. Теперь специалисты техподдержки получают информацию с устройств, не нужно тратить время на созвоны с сотрудниками, а заявки получается закрывать значительно быстрее. SLA растет, а рутина уменьшается.
Что же дальше?
2 уровень для искушенных ценителей ― CMDB и цифровая копия инфраструктуры
А дальше в компании выстраивают цифровую копию ИТ-инфраструктуры и CMDB.
CMDB ― это Configuration Management Data Base, то есть база данных управления конфигурациями, которая включает в себя элементы ИТ-инфраструктуры и отражает их связи. Иными словами, это «сердце» любой ITSM.
Одна из главных особенностей CMDB — учет не только оборудования и ПО, но и конфигурационных единиц (КЕ).
Компоненты CMDB
Все это звучит трудозатратно и зачем тогда это нужно, если инвентарную информацию и так уже собираем? Рассмотрим на простом примере.
В техническую поддержку прилетает тикет ― отвалился компонент ключевого в компании ПО (например, nanoCAD). Специалисты берут заявку в работу, собирают с помощью софта данные, находят ошибку, устраняют проблему и закрывают заявку. Все отлично ― как говорится, закрыли и забыли.
Проходит примерно неделя ― прилетает тикет с той же самой проблемой. Повторили алгоритм. А затем эта ситуация повторяется с определенной периодичностью и становится регулярной. Это раздражает и сотрудников, которые не могут выполнять работу, и техподдержку.
По нашему опыту, именно после череды подобных проблем бизнес и задумывается о формировании подробной Базы знаний, которую держат в актуальном состоянии. Затем создает цифровую копию инфраструктуры и внедряет инструменты для автоматизации процессов.
Это помогает решать проблемы комплексно и эффективно, особенно когда парк устройств увеличивается, открываются филиалы в разных городах. Тут важно выстроить стабильный процесс и полностью контролировать все свое ИТ.
На уровне бизнеса понятно, а зачем вся эта системность и CMDB специалистам технической поддержки? Это позволяет видеть не отдельные тикеты, а историю взаимодействия и взаимосвязи, хранить информацию не только о заявке, но и о привязанных к ней устройств.
Для этого нужно решение, чтобы поставлять данные со всей ИТ-инфраструктуры в CMDB. И снова есть два варианта: использовать инструменты Service Desk или специальный софт такой. Например, в «Инферит ИТМен» реализован единый конвейер обработки данных, который собирает, детализирует, нормализует, обогащает данные и поставляет в CMDB.
Конвейер обработки данных в «Инферит ИТмен»
Инструменты Service Desk не собирают информацию со сложной инфраструктуры и специфичного софта. Также требуется много ручных операций, чтобы приводить данные к единому виду. Если не устранять дубли, цифровая копия инфраструктуры будет слишком далека от оригинала.
Итак, грамотно выстроенный CMDB помогает технической поддержке быстрее закрывать заявки и делать это с меньшей рутиной и меньшим количеством ошибок. Это самый эффективный и прямой путь к идеальному SLA.
Напоследок расскажем несколько реальных кейсов, когда нужно было закрывать заявки, а ПО для сбора инвентарной информации не было.
Кейсы: заявки есть, а данных нет
Все эти случаи мы взяли из практики наших клиентов ― именно после таких историй они пришли к нам за решением.
Сетевые ограничения
Системному администратору на второй линии поддержки приходит тикет ― у сотрудника отвалилось системное ПО и нет информации по версии ОС.
Сисадмин пытается подключаться с помощью удаленного рабочего стола и собрать данные, чтобы устранить проблему. И тут сюрприз ― закрытый протокол и подключиться не получилось. Софта для сбора данных в компании нет, снова нужно звонить и «интервьюировать» сотрудника.
Все отключено
На стороне сотрудника отключен Microsoft Management Console, а также доступ к файловой системе и удаленному реестру. Стандартные инструменты ОС не работают, подключиться к удаленному столу не выходит. Ну, что сказать ― приплыли. Тут справится только софт, который работает на локальном конечном устройстве и сможет достать нужную информацию.
Географическое разнообразие
Конечные устройства находятся в Таджикистане и Узбекистане, а техническая поддержка базируется в Москве. Стандартные инструменты ОС не позволяют преодолеть это расстояние, пройти все каналы передачи данных и получить информацию для закрытия заявки.
В общем, все кейсы сводятся к одному ― при любом ограничении, закрытых портах, каналах и сложной инфраструктуре у поддержки остается только один путь: звонок сотруднику и поход ногами к устройству. А это приводит к тому, что закрытие заявок растягивается во времени и негативно влияет на показатели.
Чтобы техподдержка работала эффективно, без утомительной рутины и ошибок ― нужно внедрять софт для сбора и инвентаризации данных. Это единственный проверенный путь к идеальному SLA.
