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

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

MTPD (Maximum Tolerable Period of Disruption) - это максимально допустимый период простоя бизнес-процесса, после которого ущерб становится неприемлемым. MTPD используется как отправная точка для определения требований к ИТ-услугам. При управлении доступностью MTPD бизнес-процесса сравнивается с RTO ИТ-услуг, которые поддерживают этот процесс. Если RTO превышает MTPD, необходимо принимать дополнительные меры для сокращения времени восстановления ИТ-услуг. MTPD является критическим параметром при разработке планов непрерывности, так как определяет, насколько быстро необходимо восстановить ИТ-услуги для предотвращения критического воздействия на бизнес.

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

Структура сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (Actor), который определяется как внутренний или внешний; тип угрозы (Threat Type), такой как злоумышленные действия, ошибки или природные катаклизмы; событие (Event), включающее раскрытие информации, модификацию, кражу или уничтожение; связанные активы (Asset/Resource), относящиеся к людям, организационным структурам, процессам и ИТ-инфраструктуре; и временной аспект (Time), учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от времени суток или календарного периода.

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

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

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

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

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