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

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

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

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

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

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

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

В ITIL 4 риск определяется как возможное событие, которое может причинить вред или убытки, или затруднить достижение целей. Также риск может определяться как неопределенность результата и может использоваться в контексте измерения вероятности наступления как положительных, так и отрицательных результатов. Это более широкое определение учитывает не только потенциальные негативные последствия, но и неопределенность в достижении целей.

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

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