И что из этого вышло, а что не вышло…

Кадр из сериала “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. Количество зарегистрированных заявок;
2. Количество закрытых заявок;
3. Количество выполненных регламентно-профилактических задач;
4. Оценка пользователями работы специалиста по заявкам.

Поэтому интригу я решил создать за счет введения в систему мотивации дополнительных критериев, как то:

1. Премиальный коэффициент 1,5 увеличивающий баллы на 50% для двух ударников в каждой из категорий (регистрация, закрытие заявок, выполнение профилактик).
2. Депримирующий коэффициент 0,5, который уменьшает баллы на 50% для самого слабого специалиста в категории.
3. Коэффициент субъективной оценки качества ведения ServiceDesk в течение месяца. Предполагалось, что такую оценку будет ставить один из специалистов, которому отводилась на этот месяц роль “диспетчера” (за эту роль полагался дополнительный премиальный коэффициент)
4. Депримирующий коэффициент 0,5 за невыполнение норматива профилактических задач (40 задач в месяц). Данный норматив отсутствовал у трех самых крутых специалистов.
5. Депримирующий коэффициент 0,5 за отклонение от регламентов выполнения профилактических задач. При этом вычтенные у провинившегося сотрудника баллы плюсовались тому сотруднику, который обнаружил отклонение от регламентов.

Еще в систему мотивации были защиты коэффициенты за составление статей в блог по всяким офисным премудростям (таким способом мы одно время приучали парней корректно составлять инструкций для пользователей), а также за участие в проектах. Как все эти коэффициенты были связаны между собой я сейчас не буду рассказывать – все это не имеет особого значения, так как от данной системы в скором времени пришлось отказаться.

Введя новые правила, я в очередной раз увеличил премиальный фонд и сделал рассылку. Изучив новые правила игры, Илья Муромец (напомню еще раз, что имена сотрудников изменены) сразу увидел ее несовершенство и заявил, что он “хакнет” премиальную систему, чтобы показать ее недостатки. Для этого в течение всего месяца Илья делал как можно больше профилактических задач, чтобы остальные коллеги не имели возможности выполнить свой норматив по профилактикам и получили понижающий коэффициент к премии (а значит, уменьшили свою премию и увеличили его). У Ильи это почти получилось, и в марте он получил самую большую премию:

Таблица 2 (кликабельно). Расчет премии за работу с системой ServiceDesk в марте 2014 года. Здесь и далее: N – количество заявок, P – цена в баллах, K – повышающий (понижающий) коэффициент.

Правда запала на апрель у Ильи уже не хватило (ну или коллеги устроили ему темную – история умалчивает), и премия за апрель напоминала старые отчеты:

Таблица 3 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2014 года.

На третий месяц уже Добрыня Никитич оставил всех с носом, сделав чуть ли не все профилактики в одно лицо. У Добрыни для этого было техническое преимущество – он живет в Новосибирске и просыпался тогда на 3 часа раньше Московского офиса (сейчас уже на 4). Видимо, запас времени и территориальная отдаленность от основного коллектива лишили Добрыню чувства самосохранения, и в мае 2014 года он оттяпал половину всего премиального фонда:

Таблица 4 (кликабельно). Расчет премии за работу с системой ServiceDesk в апреле 2014 года.

Четвертого месяца работы по такой системе мотивации не было – в массах пошло роптание о том, что существующая система только демотивирует. В принципе, сейчас я понимаю, что такая система поощрения могла прижиться только в нездоровом коллективе, где каждый только и думает о том, как бы насолить другим. В нашем же случае, парни не хотели оценивать качество работы других с системой заявок, не хотели “стучать” на соседа, если обнаруживали косяк в его работе (пожурить – безусловно, но в данном случае любая ошибка приводила к уменьшению премии), да и в целом, часть людей предпочитала просто не браться за какие-то задачи, если ошибки при их исполнении могут привести к уменьшению премии. В итоге, чтобы не доводить людей до греха (в массах уже пошли разговоры о том, чтобы устроить темную в том числе и мне за искусное управление компанией), спустя три месяца пришлось отказаться от:

1. Прямого участия коллег в оценке результатов труда и во влиянии на размер премии;
2. Любых демотивирующих коэффициентов (за исключением объективной оценки качества работы пользователями);
3. Любых привилегированных сотрудников в системе премирования.

После этого в системе “соцсоревнования” осталось только три категории с двумя лидерами в каждой из категорий и с оценкой качества работы по заявкам пользователями. До апреля 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 лет) система учета заявок в моей компании стала более информативной – в ней стали регистрироваться все возникающие задачи, и большинство задач в системе стали закрываться своевременно. Сейчас в системе заявок в любой момент времени можно получить более-менее актуальную информацию о текущем статусе выполняемых задач. Но главное – теперь можно более-менее объективно измерять качество наших услуг: сколько заявок сделали, сколько времени их делали, по каким сервисам были заявки, какая динамика со временем у наших услуг, какие затраты на поддержку каждого сервиса, кто у нас ударник труда и так далее. К примеру, можно сравнить результаты работы за два последних года:

	2017 год	2016 год
