Сервис деск в телекоме: 6 фатальных ошибок в автоматизации поддержки и как их избежать

Размножились неконтролируемые связи между обращениями, оборудованием, подрядчиками? Ведете проекты отдельно от эксплуатации? Или так и не выстроили процессы работы с массовыми инцидентами?

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

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

Ошибка №1. Сервис деск — только для приема и обработки заявок

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

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

Полноценный сервис деск объединяет весь контур обслуживания:

Учет склада и запчастей. Комплектующие привязаны к конкретному оборудованию и объектам, а остатки видны до выезда инженера.

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

Обслуживание оборудования и плановые работы. Регламентные задачи создаются по расписанию и сохраняются в истории конкретного элемента инфраструктуры.

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

Интеграция с мониторингом и биллингом. Например, Zabbix может автоматически создать инцидент еще до обращения клиентов, а открытый API — синхронизировать данные с системами фиксации платежей.

Аналитика и дашборды. Показатели по заявкам, SLA, трудозатратам и рентабельности клиентов собираются автоматически.

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

Ошибка №2. Разбирать массовые аварии по одной заявке

Классика жанра: на магистрали произошла авария. За полчаса приходит тысяча одинаковых обращений от абонентов одного района.

Что происходит, если система не умеет работать с массовыми инцидентами:

• операторы отвечают каждому отдельно, хотя причина одна;

• инженеры получают десятки одинаковых по сути задач;

• руководитель не видит сразу масштаб проблемы и не может оценить, сколько времени и ресурсов потребует восстановление.

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

Правильно выстроенный процесс выглядит иначе — рассмотрим на примере системы ITSM 365. Сигнал о проблеме может прийти откуда угодно — из системы мониторинга, от дежурной смены NOC, по звонкам клиентов. Распознав, что множество обращений связаны одной причиной, в системе можно автоматически сгруппировать их вокруг одного глобального инцидента, отделив от единичных, не связанных с аварией жалоб. 

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

№3. Не знать историю оборудования

Еще один пример: инженер приезжает на объект без контекста происходящего. Он не знает, что установлено на узле, какие комплектующие меняли до этого, кто обслуживал оборудование раньше, сколько раз оно уже выходило из строя и как пробовали чинить. Без этих данных инженер работает вслепую.

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

ITSM 365 хранит в карточке элемента инфраструктуры все данные об оборудовании: конфигурацию, связи с услугами и клиентами, обслуживание, замену комплектующих и аварии. Связанные с активом заявки добавляются в карточку автоматически, поэтому специалист быстрее находит причину повторных поломок. 

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

№4. Не учитывать плановые работы в эксплуатационном контуре

Даже крупные компании до сих пор держат регламент обслуживания в таблицах — телекому это может влететь в копеечку. 

Цепочка сбоев плюс-минус одинаковая.

• Плановые работы на узле связи забыли внести в график → регламентное обслуживание пропущено. 

• Окно работ не согласовали с B2B-клиентом заранее → авария или перерыв в самый неподходящий момент. 

• Абонентов не уведомили о плановом отключении → вместо ожидаемого сервиса они получают сбой. 

• На объект выехали, но не проверили наличие нужного ЗИП → работы срываются или откладываются. 

• Бригаду на выезд забыли назначить вовремя → регламент есть в плане, а исполнителя нет. 

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

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

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

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

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

Ошибка №5. Измерять работу только количеством закрытых заявок

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

На что смотреть вместо этого:

• Доля заявок с возобновлением. Если инженеру приходится возращаться к проблеме повторно или тем более ехать, это не только прямые издержки, но и возможный сигнал о снижении качества обслуживания.

• Соблюдение SLA по типам заявок и клиентам. Не общий процент по компании, а в разрезе конкретных договоров и объектов, где чаще всего случаются просрочки.

• Повторные обращения по одному узлу/оборудованию. Если один и тот же объект дает заявки снова и снова, значит, устраняют симптом, а не причину.

• Среднее время устранения. Показывает, насколько быстро реально решается проблема, а не просто сколько раз клиент написал.

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

Подробнее об аналитике в ITSM 365 — в статье на Хабре.

Ошибка №6. Проекты отдельно от эксплуатации

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

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

• Список смонтированного оборудования и его параметры. Какая именно модель установлена, с какими настройками, кто поставщик — вместо карточки актива остается только акт выполненных работ в архиве.

• История согласований с клиентом. На этапе строительства обсуждали, например, особые требования к резервированию канала, а поддержка об этом не в курсе и сталкивается с претензиями.

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

• Контакты и договоренности с бригадой монтажников. Если через полгода нужно уточнить нюанс монтажа, найти концы уже сложно.

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

Подробнее о том, как управлять проектами и сервисом в ITSM 365 — в статье на Хабре

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

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

Что в итоге?

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

А иногда дело не в объеме, а в потолке функционала: компания уже использует сервис деск, но упирается в его границы — система просто не позволяет настроить процессы под нишевую телеком-специфику, будь то регламентные работы на узлах связи, учет ЗИП или сложные схемы SLA для B2B-клиентов.

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

Хотите узнать, как ITSM 365 закрывает телеком-специфику, задать вопросы и протестировать сервис деск бесплатно в течение двух недель — напишите через форму на сайте или на cs@itsm365.com. Покажем, расскажем, посоветуем.