Ещё в далёком и немного сказочном 2021 году одна небезызвестная сеть ресторанов быстрого питания приходила к нам поинтересоваться насчёт аутсорса техподдержки. Обсуждали поддержку центрального офиса и ещё ряд услуг на всякий случай, если будет какой-то пик. Но до контракта тогда дело не дошло, решение отложили и оставили всё как есть. До сами знаете чего.



В 2022-м они вернулись в новом качестве и попросили нас обновить предложение. Они отделялись от глобальной поддержки, меняли домен, локализовывали все сервисы, переходили на Яндекс 360 для бизнеса. Рук не хватало.

Первый сюрприз, который нас ждал, — база знаний. Её не было. Точнее она возможно, и была когда-то, но требовала локализации. То есть по-русски — написания с нуля. Поэтому, вместо того чтобы сразу ворваться и разбирать заявки, перезаливать ноуты, просить включить-выключить и чинить Any key, мы начали писать документацию. Это наше правило — элементарно для того, чтобы клиент не был привязан к аутсорсеру и в любой момент внутри клиента сохранялись все знания.

Начну сначала

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

В данный момент заказчик пользуется тремя спецификациями: удалённая поддержка, центральный офис на месте, администратор MS SQL.

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

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

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

Что мы сделали, когда пришли

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

Для самих пользователей мы с их инженерами разворачиваем каналы доступа через внутренний сайт (обычно корпоративный портал), мессенджер (корпоративный или нет), по телефону и по почте. Хотите Telegram и Skype для бизнеса — пожалуйста, будут там аккаунты.

В прежнее время у них телефонной линии для ИТ-поддержки не было. Мы сделали единый номер, по нему можно позвонить и попасть на инженеров. Звонок принимается, регистрируется, сотрудник первой линии сам заводит тикет во время разговора в ITSM.



Заказчик в ответ попросил дать приоритет руководителям подразделений. Смысл в том, что при массовом сбое включается автоответчик и начинает набираться очередь. Предполагается, что руководителю подразделения нужен отдельный номер, чтобы эту очередь обойти, потому что он будет говорить сразу за множество людей, а не только за себя. В общем, нужна или VIP-линия, или что-то такое. Решили кодом: во время разговора надо нажать секретную комбинацию и звонок поднимется в очереди. На практике они так не заморачиваются, потому что обычно у нас нет очередей в принципе.

Вместо ITSM заказчик решил использовать Директум. Это вообще-то документооборот, но так исторически сложилось, что там ставились тикеты (точнее, их аналоги) для АХО и ещё нескольких типов задач. Вместе с заказчиком мы доработали систему так, что она стала похожа на ITSM. Это значит, что у людей не появилось новых интерфейсов — всё привычно, это такой аналог почты по сути.

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

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

Ну и дальше пользователи стали радоваться:

Локализация от нулевой отметки

В итоге с нуля выстроили сервисную модель техподдержки. Раньше была глобальная поддержка из зарубежного офиса плюс инженеры на местах. Сотрудники ногами ходили к инженерам, чтобы решить проблемы. Не было выстроенной системы приёма и отработки заявок, чётких SLA, разделения линии поддержки, не было единого телефона, куда можно позвонить с проблемой. С нами произошла локализация сервиса. Это сейчас так называется, когда иностранный сервис меняют на отечественный.

Аутсорсинг компания выбрала в сравнении с собственными работами, потому что это быстрее и дешевле, чем обучать своих инженеров в нужном количестве, плюс если размер бизнеса сильно поменяется, то нужно будет увольнять своих инженеров, а это так себе идея. Да и отказаться от аутсорсера сильно проще и быстрее. С аутсорсером очень легко уменьшить объём техподдержки или, наоборот, быстро его нарастить. Сегодня это важно, поскольку ситуация на рынке для бизнеса такова, что никто не знает, что будет дальше. Горизонт планирования примерно неделя. У нас договор с заказчиком гибкий, предполагает уменьшение или увеличение техподдержки в любой момент.

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

Было и несколько экзотических случаев. Система заявок у них работает на базе почты по ФИО и пользователи путали пару раз, условно говоря, однофамильцев Алексея и Александра. Одному доставались документы другого. У нас в наших поставляемых системах такой проблемы нет, но здесь основа обращения — почтовые адреса.



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

Наша база знаний очень помогла онбордить внутренних инженеров (заказчик нанимает и их) — то есть админов, по сути. У них вышел новый человек, почитал нашу базу на Яндекс.Вики и очень быстро во всём разобрался.

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

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