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

После выявления «известной ошибки» она документируется в специальной базе данных известных ошибок (KEDB - Known Error Database). В запись об ошибке включается информация о корневой причине, описании проблемы, временном обходном решении (workaround), а также данные о влиянии на бизнес и истории связанных с ней инцидентов. Эта информация используется при возникновении аналогичных инцидентов для быстрого применения известного обходного решения. Запись поддерживается в актуальном состоянии и обновляется по мере получения новых данных или поиска постоянного решения проблемы.

Если в процессе не используется понятие 'переоткрытый инцидент', показатель First Time Resolution (FTR) можно получить, анализируя долю инцидентов, с которыми связаны более поздние инциденты, при условии, что система автоматизации процесса управления инцидентами позволяет связывать инциденты друг с другом. Если связь инцидентов используется и для других целей, анализ может стать несколько сложнее, но остается возможным. Также можно формировать полную систему оценки, в которой FTR не учитывается отдельно, поскольку переоткрытые инциденты влияют на другие показатели, например TCR (Ticket Closure Rate).

Негативные последствия фокуса только на выходах: снижение качества услуг, когда, например, сервис-деск сокращает время звонка (выход), но не решает фактических проблем клиентов, что приводит к росту жалоб в регулирующие органы; потраченные впустую ресурсы на технические реализации, которые не приносят бизнес-ценности (как внедрение крутого API без интеграции с CRM); ухудшение репутации компании и финансовые потери, как в случае с дискаунтером «Светофор», где фокус на количестве магазинов привел к серьезным нарушениям и закрытию точек; утрата доверия бизнеса к ИТ-отделу из-за отсутствия вклада в достижение стратегических целей.

При множественных возвратах одного инцидента в разные группы каждый возврат должен учитываться отдельно для соответствующей группы. Например, если инцидент дважды возвращался на доработку — сначала в группу А, затем в группу В, то оба возврата учитываются в Sj для каждой из этих групп. Это гарантирует, что снижение метрики FTR происходит только у тех групп, которые допустили ошибки, и предотвращает искажение результатов из-за совместного учёта всех возвратов на уровне всего инцидента.

Cj и Sj связаны между собой через операнд Nj, который определяется как сумма этих величин: Nj = Cj + Sj. Здесь Cj — количество обращений, обработанных j-той группой и закрытых без рекламаций, а Sj — количество возвратов на доработку в эту группу. Эти два показателя вместе формируют полную картину обработанных обращений, участвующих в расчёте метрики First Time Resolution (FTR), и позволяют корректно отразить качество работы группы.

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

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

Управление уровнем услуг (Service Level Management, SLM) играет ключевую роль при согласовании срочных изменений, обеспечивая коммуникацию между ИТ-организацией и бизнес-заказчиком. SLM отвечает за обсуждение и согласование целевых показателей доступности на период внедрения изменений, а также за обновление сервисных соглашений при необходимости временной корректировки целевых показателей. SLM обеспечивает прозрачность и осознанность бизнеса относительно последствий срочных изменений, фиксирует согласованные условия и помогает поддерживать доверительные отношения между ИТ и бизнесом в условиях необходимости оперативного реагирования на меняющиеся требования.

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