Как я качество работы техподдержки измерял

содержать штат диспетчеров, менеджеров и, непосредственно, специалистов технической поддержки

ITIL не про людей, ITIL про роли. В экстремуме в ИТ может быть один человек, исполняющий все роли всех процессов одновременно.

более правильным сосредоточить свое внимание не на повышении качества учета обращений пользователей, а на том, чтобы причин обращаться в техническую поддержку у пользователей не было

А вот это ключевое. Иногда в ITIL почему-то видят только ИТ-составляющую. Хотя там прямо говорят про цели всех процессов. И качество регистрации заявок просто один из критериев инцидентного процесса. А цели в ITIL — они всегда бизнес-ориентированы. У инцидентов — это скорейшее восстановление. У проблем — устранение корневых причин, и т.д. И если ты очень качественно регистрируешь инциденты, но очень долго их устраняешь, то ты занимаешься ерундой.

В период с 2011 по 2014 решал аналогичную задачу. Основная масса ошибок возникла из-за неправильных предпосылок относительно желаний сотрудников.
Предполагал, что если человек пришел работать сисадмином, то он хочет развития технического и, конечно, денег.
В процессе работы и общения с людьми осознал, что некоторым и то, и другое как бы нужно, но оно совершенно не в приоритете. В тот момент никак не мог в голове уместить тот факт, что кому-то может быть достаточно «навыков/знаний» и/или «доходов».

Пытался ввести подобную систему. Отчет в habrahabr.ru/post/306900

Вся суть статьи:
«Коллектив работает слаженно и продуктивно, и только начальство бегает туда-сюда с неактуальными вопросами и вносит элементы хаоса и беспредела, являясь причиной сбоев в хорошо отлаженной системе.»

"передаст его специалисту и будет… по большому счету не нужен ни пользователям, ни техническим специалистам"

И как пользователь и как технический специалист могу сказать, что весь этот ITIL и в самом деле придумал, нет — «понавнедрял» на просторах нашей Родины только настоящий передаст. Техподдержки везде сплошь и рядом стали дубовыми. Аналогично и с обратной стороны: безумные и никому ненужные задания.

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

Судя по описанному, она фактически отсутствует. А «опросы удовлетворённости клиентов» в малом бизнесе будут работать?

Вместо висяков (по типу замены вентилятора) делается плановая работа самими IT-шниками на ту дату, когда собственно будет происходить замена. Заявка закрывается с указанием, что будет выполнена работа в согласованное и запланированное время.

Странно что для всего используется «заявка» (в терминах ITIL incident?). У нас в конторе в поддержке используют:
— incident — у пользователя что-то не работает
— request — все работает, но пользователю надо помочь (поменять пароль, дать доступ)
— problem — порождается повторяющимися incidents, обычно изза бага в коде
— change — когда принимается решение пофиксить problem
— project — для небольших улучшений и изменений в коде
Для всех этих типов заявок разные SLA, по висякам — совещание каждую неделю. Так как получаемые нами по контракту деньги зависят от висяков, в системе имеется возможность останавливать таймер в случае если мы вынуждены ждать.
Как-то так…
А цель всей нашей ИТ — сокращать внеплановую работу (инциденты), и переводить ее в плановую.

Ну, то, что Вы не вынесли из ITIL про роли уже написали.
Есть и ещё момент — ITIL он (кроме прочего) про эффективность и оправданность.
Можно быть сколько угодно клиентоориентированным, но если у вас пользователь какого-то бесплатного пакета будет выносить мозг архитектору или переписываться лично с CIO/CTO — всё загнётся. Потому как пользователей обычно сильно больше. Именно поэтому нужно правильно единого окна.
Также всё это городится для того, чтобы всё решать на как можно низшем уровне. Время решения инцидента, допустим, 10 минут на первой линии и 5 минут на второй. Но при условии, что цена специалиста второй линии в 3 раза дороже — ситуация несколько иная. А мега-кодер может в случае отвлечения в неудачный момент и нах послать (образно).

Вы правы по сути лишь в одном — городить полноценный ITIL-like support (замечу, что вообще-то библиотека отнюдь не ограничивается саппортом), когда у вас 5-7 работников, что сидят одновременно в одном помещении — не нужно. Есть исключения, но обычно это так.

Стиль изложения понравился -позитивно. Методичность реализация не понравилась. Это на уровне ощущений. Теперь по порядку.

❶ Про мотивацию, цитата: «…медленно, но верно движемся к разработке системы поощрения и мотивации…»
Вы заблуждаетесь. Вы пытались реализовать не мотивацию, а стимуляцию, причём в большей степени материальную внешнюю, поскольку стимуляция входит в состав мотивации (партитивная связь).

→ Геройство одного работника, есть результат, как бы это выразиться полит корректно, промаха другого работника. Другими словами, если желаете создавать систему мотивации, то учитывайте каждую её составляющую: положительная/отрицательная, внешняя/внутренняя, материальная/духовная. Учитывая тот факт, что в статье не указано выполнение анализа предшествующего созданию системы – реализовывали субъективно, опираясь на мнения, а не знания. Аналитическую записку не писали? Так?

Выражаясь обывательски, стимулировать хорошо ослика, а человека нужно мотивировать…

❷ Про цель, цитата: «Цель системы мотивации для компании – повышение внутренней эффективности. Цель системы мотивации для каждого из вас – получить возможность объективной оценки своего вклада …»
У одной системы не может быть две цели, исходя их понятий «система» и «цель», тем более, разнонаправленные.
Заявленная Вами цель не соответствует подлинной цели системы мотивации, исходя её определения и назначения.

