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

В такой рутине важно не только закрыть заявку и решить проблему сотрудника, но и уложиться в определенное время, то есть держать 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 — учет не только оборудования и ПО, но и конфигурационных единиц (КЕ). 

Все это звучит трудозатратно и зачем тогда это нужно, если инвентарную информацию и так уже собираем? Рассмотрим на простом примере. 

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

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

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

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

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

Для этого нужно решение, чтобы поставлять данные со всей ИТ-инфраструктуры в CMDB. И снова есть два варианта: использовать инструменты Service Desk или специальный софт такой. Например, в «Инферит ИТМен» реализован единый конвейер обработки данных, который собирает, детализирует, нормализует, обогащает данные и поставляет в CMDB. 

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

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

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

Кейсы: заявки есть, а данных нет 

Все эти случаи мы взяли из практики наших клиентов ― именно после таких историй они пришли к нам за решением. 

Сетевые ограничения

Системному администратору на второй линии поддержки приходит тикет ― у сотрудника отвалилось системное ПО и нет информации по версии ОС. 

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

Все отключено 

На стороне сотрудника отключен Microsoft Management Console, а также доступ к файловой системе и удаленному реестру. Стандартные инструменты ОС не работают, подключиться к удаленному столу не выходит. Ну, что сказать ― приплыли. Тут справится только софт, который работает на локальном конечном устройстве и сможет достать нужную информацию. 

Географическое разнообразие 

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

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

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