В управлении доступностью (AVA) основными показателями выступают: - MTRS (среднее время восстановления услуги) - MTBF (среднее время между сбоями) - MTBSI (среднее время между инцидентами) Эти показатели связаны со статистикой и тенденциями сбоев в работе ИТ-систем. В управлении непрерывностью (CONT) используются: - RTO (recovery time objective) — целевое время восстановления - RPO (recovery point objective) — целевая точка восстановления RTO показывает, за какое время после сбоя должно быть возобновлено предоставление услуги, а RPO указывает, какой период данных может быть потерян без критического ущерба для бизнеса.

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

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

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

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

Для корректного учёта параллельных задач важно фиксировать начало и окончание совокупности действий, а затем оценивать реальное распределение времени между ними. Например, если сотрудник ведёт телефонный разговор и составляет документ, общее время разбивается на доли (изначально 50/50), после чего уточняется на основе личного наблюдения. Это позволяет избежать завышенных оценок и получить реалистичную статистику. Ключевой момент — отказ от восприятия одновременной работы над несколькими задачами как полного выполнения каждой из них за отведённое время.

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

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

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

Чтобы определить, является ли предложение услугой в контексте ITIL4, следует задать следующие вопросы: 1) Какие риски и затраты клиент перекладывает на поставщика при использовании этого предложения? 2) Что является конечной ценностью для клиента, и как предложение помогает ее достичь? 3) Какие ресурсы включает в себя предложение, и как они доступны клиенту? 4) Какие сервисные операции выполняет поставщик для поддержания работы предложения? 5) Если бы клиент сам решал эти задачи, какие усилия и риски на него бы легли? Если при ответе на эти вопросы становится ясно, что клиент перекладывает на поставщика значимые риски и затраты, то предложение соответствует определению услуги в ITIL4. Например, простая продажа шоколадки не является услугой, так как клиент не перекладывает никаких рисков, но при регулярной доставке клиент перекладывает на поставщика ответственность за своевременность и качество поставок.