Интересными наблюдениями и рекомендациями, по результатам двухлетнего проекта трансформации службы поддержки, делится Ричард Сикора (Richard Sykora) (оригинал статьи A Support Center Transformation to Shift Left).
Основная цель проекта была обеспечить «shift left» организации поддержки. Ричард пишет:
"Cтратегия сдвига влево, на самом деле, очень проста. В левой части спектра у вас есть наименее затратная модель поддержки ваших конечных пользователей. В ней обычно нет людей, которые помогают пользователям, он широко известен, как нулевой уровень или самообслуживание. В центре спектра у вас может быть вспомогательный персонал, однако, это скорее сценарий «много-к-одному», например, чат. Дальше вправо по спектру соотношение уже «один-к-одному» между конечными пользователями и службой поддержки. Помимо прочего, сюда стекаются также проблемы сторонних поставщиков, инженеров, архитекторов и других. Рисунок ниже представляет собой схему сдвига влево и относительной его стоимости. Одна из важнейших задач сдвига влево – переместить обращения, обычно заключённые в правых колонках, как можно левее, снабдив их необходимыми инструментами, знаниями и ресурсами. Как видно на графике, по мере снижения числа контактов, снижается и их стоимость. Главная же цель состоит в том, чтобы переместить влево все обращения из вашей организации. Перемещённая влево задача – наименее дорогостоящая для службы поддержки».
Основные моменты, на которые обращает внимание Ричард – это:
1. Команда
- «Прежде чем изменения начнутся, вам нужно инвестировать в отличную команду. Ваша команда должна быть с вами заодно. Я всецело поддерживаю дискуссии и обмен мнениями на стадии планирования. Но в конце дня, после многих компромиссов КОМАНДА должна прийти к абсолютно единому мнению и всячески его поддерживать, чтобы работать, как единое целое».
- «Мы менялись быстро и решили не «резать хвост по частям», а сделать сразу всё. Вместо того чтобы вводить все изменения постепенно, мы менялись одновременно на всех подпроектах. Поскольку ведущая команда была полностью едина, было легко заставить всех остальных принять эти перемены».
2. Разделение задач
- «Вместо того, чтобы вся команда работала над каждой деталью сообща, мы разделились и добились успеха. Таким образом, каждому руководителю службы поддержки были назначены различные аспекты проекта трансформации».
- «Трудно мыслить стратегически, попутно отвечая за ежедневную текучку. Мы осознали разницу в стратегическом мышлении и процессе в сравнении с оперативными однообразными задачами. Стратегическая точка зрения заключается в создании долгосрочных целей и задач, основанных на достижении желаемого результата. Оперативная деятельность состоит из повторяющихся действий, которые являются повседневными основными процессами, которые достигают тактических целей, SLA и т. д. Лидеры должны выделять нужное количество времени на стратегическое мышление, чтобы согласовывать цели и задачи, управлять изменениями и выстраивать показатели для достижения целей и чёткого видения того, как измерять успех».
3. Определение цели
- «Вам нужно знать, где вы находитесь, куда идёте и как планируете туда добраться. Оценка текущей эффективности сервисной стратегии, включающей процесс, людей и инструменты, является обязательной. Вы не можете измерить успех, если не установили конечную цель».
- «Мы не только хотели добиться успеха во внедрении ведущих в своём классе инструментов, отраслевых процессов и лучших практик, мы также хотели продвигать информацию среди наших заказчиков и изменить саму культуру предоставления технической поддержки».
4. Знайте своих пользователей
-
«Однажды, исследуя вопрос формирования службы поддержки на будущее, мы наткнулись на очень интересный набор фактов, который подтвердил, что мы находимся на правильном пути. Существует огромное количество исследовательских данных, статей и много другого о миллениумах (Millennials, поколение Y, поколение «некст», «сетевое» поколение, эхо-бумеры) на рабочем месте и том, как они относятся к поддержке. Одним из источников, которые произвели на меня впечатление, было исследование JD Powers, в котором участвовали 600 000 пользователей. Исследование показало, что миллениумы чаще используют продукт повторно или взаимодействуют с брендом после того, как проблема решена. Кроме того, эти люди предпочитают самообслуживание для разрешения проблем, по возможности, избегают контакт-центров, к тому же, они хотят получить услугу в удобное им время. Если они будут вынуждены поговорить с человеком, они сделают это, но предпочтут этого избежать».
Несмотря на кажущуюся очевидность приведённых рекомендаций, корректное их применение может серьёзно помочь не только в трансформации технической поддержки, но и при проведении любого изменения, а особый вес им придаёт результат проекта:
«Наша компания растёт, и наша клиентская база растёт на 8% из года в год. Однако благодаря успешной работе над обработкой обращений, наш фактический входящий объём обращений остаётся без изменений или снижается из года в год. Кроме того, мы наблюдаем сокращение операционных расходов более чем на 1 млн. долл. США, несмотря на рост числа заказчиков».
* Данный проект был отмечен такими наградами как Stevie Awards, ASP top ten website awards, HDI Service Improvement award и Knowledge-Centered Service award
Тут как бы две статьи на разные темы. Первая про сдвиг влево в работе службы поддержки. Я ожидал, что речь пойдет про DevOps – когда люди из эксплуатации, технологи, привелкаются к разработке продукции на максимально ранней стадии. Но нет. Речь идет о самообслуживании. Для наглядности приведу аналогию – это все равно, что заниматься самолечением(selfservice) на основе медицинской энциклопедии(knowledge base). Результаты будут такими же. Но и затраты существенно ниже – не нужен медперсонал, поликлиники и больницы. Правда похоронна служба слегка вырастет, но это такое, не существенное.:)
Вторая – перечисление принципов, известных уже чуть ли не столетие – teamwork, Delegation, целеполагание, фокус группа или целевая группа потребителей. Хотя, за реят можно порадоваться – их еще столько "открытий" ждет!