И что из этого получилось и что не получилось.
Кадр из серии «ИТ-толпа»
Что делает техническая поддержка и насколько она эффективна? — чем дальше в своей работе я отходил от задач техподдержки, тем больше меня беспокоил этот вопрос, пока в 2013 году я наконец не осознал, что совершенно понятия не имею, чем занимаются эти «бездельники».
Нет, я не сомневался, что ребята из техподдержки ответственно относятся к своей работе (и это подтверждают отзывы клиентов), но повышается или снижается со временем качество наших услуг, какие задачи возникают в техподдержке и в каких количествах, кто выполняет львиную работу? доля работы - этого я не понял.
Эта статья посвящена моим попыткам разобраться в положении дел в технической поддержке.
Но сначала немного истории:
Как измеряется качество работы техподдержки в мире, и почему мне этот метод не подошел
Проблема, с которой я столкнулся, не нова.Тридцать лет назад британцы задали тот же вопрос – «чем именно ИТ-специалисты занимаются в госструктурах и есть ли необходимость в таком их количествеЭ» Британцы подошли к этому вопросу фундаментально и провели исследование, результатом которого стали 30 (тридцать) томов рекомендаций по организации эффективной работы ИТ-службы и методам контроля ее работы.
Со временем эти рекомендации сократились до 5 томов и получили мировую известность под названием «Методология ITIL».
Вся суть методологии сводится к закреплению за специалистами узкой зоны ответственности: диспетчеры регистрируют обращения, есть первая, вторая, третья линия техподдержки, есть инцидент-менеджеры, проблемные менеджеры, менеджеры изменений, менеджеры по конфигурации и т.д. и так далее — список разных ролей можно продолжать.
Столь узкое разделение ролей, с одной стороны, ограничивало задачи отдельного специалиста (а значит, упрощало его работу и повышало личную продуктивность), а с другой стороны, делало невозможным работу ИТ-подразделения без системы учета.
соединение всех ролей, благодаря которым одни специалисты конвейера могли передать задачу другим.
Именно необходимость использования системы учета (которую британцы гордо называют ServiceDesk), помогающей контролировать занятость специалистов и измерять различные показатели эффективности работы всего ИТ-подразделения в целом и отдельных сотрудников в частности.
Единственный недостаток метода, предложенного британцами тридцать лет назад, заключается в том, что он ориентирует специалистов на выполнение собственных рабочих процедур, а не на решение проблем клиента.
В глобальном масштабе методология ориентирована на процесс, а не на клиента, а недостаток предлагаемых в ней методов организации работы описал Аркадий Райкин в своей миниатюре « кто сделал костюм? Например, согласно методологии ITIL, пользователь не может обращаться к специалистам напрямую, а должен сначала пройти через диспетчера, который зарегистрирует его запрос в системе, передаст его специалисту и проконтролирует дальнейшее исполнение.
В этом усложнении есть разумное ядро.
- если регистрацию заявок передать самим техническим специалистам, то часть запросов просто не будет зарегистрирована, потому что этот ритуал по большому счету не нужен ни пользователям, ни техническим специалистам.
В принципе, все недостатки методологии ITIL не таковы, если у вас достаточно денег на содержание штата диспетчеров, менеджеров и непосредственно специалистов технической поддержки, а также если вы уверены, что ваши пользователи от вас не ускользнут. Но у меня небольшая IT-аутсорсинговая компания, и вся техподдержка — это 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 году стали это делать чаще, что и привело к такому переделу.
Та же петрушка наблюдается и с определением категорий задач — специалисты техподдержки не всегда правильно связывают задачу с затрагиваемым ею сервисом.
Если бы у нас в техподдержке были диспетчеры и менеджеры, они бы отслеживали подобные ошибки в процессе работы, проводили разъяснительную работу, и точность нашего учета была бы выше.
Также, судя по сообщениям выше, у нас просто гора заявок с нарушениями сроков, при том, что реальных нарушений сроков у нас всего несколько (ну ладно, ладно, десятки).
Большинство нарушений связано с несоответствием формального учета задач и их фактического исполнения.
Например:
- Есть задачи, оперативное выполнение которых принесет клиенту больше вреда, чем пользы.
Например, мы обнаружили, что один из вентиляторов на сервере плохо вращался, но сервер/диски не грелись и не было причин бежать и судорожно менять вентилятор (остановив работу компании).
Соответственно, приложение зависает в ожидании подходящего момента для выполнения работы, а система приложения в итоге «зависает».
- Специалисты не всегда размещают запрос на «холд», когда задача выходит за пределы нашей зоны ответственности.
Например, мы получили жалобу на качество связи, провели диагностику — проблема была в провайдере, и переправили запрос ему.
В этот момент приложение можно/нужно поставить на «холд», чтобы таймер остановился (поскольку сеть провайдера находится вне нашей зоны ответственности).
В реальности ребята часто этого не делают, ожидая, что провайдер скоро все исправит. Если провайдер долго решает проблему, то мы получаем задержку в нашей системе учета.
- Некоторые приложения до сих пор не закрываются вовремя, даже после завершения.
Просто иногда такое случается — пришлось уйти с работы пораньше, оформил заявку и занялся другой задачей, забыл вовремя ее закрыть.
Ну а некоторые специалисты (видимо с очень большой зарплатой), несмотря на все мои ухищрения, до сих пор работают с прикладной системой в той мере, в какой она есть.
- Пиковая нагрузка.
Когда какая-то эпидемия уничтожает половину нашего коллектива, а сотрудники наших клиентов, наоборот, полны здоровья, переполнены энергией и хотят сегодня заняться проблемами, до которых раньше никогда не доходили руки.
В такие дни нет времени соблюдать все формальности в ServiceDesk — лишь бы успеть ответить на звонки.
- Некоторые приложения представляют собой мини-проекты, которые занимают больше времени, чем отведено для стандартных приложений.
Например, клиент пишет, что собирается открыть новый офис, заявка автоматически регистрируется и остаётся «висеть» до банкета, связанного с открытием офиса.
- Некоторые заявки представляют собой проблемы по своей сути (в терминологии ITIL).
Например, когда база данных 1С одного-единственного сотрудника «зависает» на несколько секунд в день или когда первый запуск Outlook у пользователя занимает больше времени, чем обычно, ошибка наблюдается уже не в момент обращения в техподдержку, а поскольку возникает регулярно, специалисту необходимо найти и устранить ее причину.
На поиск таких причин часто уходят недели, но в системе подачи заявлений самый длительный срок, отведенный на рассмотрение заявлений, составляет 3 дня.
Конечно, здесь еще есть что дорабатывать и улучшать, но я считаю, что гораздо правильнее сосредоточить свое внимание не на улучшении качества записи запросов пользователей, а на том, чтобы у пользователей не было повода обращаться в техподдержку.
Правда, опыт показал, что по мере улучшения качества информационных систем в компаниях количество обращений в техподдержку не меняется, а меняется лишь характер обращений и сопровождающий их эмоциональный фон.
Но это совсем другая история.
Удачи! Иван Кормачев Компания «ИТ Департамент» www.depit.ru Теги: #Системное администрирование #itil #ITSM #Service Desk #управление качеством #управление проектами #системное администрирование #управление проектами
-
Обзор Moto Z Play: Младший Брат Флагмана
19 Oct, 24 -
Иллюзия
19 Oct, 24
