В один прекрасный день ИТ-системы одной нефтесервисной компании превратились в тыкву… После всем известных событий российскую часть предприятия просто отключили от западного ПО и глобальной технической поддержки. Сотрудники остались практически без софта — корпоративные компьютеры заблокировала служба безопасности головной компании. А в арсенале у инженеров не осталось даже сервис-деска.
Некоторые базы и утилиты заказчик скачал и забэкапил, но далеко не все. Такой «трофейный» софт, конечно, не покрывал всех потребностей, так что многие рабочие процессы нужно было выстраивать заново.
Схлопывание случилось, конечно, не сразу. Разделение компаний планировалось заранее и заказчик, как мог, подготовился к этому событию. Оставшись наединес болью с задачей по организации локальной техподдержки, они прикинули, во что выльется найм, обучение и содержание инженеров первой и второй линии саппорта, погрустили и сели сочинять ТЗ на аутсорс.
Если опустить детали, то запрос звучал предельно просто: чтобы поддержка заработала, как раньше — привычно и четко.
С этим заказчиком мы уже работали по другим проектам, знали часть инфраструктуры и поэтому смогли быстро включиться в задачу. Начали с аудита, чтобы понять, что есть, чего нет. Не было ничего. Не было даже удаленного подключения: мы вместе с руководством компании выбирали, какой сервис использовать. Обсуждали AnyDesk и другие варианты. Остановились на программе для удаленного доступа Ассистент.
Для Service Desk выбрали самый простой и быстрый вариант — подключили компанию к Jira. Сразу почувствовали себя, как дома — у себя мы давно используем Jira для корпоративных нужд. У нас даже есть отдел, который занимается ее поддержкой и кастомизацией.
Jira крутится в облаке, так что мы просто создаем дополнительные пространства под внешние проекты и доступом с клиентами, привязываем новый номер и настраиваем Skype. Все поддержка запущена — можно принимать заявки. Но тут началось самое интересное.
С одной стороны — проект нужно было делать почти что с нуля, а это всегда интереснее, чем переделывать чужое. С другой — не было ориентиров и требований.
Фактически мы на ходу формировали ТЗ, встречались с заказчиком, обсуждали их пожелания и собирались снова. Это был период постоянных совещаний, после которых мы писали регламенты, инструкции и сценарии решения пользовательских запросов. Сами писали и сами выполняли. Не без бубна, конечно. Трудностей на старте хватало.
Непонятно, как было раньше. Поддержка раньше была заморская, американская: все проблемы российского подразделения компании решались централизованно за рубежом. Ни гайдлайнов, ни инструкций не осталось. Никаких деталей работы мы не знали, кроме того, что запросы писались по-английски и на email.
Работа удаленная, но на оборудовании заказчика. Все ради безопасности: ноутбуки без прямого доступа к инфраструктуре и подключение через VPN. Мы могли вершить судьбы учетных записей, блокировать пользователей и сбрасывать пароли, но, например, хочешь помочь с установкой ПО — берись за бубен.
Нет всех доступов и прав администратора. Нам были недоступны серверы и домены администрирования — безопасность, да. Только LAPS, только сгенерированные временные пароли для определенного компьютера, только хардкор. Так что, например, решить тикеты, связанные с Exchange-серверами при всем желании мы не могли — приходилось много эскалировать.
Бюрократия. Все вышеперечисленное встречалось нам в разных комбинациях и раньше, но такие длинные цепочки согласований — редкость. Нужно выдать сотруднику новую клавиатуру — отправляемся в увлекательный квест на поиски ответственного за материальное обеспечение и пишем заявки, много заявок. Странное занятие для техподдержки, но не сваливать же на сотрудника эту кипу бумаг?
Поначалу мы решали совсем простые запросы вроде смены пароля, ставили программы из специально согласованного списка, а с более сложными запросами отправлялись к специалистам заказчика.
Часто было непонятно, куда передавать отдельные вопросы. Например, можно ли ставить ПО не из закрытого перечня. Если да, то какое? А если нет, то как помочь сотруднику компании, которому нечем открыть PDF? Подобных «неразрешимых» тикетов со временем становилось больше, так что мы инициировали новую серию совещаний и разработали матрицу эскалации.
Со временем стали идентифицировать пользователей, уточнять учетную запись в Active Directory и суть проблемы — собирать анамнез, и решать куда более сложные вопросы. Так, постепенно, шаг за шагом вникли в процессы компании, распутали часть бюрократических перипетий и в итоге четко распределили все виды тикетов между нашими 1 и 2 линией и инженерами заказчика.
Отдельный момент — работа со службой безопасности. Специалисты из этого отдела редко напрямую взаимодействуют с другими сотрудниками, по крайней мере пока речь идет о тикетах, но с ними многое нужно согласовывать.
Работа с ними выстроилась так: отправляем к ним запрос, а они возвращают нам его с внутренним комментарием и описанием возможного решения.
Когда проект только начинался, мы ожидали, что будем иногда получать какие-то экзотические «нефтесервисные» тикеты. Все таки речь о сложном производстве. Но на деле первая и вторая линия поддержки занимается работой офисов, почти никакой отраслевой специфики. В основном это «сезонные» моменты, например, массовая смена паролей. Есть сотрудники, которые не получили или не увидели уведомления, и у них «вдруг» что-то блокируется. И вот каждые три месяца они приходят к нам целыми косяками.
Jira, конечно, дико удобный сервис. Во всяком случае, мы в нем ориентируемся уже как рыба в воде. Но по опыту, и он почти всегда требует какой-то кастомизации под привычные для заказчика процессы и ритуалы. На этом проекте мы тоже кое что изменили для удобства пользователей:
Разделили запросы на отдельные группы: Это первая линия, серверная команда, поддержки Exchange и системы управления документами Alfresco. То есть для каждого типа запросов создали свою группу — раздел в Jira, куда переносим обращения к определенным сотрудникам. В Alfresco есть еще и подпункты — один сотрудник отвечает за разработку, а другой за обслуживание. И вопросы к каждому из них должны поступать соответствующие.
Настроили автономную и персонализированную работу с заявками. Мы видим и принимаем все запросы. А вот от нас они уходят строго по адресам, не смешиваются с другими тикетами, и их не видят другие подразделения.
Подключили инструменты отчетности. В Jira удобная система фильтрации, и при должной настройке она позволяет выгружать только ту информацию, которая необходима.
Ввели систему оценок. Важно, чтобы сотрудники компании всегда могли пожаловаться, хотя на практике они скорее нас хвалят:) По крайней мере из примерно двух тысяч заявок около 500 были с отзывами. Средняя оценка 4,9 и комментарии, как правило, положительные.
Сейчас все работает, как и хотел заказчик — привычно для пользователей (на самом деле стало еще удобнее) и четко в соответствии с SLA. Пользователи обращаются к нам по двум каналам:
Еще есть электронная почта — самый неудобный вариант, но старая служба поддержки принимала заявки только так. Поэтому мы решили оставить этот канал связи. Многие сотрудники к нему привыкли, и до сих пор пишут длиннющие письма, причем на английском, как раньше.
Все эти запросы, независимо от канала, мы переносим в Jira и они отображаются вместе в списке зарегистрированных обращений — типичный Service Desk, как он есть. Конечно, нам было бы удобнее, чтобы пользователи сами заводили все заявки сразу Jira, но тут мы не стали заниматься формализмом и сделали так, как привычнее и удобнее людям.
Если вопрос к нам — связываемся с пользователем в Skype или пишем комментарий на почту. Общаемся, подключаемся, работаем и решаем проблему. Если запрос уровня инженеров заказчика, мы уточняем информацию и переводим на правильного исполнителя. У них тоже все в Jira, удобно и просто.
Некоторые базы и утилиты заказчик скачал и забэкапил, но далеко не все. Такой «трофейный» софт, конечно, не покрывал всех потребностей, так что многие рабочие процессы нужно было выстраивать заново.
Новая техподдержка: штат или аутсорс
Схлопывание случилось, конечно, не сразу. Разделение компаний планировалось заранее и заказчик, как мог, подготовился к этому событию. Оставшись наедине
Если опустить детали, то запрос звучал предельно просто: чтобы поддержка заработала, как раньше — привычно и четко.
Начинали с нуля
С этим заказчиком мы уже работали по другим проектам, знали часть инфраструктуры и поэтому смогли быстро включиться в задачу. Начали с аудита, чтобы понять, что есть, чего нет. Не было ничего. Не было даже удаленного подключения: мы вместе с руководством компании выбирали, какой сервис использовать. Обсуждали AnyDesk и другие варианты. Остановились на программе для удаленного доступа Ассистент.
Для Service Desk выбрали самый простой и быстрый вариант — подключили компанию к Jira. Сразу почувствовали себя, как дома — у себя мы давно используем Jira для корпоративных нужд. У нас даже есть отдел, который занимается ее поддержкой и кастомизацией.
Jira крутится в облаке, так что мы просто создаем дополнительные пространства под внешние проекты и доступом с клиентами, привязываем новый номер и настраиваем Skype. Все поддержка запущена — можно принимать заявки. Но тут началось самое интересное.
Бюрократия и никаких инструкций: с чем нам пришлось работать
С одной стороны — проект нужно было делать почти что с нуля, а это всегда интереснее, чем переделывать чужое. С другой — не было ориентиров и требований.
Фактически мы на ходу формировали ТЗ, встречались с заказчиком, обсуждали их пожелания и собирались снова. Это был период постоянных совещаний, после которых мы писали регламенты, инструкции и сценарии решения пользовательских запросов. Сами писали и сами выполняли. Не без бубна, конечно. Трудностей на старте хватало.
Непонятно, как было раньше. Поддержка раньше была заморская, американская: все проблемы российского подразделения компании решались централизованно за рубежом. Ни гайдлайнов, ни инструкций не осталось. Никаких деталей работы мы не знали, кроме того, что запросы писались по-английски и на email.
Работа удаленная, но на оборудовании заказчика. Все ради безопасности: ноутбуки без прямого доступа к инфраструктуре и подключение через VPN. Мы могли вершить судьбы учетных записей, блокировать пользователей и сбрасывать пароли, но, например, хочешь помочь с установкой ПО — берись за бубен.
Нет всех доступов и прав администратора. Нам были недоступны серверы и домены администрирования — безопасность, да. Только LAPS, только сгенерированные временные пароли для определенного компьютера, только хардкор. Так что, например, решить тикеты, связанные с Exchange-серверами при всем желании мы не могли — приходилось много эскалировать.
Бюрократия. Все вышеперечисленное встречалось нам в разных комбинациях и раньше, но такие длинные цепочки согласований — редкость. Нужно выдать сотруднику новую клавиатуру — отправляемся в увлекательный квест на поиски ответственного за материальное обеспечение и пишем заявки, много заявок. Странное занятие для техподдержки, но не сваливать же на сотрудника эту кипу бумаг?
Поначалу мы решали совсем простые запросы вроде смены пароля, ставили программы из специально согласованного списка, а с более сложными запросами отправлялись к специалистам заказчика.
Часто было непонятно, куда передавать отдельные вопросы. Например, можно ли ставить ПО не из закрытого перечня. Если да, то какое? А если нет, то как помочь сотруднику компании, которому нечем открыть PDF? Подобных «неразрешимых» тикетов со временем становилось больше, так что мы инициировали новую серию совещаний и разработали матрицу эскалации.
Со временем стали идентифицировать пользователей, уточнять учетную запись в Active Directory и суть проблемы — собирать анамнез, и решать куда более сложные вопросы. Так, постепенно, шаг за шагом вникли в процессы компании, распутали часть бюрократических перипетий и в итоге четко распределили все виды тикетов между нашими 1 и 2 линией и инженерами заказчика.
Отдельный момент — работа со службой безопасности. Специалисты из этого отдела редко напрямую взаимодействуют с другими сотрудниками, по крайней мере пока речь идет о тикетах, но с ними многое нужно согласовывать.
Работа с ними выстроилась так: отправляем к ним запрос, а они возвращают нам его с внутренним комментарием и описанием возможного решения.
Какие запросы приходят в поддержку
Когда проект только начинался, мы ожидали, что будем иногда получать какие-то экзотические «нефтесервисные» тикеты. Все таки речь о сложном производстве. Но на деле первая и вторая линия поддержки занимается работой офисов, почти никакой отраслевой специфики. В основном это «сезонные» моменты, например, массовая смена паролей. Есть сотрудники, которые не получили или не увидели уведомления, и у них «вдруг» что-то блокируется. И вот каждые три месяца они приходят к нам целыми косяками.
Как мы допилили Jira под заказчика
Jira, конечно, дико удобный сервис. Во всяком случае, мы в нем ориентируемся уже как рыба в воде. Но по опыту, и он почти всегда требует какой-то кастомизации под привычные для заказчика процессы и ритуалы. На этом проекте мы тоже кое что изменили для удобства пользователей:
Разделили запросы на отдельные группы: Это первая линия, серверная команда, поддержки Exchange и системы управления документами Alfresco. То есть для каждого типа запросов создали свою группу — раздел в Jira, куда переносим обращения к определенным сотрудникам. В Alfresco есть еще и подпункты — один сотрудник отвечает за разработку, а другой за обслуживание. И вопросы к каждому из них должны поступать соответствующие.
Настроили автономную и персонализированную работу с заявками. Мы видим и принимаем все запросы. А вот от нас они уходят строго по адресам, не смешиваются с другими тикетами, и их не видят другие подразделения.
Подключили инструменты отчетности. В Jira удобная система фильтрации, и при должной настройке она позволяет выгружать только ту информацию, которая необходима.
Ввели систему оценок. Важно, чтобы сотрудники компании всегда могли пожаловаться, хотя на практике они скорее нас хвалят:) По крайней мере из примерно двух тысяч заявок около 500 были с отзывами. Средняя оценка 4,9 и комментарии, как правило, положительные.
Как теперь работает техподдержка
Сейчас все работает, как и хотел заказчик — привычно для пользователей (на самом деле стало еще удобнее) и четко в соответствии с SLA. Пользователи обращаются к нам по двум каналам:
- В Skype. Самый удобный и частый вариант для решения срочных тикетов. Видно, кто сейчас в сети, и можно обратиться напрямую.
- По телефону. Тоже удобный вариант, которого у заказчика не было раньше. Им пользуются реже и в основном те, кто не любит долгие переписки.
Еще есть электронная почта — самый неудобный вариант, но старая служба поддержки принимала заявки только так. Поэтому мы решили оставить этот канал связи. Многие сотрудники к нему привыкли, и до сих пор пишут длиннющие письма, причем на английском, как раньше.
Все эти запросы, независимо от канала, мы переносим в Jira и они отображаются вместе в списке зарегистрированных обращений — типичный Service Desk, как он есть. Конечно, нам было бы удобнее, чтобы пользователи сами заводили все заявки сразу Jira, но тут мы не стали заниматься формализмом и сделали так, как привычнее и удобнее людям.
Если вопрос к нам — связываемся с пользователем в Skype или пишем комментарий на почту. Общаемся, подключаемся, работаем и решаем проблему. Если запрос уровня инженеров заказчика, мы уточняем информацию и переводим на правильного исполнителя. У них тоже все в Jira, удобно и просто.
