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

RFC может появиться раньше Change proposal в случае, когда бизнес-заказчик обращается с запросом через непрямые каналы (например, через службу поддержки), и выделенный ИТ-представитель (BRM) должен определить, насколько запрос значим. Однако для крупных изменений BRM будет инициировать создание Change proposal, тогда как операционные мелкие запросы обрабатываются через RFC без подготовки стратегического документа.

Выбор модели зависит от требований к гибкости, сложности системы и необходимости аудита. Например, в простых системах с чёткими ролями достаточно RBAC, тогда как в динамичных средах (многофилиальные компании) гибридная модель с ABAC обеспечит точный контроль. Неверный выбор может привести к избыточной сложности (чистый ABAC) или недостаточной адаптивности (только RBAC).

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

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

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

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

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

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

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