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

В Lean-подходе Lead Time — это время от момента поступления запроса до его выполнения, то есть общий период, который заказчик ожидает результата. Process Time (также называемое Touch Time или Task Time) — это время, когда непосредственно осуществляется работа над запросом, без учета времени ожидания в очередях. Основная разница в том, что Lead Time учитывает все задержки и время ожидания, тогда как Process Time фокусируется только на активной работе. Поскольку именно Lead Time определяет восприятие скорости выполнения работы заказчиком, оптимизация обычно направлена на сокращение именно этого показателя, а не Process Time. Однако отношение Process Time к Lead Time служит важным индикатором общей эффективности потока.

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

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

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

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

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

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

Девять принципов ITIL Practitioner Guidance 2016 года трансформировались в семь принципов ITIL 4 2019 года следующим образом: два идентичных принципа остались без изменений ("Фокусируйтесь на ценности" и "Отталкивайтесь от текущей ситуации"); два принципа были объединены ("Сотрудничайте" и "Будьте прозрачны" стали одним - "Сотрудничайте и поощряйте прозрачность"); три принципа получили незначительные изменения формулировок ("Действуйте итерационно" стало "Действуйте итерационно, используя обратную связь", "Упрощайте" превратилось в "Простота и практичность", "Используйте целостный подход" получил дополнение "Think and work holistically"); один принцип ("Проектируйте, ориентируясь на потребительский опыт использования") был интегрирован в более общий принцип "Фокусируйтесь на ценности"; элементы другого принципа ("Приоритет прямого наблюдения") нашли отражение в рекомендациях по применению принципа "Отталкивайтесь от текущей ситуации"; и был добавлен новый принцип "Оптимизируйте и автоматизируйте".

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