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

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

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

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

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

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

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

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

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

В ITIL4 Foundation отсутствует детальное описание ролей, участвующих в практиках, поскольку ITIL4 представляет собой более гибкий и принципиально иной подход по сравнению с ITIL V3. Вместо фиксированных ролей и процессов ITIL4 фокусируется на практиках, которые могут быть адаптированы под конкретные потребности организации. Полное описание ролей и ответственностей в ITIL4, вероятно, содержится в более углубленных модулях или материалах, выходящих за рамки базового уровня Foundation. В статье упоминается, что следует ждать более подробного описания в соответствующих модулях ITIL4.