Устранено инцидентов	2535	3267
Выполнено запросов на обслуживание	2373	1411
Оказано консультаций	148	113
Выполнено регламентных задач	3940	4138
Исправлено ошибок	340	190
Инцидентов устраненных с нарушением сроков	432	569
Запросов на обслуживание выполненных с нарушением сроков	200	196
Медианное время устранения инцидентов	37 минут	78 минут
Медианное время выполнения запросов на обслуживание	43 минуты	61 минута

Таблица 8. Сравнение результатов работы технической поддержки в 2016 и 2017 годах.

В предыдущем абзаце вы наверняка обратили внимание на использование оборота “более-менее”. Дело в том, что точность учета в системе заявок все еще оставляет желать лучшего. Так, из таблицы выше следует, что в 2017 году по сравнению с 2016 у нас количество инцидентов уменьшилось на 741, а запросов на обслуживание наоборот – выросло на 962. Причина такого изменения проста – заявки, приходящие по почте, у нас автоматически регистрируются как инцидентные. В 2016 году парни просто редко проверяли тип заявки при ее закрытии, а в 2017 стали делать это чаще, что и привело к такому перераспределению. Такая же петрушка наблюдается и с определением категорий задач – не всегда специалисты техподдержки корректно связывают задачу с затрагиваемым ей сервисом. Если бы у нас в техподдержке были диспетчеры и менеджеры, то они бы отслеживали подобные ошибки в процессе работы, проводили разъяснительную работу, и точность нашего учета была бы выше.

Также, по отчетам выше, у нас просто гора заявок с нарушением сроков выполнения при том, что реальных нарушений сроков у нас единицы (ну ладно, ладно – десятки). Большинство же нарушений связано с расхождением особенностей формального учета задач и их реального исполнения. Например:

1. Есть задачи, оперативное выполнение которых нанесет ущерба клиенту больше, чем пользы. К примеру, обнаружили что один из вентиляторов на сервере крутится плохо, но при этом сервер/диски не греются и причин бежать и судорожно менять вентилятор (останавливая работу компании) нет. Соответственно, заявка висит в ожидании удобного момента для проведения работ, а в системе заявок получается “висяк”.
2. Не всегда специалисты ставят заявку на “удержание” (hold), когда задача выходит из нашей зоны ответственности. К примеру, получили жалобу на качество связи, провели диагностику – проблема у провайдера, передали ему обращение. В этот момент заявку можно/нужно ставить на “hold”, чтобы таймер остановился (поскольку сеть провайдера вне нашей зоны ответственности). В реальности же парни этого зачастую не делают, ожидая, что в скором времени провайдер все починит. Если же провайдер решает проблему долго, то получаем просрочку в нашей системе учета.
3. Часть заявок все еще не закрывается вовремя, даже когда выполнена. Просто иногда такое случается – нужно было убежать с работы пораньше, сделал заявку и занялся другой задачей, забыл закрыть вовремя. Ну и некоторые специалисты (видимо, с сильно большой зарплатой), несмотря на все мои ухищрения, все еще работают с системой заявок постольку-поскольку.
4. Пиковая нагрузка. Когда какая-то эпидемия выкашивает половину нашего коллектива, а у клиентов сотрудники наоборот пышут здоровьем, переполнены энергией и хотят именно сегодня разобраться с проблемами, до которых раньше у них не доходили руки. В такие дни не до соблюдения всех формальностей в ServiceDesk – успеть бы на звонки ответить.
5. Часть заявок являются мини-проектами, на которые времени уходит больше, чем отводится для стандартных заявок. К примеру, клиент пишет, что собирается открыть новый офис, заявка автоматически регистрируется и остается “висеть” до банкета связанного с открытием офиса.
6. Некоторые заявки по своей сути являются проблемами (в рамках терминологии ITIL). К примеру, когда база 1С у одного единственного сотрудника “подвисает” на несколько секунд в день или, когда первый запуск Outlook у пользователя проходит дольше обычного – в момент обращения в техподдержку ошибка уже не наблюдается, но поскольку она возникает регулярно, специалисту нужно найти и устранить ее причину. На поиски таких причин зачастую нужны недели, но в системе заявок самый большой срок, отводимый на выполнения заявок равен 3 дням.

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

Успехов!

Иван Кормачев
Компания «Департамент ИТ»
http://www.depit.ru