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

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

Цели процесса в ITIL должны соответствовать принципу SMART: - Конкретность и измеримость: формулировка включает метрику (например, "увеличить долю своевременно решённых инцидентов до 95%"). - Привязка к срокам: цель ставится на конкретный период (месяц, квартал). - Глаголы совершенного вида (дождусь, достигну, обеспечу). Цели не фиксируются в регламенте процесса, так как они часто пересматриваются, а учитываются в планах управления или картах показателей. Ответственность за определение и актуализацию целей лежит на владельце процесса. Цели должны быть чётко связаны с бизнес-требованиями и обоснованием проекта.

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

Для управления рисками в области IT существуют различные методы и стандарты, такие как CRAMM, COSO ERM, ISO 27005, OCTAVE и MEHARI. Все эти методики описывают известный цикл управления рисками, состоящий из этапов: определение охвата, идентификация, анализ, оценка, реагирование и контроль. Этот цикл официально закреплен в стандарте ISO 31000 с 2009 года. Каждая методика предлагает свой подход к формулированию рисков. Например, ITSM-специалисты часто используют модель «актив-угроза-уязвимость», в то время как PMBOK рекомендует структуру «причина-событие-последствие». ISACA в своих публикациях, начиная с RiskIT и в частности в COBIT 5 for Risk, предлагает концепцию сценария риска, включающего источник угрозы, тип угрозы, событие, связанные активы и временной аспект.

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

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

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

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

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