И что из этого вышло, а что не вышло...
Кадр из сериала “The IT Crowd (Компьютерщики)”
Чем занимается техническая поддержка, и насколько эффективно она работает? — чем дальше в своей работе я отдалялся от задач техподдержки, тем сильнее беспокоил меня этот вопрос, пока в 2013 году я окончательно не осознал, что совершенно не представляю, чем занимаются эти “бездельники”. Нет, я не сомневался, что парни в технической поддержке ответственно относятся к своей работе (и это подтверждали отзывы клиентов), но вот повышается ли качество наших услуг со временем или уменьшается, какие задачи возникают в технической поддержке и в каких количествах, кто делает львиную долю работы — этого я не понимал. Моим попыткам разобраться в положении дел в техподдержке и посвящена данная статья. Но для начала небольшой экскурс в историю:
Как качество работы технической поддержки измеряют в мире, и почему этот способ меня не устраивал
Проблема, с которой я столкнулся, не нова. Тридцать лет назад англичане задались таким же вопросом — “а чем, собственно, занимаются айтишники в госучреждениях, и нужно ли их столько?”. Англичане подошли к этому вопросу фундаментально и провели исследование, итогом которого стали 30 (тридцать) томов рекомендаций по организации эффективной работы ИТ-службы и методам контроля ее работы. Со временем, эти рекомендации уменьшились до 5 томов и получили мировую известность под названием “методология ITIL”. Вся суть методологии сводится к закреплению за специалистами узкой зоны ответственности: диспетчеры регистрируют заявки, есть первая, вторая, третья линия технической поддержки, есть менеджеры инцидентов, менеджеры проблем, менеджеры изменений, менеджеры конфигураций и так далее — список различных ролей можно продолжать. Такая узкая нарезка на роли, с одной стороны, ограничивала задачи отдельного специалиста (а значит, упрощала его работу и повышала личную производительность), а с другой — делала невозможной работу ИТ-отдела без связывающей все роли системы учета, через которую одни специалисты как по конвейеру могли бы передавать задачу другим. Именно необходимость использования учетной системы (которую англичане назвали гордым словом ServiceDesk) и помогает контролировать занятость специалистов и измерять различные метрики производительности всего ИТ-отдела в целом и отдельных сотрудников в частности.
У предложенной тридцать лет назад англичанами методики единственный недостаток — она нацеливает специалистов на выполнение своих рабочих процедур, а не на решение проблем клиента. Глобально, методика является процессно-ориентированной, а не клиентоориентированной, и недостаток предлагаемых в ней способов организации труда описывал еще Аркадий Райкин в своей миниатюре “кто сшил костюм?”. К примеру, согласно методике ITIL, пользователь не может связываться со специалистами напрямую, а должен сначала пройти через диспетчера, который зарегистрирует его обращение в системе, передаст его специалисту и будет контролировать дальнейшее исполнение. Такое усложнение содержит в себе разумное зерно — если регистрацию заявок переложить на самих технических специалистов, то часть обращений просто-напросто не будет зарегистрирована, потому что этот ритуал по большому счету не нужен ни пользователям, ни техническим специалистам.
В принципе, все недостатки методологии ITIL не являются таковыми, если у тебя достаточно денег, чтобы содержать штат диспетчеров, менеджеров и, непосредственно, специалистов технической поддержки, а также, если ты уверен, что твои пользователи от тебя никуда не денутся. Но у меня небольшая ИТ-аутсорсинговая компания, и вся техническая поддержка — это 10 специалистов. Содержать выделенных диспетчеров для нас (не говоря уже о менеджерах) — это непозволительная роскошь. Кроме того, наши клиенты привыкли получать на свои вопросы незамедлительный и компетентный ответ. Если бы я обязал наших пользователей при звонках в техподдержку смиренно ждать ответа диспетчера, чтобы тот сначала зарегистрировал заявку, а потом передал ее специалисту, то я мог бы потерять добрую половину клиентов уже через полгода. Поэтому единственное, что мне оставалось — это стимулировать специалистов технической поддержки самостоятельно вести учет всех без исключения поступающих к ним обращений, что я и попытался сделать:
Моя первая безрезультативная попытка что-то измерить, наводка
Тут стоит сказать, что в 2013 году в моей компании уже работала система учета задач технической поддержки (далее по тексту ServiceDesk). Правда использовалась она номинально — в ней автоматически регистрировались письменные обращения пользователей, и создавались регламентно-профилактические задачи, но получаемые по телефону заявки в систему попадали редко, особенно, если они решались в рамках одного звонка. Кроме того, страдала и сама культура работы с системой — специалисты могли месяцами (а иногда и годами) не закрывать уже выполненные заявки, а об актуализации текущих статусов задач и вовсе не шло речи. В том виде, в котором система работала в 2013 году, что-либо измерить в ней просто не представлялось возможным.
Первое что приходило на ум в плане стимулирования специалистов регистрировать и закрывать заявки в ServiceDesk — это выплачивать специалистам премию за каждую зарегистрированную и закрытую заявку. Но такой подход, очевидно, скрыто мотивирует специалистов создавать как можно больше причин у пользователей для обращения в техническую поддержку, в то время как, куда правильнее стимулировать специалистов работать так, чтобы у пользователей не было причин для обращения в техническую поддержку. По этой причине я решил сделать премиальный фонд фиксированной ежемесячной суммой, которая не зависит от количества заявок. Предполагалось, что фиксированная сумма будет делиться между всеми сотрудниками технической поддержки исходя из пропорции зарегистрированных и выполненных заявок каждым из специалистов. То есть, если за месяц каждый специалист зарегистрировал и выполнил по одной заявке, то все специалисты делят премиальный фонд поровну. При этом предполагалось, что одна выполненная заявка будет равна двум зарегистрированным заявкам в рамках этих пропорций.
Первый премиальный фонд по заявкам я сделал символическим — 10 000 р./месяц. Чтобы парни не относились к этому как к какой-то системе премирования, которая определяет приоритеты в работе, я назвал данную систему «соцсоревнование» и в мае 2013 года разослал всем письмо следующего содержания:
“Парни, мы медленно, но верно движемся к разработке системы поощрения и мотивации.
Цель системы мотивации для компании – повышение внутренней эффективности. Цель системы мотивации для каждого из вас – получить возможность объективной оценки своего вклада в компанию и дать возможность зарабатывать вам больше, делая больше и делая качественней.
Понимаю, что оценивать объем проделанной работы в нашей сфере — это неблагодарная задача. По этой причине (дабы не наказывать невиновных и не награждать непричастных), для начала хочется объективно разобраться в текущей загрузке и провести аналитику по всем клиентам, стоящим по ним задачам, текущей удовлетворенности заказчиков и причин неравномерных объемов работ.
Для этих целей мы проводим небольшое “социалистическое” соревнование с призом в 10 000 р., который будет разделен между всеми участниками соревнования на основе следующих принципов: одна зарегистрированная заявка – 5 баллов, одна закрытая заявка – 10 баллов. Курс балла определяется как призовая сумма, деленная на сумму всех баллов по всем зарегистрированным и закрытым за месяц заявок. Например, если за месяц было закрыто 900 заявок и было зарегистрировано 200 заявок, то курс балла получается 1 рубль, стоимость одной зарегистрированной заявки — 5 рублей, а одной закрытой — 10 рублей.
Соответственно, в ваших интересах в июне месяце регистрировать (и закрывать) как можно больше заявок. Зашли в офис клиента, вам задали 3 вопроса, вы на них ответили – зарегистрировали 3 заявки, закрыли их и заработали в соцсоревновании 45 баллов, которые потом будут сконвертированы в рубли. Пожалуйста, регистрируйте любой писк пользователей – чтобы в дальнейшем мы смогли сделать целостную систему премирования, нам нужно видеть все возникающие сейчас задачи.”
Итогом первого месяца «соцсоревнования» стало… барабаннная дробь… ничего. В работе специалистов не поменялось ровным счетом ничего — парни не стали регистрировать больше заявок, выхватывать заявки друг у друга, биться за скорейшее закрытие заявок, чтобы сделать больше. Все работали, как привыкли работать, а когда за заявки выдали пусть и смешные, но дополнительные деньги, ни у кого из парней не дернулась бровь, и не покатилась слеза умиления. Наверное, нормальный бизнесмен пришел бы в ярость от того, что подчиненные не оценили его барскую щедрость, но меня такое положение дел только раззадорило, и я решил наблюдать за дальнейшим поведением специалистов и постепенно повышать бюджет соцсоревнования. Через 3 месяца бюджет поднялся до 15 000 р./месяц, еще через три — 20 000 р./месяц. Повышение бюджета все также не вызывало никакой реакции специалистов, и распределение премии из месяца в месяц было примерно одинаковым (реальные имена сотрудников тут и далее заменены по их просьбе):
Таблица 1 (кликабельно). Расчет премии за работу с системой ServiceDesk в ноябре 2013 года.
Каждый месяц я делал рассылку с результатами «соцсоревнования», а парни получали небольшие премии за ведение заявок, говорили спасибо и убегали с премией в руке на обед в столовую. Если судить по размерам премий, то все работали примерно одинаково, но при этом в системе премирования учитывались только заявки пользователей, и не учитывались выполняемые сотрудниками регламентно-профилактические задачи. Наверное поэтому, спустя где-то 8 месяцев от начала «соцсоревнования» я получил письмо от одного из сотрудников следующего содержания:
“А может разделить фонд на профилактики и обычные заявки, а то как-то уныло, никакой интриги?”
Интрига, нужна интрига! И тут
Мертворожденная система мотивации за работу с системой заявок, читеры, бунт на корабле
Месяца два, в свободное от чтения хабра время, я думал о том, как разнообразить систему “соцсоревнования” и внести в нее интригу. Для начала, я собрал все объективные критерии для оценки работы по заявкам, которые можно было измерять на тот момент. Их получилось немного:
- Количество зарегистрированных заявок;
- Количество закрытых заявок;
- Количество выполненных регламентно-профилактических задач;
- Оценка пользователями работы специалиста по заявкам.
Поэтому интригу я решил создать за счет введения в систему мотивации дополнительных критериев, как то:
- Премиальный коэффициент 1,5 увеличивающий баллы на 50% для двух ударников в каждой из категорий (регистрация, закрытие заявок, выполнение профилактик).
- Депримирующий коэффициент 0,5, который уменьшает баллы на 50% для самого слабого специалиста в категории.
- Коэффициент субъективной оценки качества ведения ServiceDesk в течение месяца. Предполагалось, что такую оценку будет ставить один из специалистов, которому отводилась на этот месяц роль “диспетчера” (за эту роль полагался дополнительный премиальный коэффициент)
- Депримирующий коэффициент 0,5 за невыполнение норматива профилактических задач (40 задач в месяц). Данный норматив отсутствовал у трех самых крутых специалистов.
- Депримирующий коэффициент 0,5 за отклонение от регламентов выполнения профилактических задач. При этом вычтенные у провинившегося сотрудника баллы плюсовались тому сотруднику, который обнаружил отклонение от регламентов.
Еще в систему мотивации были защиты коэффициенты за составление статей в блог по всяким офисным премудростям (таким способом мы одно время приучали парней корректно составлять инструкций для пользователей), а также за участие в проектах. Как все эти коэффициенты были связаны между собой я сейчас не буду рассказывать — все это не имеет особого значения, так как от данной системы в скором времени пришлось отказаться.
Введя новые правила, я в очередной раз увеличил премиальный фонд и сделал рассылку. Изучив новые правила игры, Илья Муромец (напомню еще раз, что имена сотрудников изменены) сразу увидел ее несовершенство и заявил, что он “хакнет” премиальную систему, чтобы показать ее недостатки. Для этого в течение всего месяца Илья делал как можно больше профилактических задач, чтобы остальные коллеги не имели возможности выполнить свой норматив по профилактикам и получили понижающий коэффициент к премии (а значит, уменьшили свою премию и увеличили его). У Ильи это почти получилось, и в марте он получил самую большую премию:
Таблица 2 (кликабельно). Расчет премии за работу с системой ServiceDesk в марте 2014 года. Здесь и далее: N — количество заявок, P — цена в баллах, K — повышающий (понижающий) коэффициент.
Правда запала на апрель у Ильи уже не хватило (ну или коллеги устроили ему темную — история умалчивает), и премия за апрель напоминала старые отчеты:
Таблица 3 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2014 года.
На третий месяц уже Добрыня Никитич оставил всех с носом, сделав чуть ли не все профилактики в одно лицо. У Добрыни для этого было техническое преимущество — он живет в Новосибирске и просыпался тогда на 3 часа раньше Московского офиса (сейчас уже на 4). Видимо, запас времени и территориальная отдаленность от основного коллектива лишили Добрыню чувства самосохранения, и в мае 2014 года он оттяпал половину всего премиального фонда:
Таблица 4 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2014 года.
Четвертого месяца работы по такой системе мотивации не было — в массах пошло роптание о том, что существующая система только демотивирует. В принципе, сейчас я понимаю, что такая система поощрения могла прижиться только в нездоровом коллективе, где каждый только и думает о том, как бы насолить другим. В нашем же случае, парни не хотели оценивать качество работы других с системой заявок, не хотели “стучать” на соседа, если обнаруживали косяк в его работе (пожурить — безусловно, но в данном случае любая ошибка приводила к уменьшению премии), да и в целом, часть людей предпочитала просто не браться за какие-то задачи, если ошибки при их исполнении могут привести к уменьшению премии. В итоге, чтобы не доводить людей до греха (в массах уже пошли разговоры о том, чтобы устроить темную в том числе и мне за искусное управление компанией), спустя три месяца пришлось отказаться от:
- Прямого участия коллег в оценке результатов труда и во влиянии на размер премии;
- Любых демотивирующих коэффициентов (за исключением объективной оценки качества работы пользователями);
- Любых привилегированных сотрудников в системе премирования.
После этого в системе “соцсоревнования” осталось только три категории с двумя лидерами в каждой из категорий и с оценкой качества работы по заявкам пользователями. До апреля 2015 года такая система работала без изменений:
Таблица 5 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2015 года.
Единственным достижением системы мотивации на начало 2015 года стала повальная регистрация всех обращений пользователей в системе заявок. А вот со своевременным обновлением статусов заявок и их закрытием в системе дела обстояли все также плохо. При изучении заявок в ServiceDesk в середине месяца, волосы на голове вставали дыбом от объемов задач, на которые мы, не то забили, не то как-то делаем, не то уже давно сделали. При этом, если пнуть специалистов техподдержки (что я и делал в конце каждого месяца), то заявки тут же закрывались в огромных количествах и картина происходящего становилась куда более лицеприятной. Но в 2015 года такое положение дел мне окончательно надоело, и я решился на еще один набег на систему премирования:
Борьба за своевременную актуализацию статуса задач в системе заявок
Чтобы побороться за своевременную актуализацию статусов и закрытие задач в системе заявок, я дополнительно разделил в системе премирования заявки пользователей на два типа — закрытые вовремя и закрытые с нарушением сроков выполнения. Заявки, закрытые вовремя, я сделал в три раза ценнее всех остальных задач. При этом коэффициенты за лидерство оставались только по трем категориям — зарегистрированные заявки, закрытые в срок и профилактические задачи. Заявки, сделанные с нарушением сроков, не имели коэффициентов за лидерство. По новой системе, для получения хорошей премии уже было недостаточно весь месяц ударно работать, а в конце месяца скопом закрыть сделанные задачи — нужно было в течение всего месяца поддерживать информацию в системе ServiceDesk в актуальном состоянии.
Памятуя о своих прошлых управленческих “успехах”, прежде чем что-то менять в сложившийся системе премирования, я для начала оценил размеры изменений по старым периодам. В таблице 6 приведен расчет премии по новой системе за апрель 2015 года (в таблице 5 выше содержится расчет за этот же период по старой системе). Дополнительно в отчете я вывел число “висяков” — заявки, которые были просрочены и не закрыты в отчетном периоде:
Таблица 6 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2015 год по новой системе учета.
Картина в отчетах вырисовывалась грустная — количество просроченных и зависших заявок превышало количество закрытых вовремя заявок. Однако, несмотря на всю грусть ситуации, новая система премирования не изменяла принципиально текущее распределение премиального фонда, а значит, не угрожала новыми конфликтами со специалистами техподдержки. Поэтому, перекрестившись, я сделал оповещение об изменении в системе премирования (на этот раз без изменения бюджета) и стал наблюдать.
Хотелось бы тут написать, что изменения не заставили себя ждать и, с введением новой системы премирования, жизнь наконец-то наладилась. Но в реальности, парни узнав об изменениях в системе премирования напряглись, закрыли большинство «зависших» заявок и… стали копить новые. Заявок, сделанных с просрочкой и “висяков”, стало несколько меньше, но не настолько, чтобы можно было заявлять о каких-то серьезных победах на этом фронте. Причина же отсутствия сколь-либо значимых результатов оказалось банальной — часть сотрудников готовы были пренебречь лишней тысячей рублей премии, лишь бы не напрягаться с качественным ведением заявок в ServiceDesk, а некоторые индивиды даже целенаправленно жертвовали качеством ведения заявок в системе, чтобы младшие коллеги получили премию побольше.
Дабы подтолкнуть работать с системой заявок тех специалистов, которым премия от работы с системой не нужна, я сделал премиальный фонд динамическим, когда размер фонда изменяется в зависимости от соотношения закрытых в срок задач к общему числу задач в системе заявок (закрытых за период и “зависших”). С таким подходом получалось, что сотрудники, которые плохо ведут ServiceDesk (не закрывают вовремя заявки, оставляют зависшие заявки), уменьшают премию не только себе, но и своим коллегам. Расчет мой был на то, что специалисты, которым премия не нужна, не заходят портить отношения с коллегами, которым премия все же нужна, и будут стараться более-менее качественно вести учет заявок — коварный план, не так ли? :)
Чтобы нововведение не ухудшило существующие условия, я рассчитал тот уровень “премиальной базы”, при котором текущий премиальный фонд (30 000 р.) соответствовал бы текущему качеству ведения ServiceDesk — вышло 47 000 рублей. Сделав очередную рассылку, я снова стал ждать и, спустя пару месяцев, увидел куда более фундаментальные в качественном отношении изменения — количество просроченных заявок и “висяков” уменьшилось в системе вдвое:
Таблица 7 (кликабельно). Расчет премии за работу с системой ServiceDesk в октябре 2015 года с динамическим премиальным фондом.
На этом вносить изменения в систему мотивации я перестал. В последующие два года я один раз поднял премиальную базу, а все остальное время только своевременно считал и исправно платил премию, а также наблюдал за развитием событий.
Результаты, что получилось и что не получилось на текущий момент
Благодаря системе премирования, за 4 года (уже практически за 5 лет) система учета заявок в моей компании стала более информативной — в ней стали регистрироваться все возникающие задачи, и большинство задач в системе стали закрываться своевременно. Сейчас в системе заявок в любой момент времени можно получить более-менее актуальную информацию о текущем статусе выполняемых задач. Но главное — теперь можно более-менее объективно измерять качество наших услуг: сколько заявок сделали, сколько времени их делали, по каким сервисам были заявки, какая динамика со временем у наших услуг, какие затраты на поддержку каждого сервиса, кто у нас ударник труда и так далее. К примеру, можно сравнить результаты работы за два последних года:
| 2016 год | 2017 год | |
| Устранено инцидентов | 3267 | 2535 |
| Выполнено запросов на обслуживание | 1411 | 2373 |
| Оказано консультаций | 113 | 148 |
| Выполнено регламентных задач | 4138 | 3940 |
| Исправлено ошибок | 190 | 340 |
| Инцидентов устраненных с нарушением сроков | 569 | 432 |
| Запросов на обслуживание выполненных с нарушением сроков | 196 | 200 |
| Медианное время устранения инцидентов | 78 минут | 37 минут |
| Медианное время выполнения запросов на обслуживание | 61 минута | 43 минуты |
В предыдущем абзаце вы наверняка обратили внимание на использование оборота “более-менее”. Дело в том, что точность учета в системе заявок все еще оставляет желать лучшего. Так, из таблицы выше следует, что в 2017 году по сравнению с 2016 у нас количество инцидентов уменьшилось на 741, а запросов на обслуживание наоборот — выросло на 962. Причина такого изменения проста — заявки, приходящие по почте, у нас автоматически регистрируются как инцидентные. В 2016 году парни просто редко проверяли тип заявки при ее закрытии, а в 2017 стали делать это чаще, что и привело к такому перераспределению. Такая же петрушка наблюдается и с определением категорий задач — не всегда специалисты техподдержки корректно связывают задачу с затрагиваемым ей сервисом. Если бы у нас в техподдержке были диспетчеры и менеджеры, то они бы отслеживали подобные ошибки в процессе работы, проводили разъяснительную работу, и точность нашего учета была бы выше.
Также, по отчетам выше, у нас просто гора заявок с нарушением сроков выполнения при том, что реальных нарушений сроков у нас единицы (ну ладно, ладно — десятки). Большинство же нарушений связано с расхождением особенностей формального учета задач и их реального исполнения. Например:
- Есть задачи, оперативное выполнение которых нанесет ущерба клиенту больше, чем пользы. К примеру, обнаружили что один из вентиляторов на сервере крутится плохо, но при этом сервер/диски не греются и причин бежать и судорожно менять вентилятор (останавливая работу компании) нет. Соответственно, заявка висит в ожидании удобного момента для проведения работ, а в системе заявок получается “висяк”.
- Не всегда специалисты ставят заявку на “удержание” (hold), когда задача выходит из нашей зоны ответственности. К примеру, получили жалобу на качество связи, провели диагностику — проблема у провайдера, передали ему обращение. В этот момент заявку можно/нужно ставить на “hold”, чтобы таймер остановился (поскольку сеть провайдера вне нашей зоны ответственности). В реальности же парни этого зачастую не делают, ожидая, что в скором времени провайдер все починит. Если же провайдер решает проблему долго, то получаем просрочку в нашей системе учета.
- Часть заявок все еще не закрывается вовремя, даже когда выполнена. Просто иногда такое случается — нужно было убежать с работы пораньше, сделал заявку и занялся другой задачей, забыл закрыть вовремя. Ну и некоторые специалисты (видимо, с сильно большой зарплатой), несмотря на все мои ухищрения, все еще работают с системой заявок постольку-поскольку.
- Пиковая нагрузка. Когда какая-то эпидемия выкашивает половину нашего коллектива, а у клиентов сотрудники наоборот пышут здоровьем, переполнены энергией и хотят именно сегодня разобраться с проблемами, до которых раньше у них не доходили руки. В такие дни не до соблюдения всех формальностей в ServiceDesk — успеть бы на звонки ответить.
- Часть заявок являются мини-проектами, на которые времени уходит больше, чем отводится для стандартных заявок. К примеру, клиент пишет, что собирается открыть новый офис, заявка автоматически регистрируется и остается “висеть” до банкета связанного с открытием офиса.
- Некоторые заявки по своей сути являются проблемами (в рамках терминологии ITIL). К примеру, когда база 1С у одного единственного сотрудника “подвисает” на несколько секунд в день или, когда первый запуск Outlook у пользователя проходит дольше обычного — в момент обращения в техподдержку ошибка уже не наблюдается, но поскольку она возникает регулярно, специалисту нужно найти и устранить ее причину. На поиски таких причин зачастую нужны недели, но в системе заявок самый большой срок, отводимый на выполнения заявок равен 3 дням.
Несмотря на все перечисленные выше недостатки, текущие качество работы специалистов технической поддержки с системой заявок меня устраивает и, что не менее важно, система мотивации по работе с системой заявок устраивает самих специалистов. Конечно, есть еще, что полировать и улучшать, но я считаю куда более правильным сосредоточить свое внимание не на повышении качества учета обращений пользователей, а на том, чтобы причин обращаться в техническую поддержку у пользователей не было. Правда, опыт показал, что с повышением качества работы информационных систем в компаниях, число обращений в техподдержку не меняется, а меняется только характер обращений и сопровождающий их эмоциональный фон. Но это уже совсем другая история…
Успехов!
Иван Кормачев
Компания «Департамент ИТ»
www.depit.ru
