Техподдержка схлопнулась, а тикеты остались. Как мы подхватили саппорт нефтесервисной компании в 2022 году

в 11:32, , рубрики: jira, service desk, аутсорс, Блог компании КРОК, техподдержка, управление проектами

В один прекрасный день ИТ-системы одной нефтесервисной компании превратились в тыкву… После всем известных событий российскую часть предприятия просто отключили от западного ПО и глобальной технической поддержки. Сотрудники остались практически без софта — корпоративные компьютеры заблокировала служба безопасности головной компании. А в арсенале у инженеров не осталось даже сервис-деска.

Техподдержка схлопнулась, а тикеты остались. Как мы подхватили саппорт нефтесервисной компании в 2022 году - 1

Некоторые базы и утилиты заказчик скачал и забэкапил, но далеко не все. Такой «трофейный» софт, конечно, не покрывал всех потребностей, так что многие рабочие процессы нужно было выстраивать заново.

Новая техподдержка: штат или аутсорс

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

Техподдержка схлопнулась, а тикеты остались. Как мы подхватили саппорт нефтесервисной компании в 2022 году - 2

Если опустить детали, то запрос звучал предельно просто: чтобы поддержка заработала, как раньше — привычно и четко.

Начинали с нуля

С этим заказчиком мы уже работали по другим проектам, знали часть инфраструктуры и поэтому смогли быстро включиться в задачу. Начали с аудита, чтобы понять, что есть, чего нет. Не было ничего. Не было даже удаленного подключения: мы вместе с руководством компании выбирали, какой сервис использовать. Обсуждали AnyDesk и другие варианты. Остановились на программе для удаленного доступа Ассистент.

Для Service Desk выбрали самый простой и быстрый вариант — подключили компанию к Jira. Сразу почувствовали себя, как дома — у себя мы давно используем Jira для корпоративных нужд. У нас даже есть отдел, который занимается ее поддержкой и кастомизацией.

Jira крутится в облаке, так что мы просто создаем дополнительные пространства под внешние проекты и доступом с клиентами, привязываем новый номер и настраиваем Skype. Все поддержка запущена — можно принимать заявки. Но тут началось самое интересное.

Бюрократия и никаких инструкций: с чем нам пришлось работать

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

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

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

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

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

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

Техподдержка схлопнулась, а тикеты остались. Как мы подхватили саппорт нефтесервисной компании в 2022 году - 3

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

Часто было непонятно, куда передавать отдельные вопросы. Например, можно ли ставить ПО не из закрытого перечня. Если да, то какое? А если нет, то как помочь сотруднику компании, которому нечем открыть PDF? Подобных «неразрешимых» тикетов со временем становилось больше, так что мы инициировали новую серию совещаний и разработали матрицу эскалации.

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

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

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

Техподдержка схлопнулась, а тикеты остались. Как мы подхватили саппорт нефтесервисной компании в 2022 году - 4

Какие запросы приходят в поддержку

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

Как мы допилили Jira под заказчика

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

Разделили запросы на отдельные группы: Это первая линия, серверная команда, поддержки Exchange и системы управления документами Alfresco. То есть для каждого типа запросов создали свою группу — раздел в Jira, куда переносим обращения к определенным сотрудникам. В Alfresco есть еще и подпункты — один сотрудник отвечает за разработку, а другой за обслуживание. И вопросы к каждому из них должны поступать соответствующие.

Настроили автономную и персонализированную работу с заявками. Мы видим и принимаем все запросы. А вот от нас они уходят строго по адресам, не смешиваются с другими тикетами, и их не видят другие подразделения.

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

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

Техподдержка схлопнулась, а тикеты остались. Как мы подхватили саппорт нефтесервисной компании в 2022 году - 5

Как теперь работает техподдержка

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

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

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

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

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

Автор:
ALomovskikh

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js