Эволюция службы поддержки сотрудников: почему так непросто сделать просто
Привет! Меня зовут Сергей Вещугин, я руковожу направлением технической поддержки пользователей и развитием службы 911 в Контуре. 911 — это название сервиса поддержки сотрудников. А их у нас сейчас больше 12 тысяч человек.
В этом году сервису 911 исполнилось 10 лет. И эта написанная в честь юбилея статья расскажет вам про менеджмент и организацию процессов в нем.
Расскажу про ключевые организационные изменения в 911, отраженные на схеме выше: как действовали с учетом масштабов компании и «пересобирали» процессы в «полете», а также почему сделать просто иногда получается и непросто, и небыстро.
Просто один email для всех
В далеком 2012 году, когда в компании было всего 1500 сотрудников, уже возникали такие вопросы: «Куда и кому написать, чтобы тебе гарантировано помогли решить вопрос здесь и сейчас?». Компания была как большая семья, где многое решалось на личных связях или потому что «так исторически сложилось».
Основная сложность была в отсутствии информации, кто какие вопросы может решать, а кто должен и может помочь, если ответственного нет на месте.
Было много почтовых адресов для получения поддержки в разных сервисах. Даже была идея сделать для каждого отдельный почтовый ящик: есть проблема, смотришь адрес сервиса в справочнике, пишешь заявку на <имя_сервиса>@kontur.ru и тебе сразу помогают профильные сотрудники.
Такая схема хороша для помогающих, но не прозрачна для пользователей, к тому же проблема может быть совсем не в сервисе.
Начинает УИТ
В 2014 году решили попробовать новую схему: один адрес для всех сервисов и проблем УИТ. Но для ее реализации надо было организовать первую линию, которая занималась бы быстрым распределением заявок. На первых порах этим занимались все системные администраторы по очереди. Сказать, что все они были в «восторге», значит, ничего не сказать. Приходилось оперативно узнавать, кто может помочь с почтой, с покупкой техники, с порталом компании и прочими сервисами компании… И все это пока на уровне одного управления.
Уже через несколько месяцев был выделен отдельный сотрудник, занимающийся распределением и быстрым решением типовых задач. Начала появляться единая база знаний.
Многие процессы тогда пришлось менять, менять принцип «так исторически сложилось», менять привычки сотрудников ходить напрямую к специалистам, менять мнение, что пользователь может и подождать/потерпеть, он ведь коллега.
Присоединяется УОФ
Эксперимент с единым адресом для всех вопросов и проблем в УИТе довольно быстро получил признание у сотрудников компании. Многие начали спрашивать: «А когда другие проблемы можно будет решать через 911?» Больше всего интересовали организационно-бытовые вопросы.
Пришло время договариваться с руководством УОФ о работе в новой системе и по новым правилам. В кратчайшие сроки была создана первоначальная база знаний: по каким вопросам в какой отдел управления нужно направлять заявки. Даже то, что большая часть управления не работает на компьютерах, не стало критичным препятствием, а привело к изменению внутренних процессов и выделению ответственных сотрудников за определенный функционал.
Как потом оказалось, это было одно из самых лояльных подразделений по подключению к 911.
Убеждаем оставшихся
Дальше больше: собрали статистику, какие вопросы задают чаще, поняли, кого надо подключать в первую очередь и пошли договариваться.
ВЫ НЕ ПОНИМАЕТЕ, У НАС СВОЯ СПЕЦИФИКА, ЭТО РАБОТАТЬ НЕ БУДЕТ!
Примерно такой была первая реакция большинства руководителей, к кому мы приходили с предложением начать принимать и обрабатывать заявки через один общий адрес. Приходилось разбираться во всех процессах каждого подразделения, находить плюсы от перехода.
В результате таких раскопок нашли и исключили дублирование функционала, научились работать с конфиденциальной информацией. Оказывается, наши сотрудники легко могут написать в заявке размер своей зарплаты или соседа, паспортные данные, арендную ставку или договор подряда, номер и чуть ли не пин-код карточки и много еще чего интересного. Все эти данные необходимо бережно хранить и ограничивать к ним доступ.
Но были и те, кто не собирался подключаться к 911, так как уже работали в других системах обработки заявок.
Чтобы избавить заявителя от дополнительных проблем и не переводить его на другой адрес, мы в разное время пробовали:
создавать заявки за пользователя в нужной системе, передавая туда всю историю по заявке;
пересылать заявку на почту нужной техподдержки, вкладывая всю имеющуюся информацию;
выступать связующим звеном между техподдержкой и заявителем, контролируя весь процесс решения вопроса;
создавать у себя базу знаний по типовым вопросам и решать проблему на своей стороне.
Но почти все это стало неактуальным после перехода на единый инструмент техподдержки. Хотя все еще бывают ситуации, что вопросы в 911 не решаются и нужно пойти в другой канал.
Просто заплатим премии отличникам
После объединения нескольких управлений появилась необходимость в едином понимании качества решения заявок, единых критериев сервисности и клиенториентированности. Выстроить любые процессы можно при прямой заинтересованности и мотивации отдельных сотрудников. Но 911 — это не один сотрудник или отдел, это команда из специалистов разных подразделений с абсолютно разным функционалом.
Мы научились формировать простые, четкие ожидания у пользователей за счет критериев по решению заявок для тех, кто их обрабатывает. Например, что в течение 2 рабочих часов вам обязательно ответит сотрудник, который будет заниматься решением заявки. Или что время на решение ограничено и при его изменении вам сообщат новый срок.
Сначала скорость
Так в 2016 году появился рейтинг 911, при выполнении которого и сейчас выплачивается премия из общего бюджета ДОС. Состав и расчет рейтинга постоянно менялся за все время существования в зависимости от того, какие узкие места было необходимо улучшить в текущий момент. В первую очередь надо было научится быстро идентифицировать проблему, найти кто должен ее решать, решить или сообщить сроки решения. Поэтому скорость или рейтинг просрочки находится под контролем до сих пор.
Глобально рейтинг призван мотивировать на увеличение скорости обработки заявки и качества предлагаемого решения.
Затем качество
В прошлом году критерии снова изменились: как и всегда, смотрим на просрочку и оценки пользователей, к этому добавили два важных на текущий момент критерия — решение вопроса с первого раза без переоткрытия и факт привязки знания для выставления новых сроков решения и дальнейшей детальной аналитики.
Для любителей цифр и конкретики несколько графиков — как менялись основные показатели:
Просто поменяем трекер 911
«Выживает не самый сильный из видов и не самый умный, а тот, кто лучше других реагирует на изменения». Чарльз Дарвин
Подозрение
В конце 2020 года у нас появились сильные подозрения, что MS SCSM — ядро нашей системы — не будет развиваться. Выпускались только критичные обновления, сменилось несколько команд разработки, а также мы заметили другие косвенные признаки. Мы начали искать подходящее для нас по функционалу и бюджету решение.
Рассматривали больше 20 различных платформ техподдержки, самые подходящие из них тестировали на совместимость с уже имеющейся инфраструктурой: порталы самообслуживания, кабинет сотрудника, отчетность и прочее. Наравне с продуктами мировых компаний рассматривали продукт, использующийся нашим УКС — WIC.
Окончательную точку в вопросе выбора поставили события февраля 2022 года, когда использование всех зарубежных вариантов закончилось, так и не успев начаться. А если уж и выбирать среди своих, то выбирать надо самых близких.
Выбрали, а что дальше?
Железобетонными было 3 условия для успешного перехода:
Пользователи не должны заметить изменения
Качество поддержки не должно ухудшиться
Устоявшиеся процессы поддержки в подразделениях не должны сломаться
Весь 2022 год мы занимались подготовкой к переходу:
Анализировали и актуализировали все процессы 911, начиная от подачи заявки до решения комплексной заявки несколькими отделами.
Написали, переписали, протестировали API для взаимодействия с имеющимися порталами, кабинетом сотрудника.
Перестроили работу сотрудников первой линии, обучив их работать в новом инструменте и создавать необходимую базу знаний.
Написали несколько статей о новом инструменте, собрали обратную связь и первые требования по доработкам.
Создавали ролевую модель для исключения доступа к коммерческой, персональной или другой тайне, которая могла быть отражена в рамках заявки.
Замучали разработчиков WIC вопросами:
А почему так? А нам надо вот так, можно? А если очень надо?
Поехали!
С января 2023 года мы начали плавный переход на новую платформу. Первые заявки начали регистрироваться в новой системе, НО ни пользователи, ни специалисты поддержки этого практически не заметили, так как для них изменилась только нумерация инцидентов — остались одни цифры. Все привычные инструменты продолжали работать. А мы проверяли, все ли работает корректно: регистрация заявок, комментарии по заявке, процесс решения, оценки и прочие технические нюансы.
4 месяца мы постепенно поднимали количество заявок, регистрируемых в новой системе. 28 апреля мы технически перевели работу с заявками в WIC. Оставалось перевести всех специалистов техподдержки на новый инструмент и обучить всем тонкостям и лайфхакам работы в нем.
Еще 4 месяца мы обучали всех специалистов (больше 400 человек), показывали инструкции, создавали знания для базы знаний, собирали обратную связь и пожелания. Проверяли, не сломаются ли внутренние процессы в подразделениях. Если где-то ломались, то совместно искали варианты решения.
1 октября отключили возможность обрабатывать заявки в старом портале. Теперь всю работу с заявками необходимо было делать в WIC.
Мы уже приехали? А сейчас?
Следующие 5 месяцев, с октября 2023 по февраль 2024, мы восстанавливали и перестраивали некритичные процессы. Поняли, что даже в самый жаркий момент перехода просрочка, скорость обработки и другие показатели практически не изменились.
Куда дальше?
На ближайшие год-полтора мы поставили перед собой следующие задачи в хронологическом порядке:
Создать отчеты Bi для специалистов 911 — для оперативного отслеживания скорости и качества решения заявок
Доработать WIC — обработка заявки должна полностью происходить в web
Продолжить развитие знаний WIC как основного помощника в решении заявки и в контроле времени решения
Доработать оценку сервисности с использованием ИИ и наработок УКС
Обновить Регламент 911
Пользуясь случаем, хочется сказать большое спасибо тем, кто стоял у истоков 911 и играл свою роль в развитии единого сервиса внутренней техподдержки. А про то, как эти 10 лет развивались интерфейсы, можно прочесть в статье Эволюция службы поддержки сотрудников: интерфейсы.
