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

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

Основные проблемы классификации включают неоднозначность определения границ между инцидентом и сервисным запросом, что приводит к дискуссиям на тему "А замена картриджа принтера? А сброс забытого пароля?". Эта неоднозначность не только создает сложности для теоретиков, но и затрудняет работу специалистов на практике. Кроме того, если эти типы обращений относятся к разным процессам управления (и, возможно, к разным менеджерам), вопрос классификации превращается в вопрос ответственности: "кто за это отвечает". Это создает организационные трения и может негативно сказаться на эффективности процесса.

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

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

С 1 января 2014 года в систему учета рабочего времени были внесены следующие изменения: добавлено отнесение времени к 18 специфическим категориям вместо предыдущих трех цветовых категорий, начал вестись полный листинг затраченного времени вместо сводной таблицы. Учет попрежнему велся в режиме реального времени — сразу после завершения одной задачи и перед началом следующей.

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

Обращения, обрабатываемые между различными часовыми поясами, могут занимать больше времени из-за различий в рабочих графиках. Например, когда пользователь из Владивостока обращается в поддержку утром, специалисты в Москве могут еще не начать работать, что приводит к простою в расчете рабочего времени. Даже если фактическое время обработки составит 4 часа, эти часы распределены между разными днями и часовых поясами, из-за чего пользователь получит решение только на следующий день. Такие задержки возникают из-за несогласованности рабочих периодов между регионами, когда работа одной группы завершается до начала работы другой.

Чтобы определить, является ли сбой RAID-массива инцидентом, нужно учитывать конкретную конфигурацию и условия, при которых массив считается работающим нормально. Например, в RAID 1+0 выход из строя одного диска в зеркале не считается инцидентом, если это не влияет на функциональность массива и его отказоустойчивость остается в допустимых пределах. Однако выход из строя второго диска в том же зеркале может привести к потере надежности и уже будет инцидентом. Важно определить, какие состояния являются нормальными для конкретной системы на основе технических спецификаций, и только после этого принимать решение о классификации происшествия.

Данные из кадровых систем могут быть ненадежными из-за задержек обновления информации, например, фактическое перемещение сотрудника может отражаться в системе с задержкой до месяца. Также возможны неточности, такие как опечатки в адресах или нестандартные сокращения в должностях, что делает данные менее подходящими для автоматической обработки при определении уровня ИТ-услуг.