Оценка вклада выполняется в системе оценки персонала. В совокупности, это система оценки и мотивации персонала.
Кстати, исходя из контекста, объективной оценки у Вас не может быть, поскольку не формализовано описание должностей/ролей (зависит от реализуемых методов планирования и организации). Это как минимум. Ещё нужны модели мотивации. Мониторинг состояния. Формализованная постановка задач, а не по понятиям. => выдаёте желаемое за действительное.

Пример: работник занимал должность Х и развивался, в результате чего его компетентность начала превышать требования к должности. Премии за превышение? Логично? Работник переведён на более сложную, с т.з. сферы деятельности, должность Y – недостаток компетентности. Вполне возможно? При всех прочих равных условиях. Это интенсивный метод. Есть ещё экстенсивный…

❸ Про объективность, цитата: «технической поддержки с системой заявок меня устраивает и, что не менее важно, система мотивации по работе с системой заявок устраивает самих специалистов. Конечно, есть еще, что полировать и улучшать…»
Ещё одно подтверждение отсутствия у Вас объективной оценки. Вы создали себе иллюзию реализованной системы оценки и мотивации персонала, причина которой является опора на мнение, т.е. полноценный субъективизм выдаваемый за объективность. Осмыслите контекст Вашего предложения — «меня устраивает», «специалистов устраивает». И другой вариант – верифицируется соответствие знаний присущих работнику и требований предъявленных должности, с фактическим результатом работы. Различия осознаём? Где ощущения, а где обоснование?

И ещё: бизнес-инцидент и инфраструктурный-инцидент не одно и тоже (если с позиции ценностей ITIL). Это про, цитата: «Соответственно, заявка висит в ожидании удобного момента для проведения работ…». Другими словами, рассматривая связь система-подсистема.

█ На последок, цитата: «Правда, опыт показал, что с повышением качества работы информационных систем в компаниях, число обращений в техподдержку не меняется…». 1) ИС есть техническое обеспечение 2) Вы пишите про обращения пользователей => Качество тех.системы будет совокупность характеристик относящихся к способности удовлетворить установленные и предполагаемые потребности пользователей. Пользователь может обратиться в случае снижения качества услуги. А Вы не думали, что пользователь может обратиться из-за низкого уровня собственной готовности, а не снижения готовности ИС, т.е. рассматривать обращение с т.з. доступности объект-субъект? При прочих равных условиях, повышение качества работу ИС приведёт к снижению количества обращений в этой ИС. Кстати, методически верно рассматривать АС, а не ИС, поскольку АС включает и кадровое обеспечение, а Вы, исключая кадровое, делаете ошибочные умозаключения.

Деятельность работника может характеризоваться:

1. низкой результативностью, но высокой эффективностью – подметать пол зубной щёткой (что дали тем и работает, и это не вина работника).
2. высокой результативностью, но низкой эффективностью – (сами сформулируйте пример).

Формировать измерения деятельности следует исходя из minimum/optimum/maximum и соотносить к ним fact. Почему превышения максимума негативно, понятно? Как это связано с методами интенсивного и экстенсивного производства, понятно?

Информация должна быть представлена в виде формализованного (аналитик, руководитель) и обобщённого (упрощённого) контекста (рядовые работники).

Название статьи не соответствует контексту. См. хотя бы «как». Цитата «измерять различные метрики» => откройте определение термина «метрика». Сопоставьте с фразой. Что получается? Вам нужны показатели деятельности. Параметры, измерения, величины. Отчётность (первичная, сводная)… Не используйте словоблудие из маркетинговых статеек.

Осторожно: Выше описанное будет мешать продуцированию квази-деятельности.

PS: На надо уподобляться работникам вида «Моё мнение объективно, потому что верно, т.к. я руководитель».

Тут очень много всего написано и в посте и в комметариях. Но что-то нигде не видно главного — а что было сделано, чтобы упростить сотрудникам ведение всех задач? Не знаю, как Вам, а я уже не раз сталкивался с тем, что если нововведение не работает — основная причина в том, что оно усложняет жизнь.
Каждая система стремится к самобалансированию. Когда количество обращений равно N, а количество заявок в сервис-деске равно M и M очевидно меньше N, надо анализировать причину того, почему система дала дисбаланс и M стало меньше N. Стимулирование, мотивация — это громадный «костыль», которым многие пытаются подпереть криво настроенную и созданную систему, с которой никто не хочет работать. И это основные грабли, на которые натыкаются почти все.
Живой пример: на производстве была цепочка из 4х технологических операций. Первые две регистрировались двумя движениями. Для регистрации третьей операции необходимо было сделать около 5ти движений. Для регистрации четвертой — тоже два. Операторов чуть ли не угрозой лишения примий заставляли регистрировать всё как положено, тем не менее третью операцию мало кто пробивал, соответственно в системе учета продукция зависала там, где ей не положено было быть. Перенастроили сами цепочки, сделали ветвление в самом начале, в итоге получили три новых параллельных цепочки взамен одной старой, но по 3 операции (взамен четырех) с двумя действиями на каждой. Вуаля — проблемы нет.
Если брать ситуацию автора поста — банальным решением может стать учет количества входящих звонков оператору и количества открытх им писем и учет количества действий, произведенных по результатам обработки звонков и писем. Один звонок/одно открытое письмо — одно действие в сервис-деске (нажатие кнопки с описанием стандартного действия, ввод краткого описания действий, закрытие заявки либо какое-то другое действие). В конце дня — контроль чисел. Удержал N=M — молодец. Расхождение в 30% — повод руководителю заинтересоваться причиной.