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

Показатель результативности процессов отражает фактическую пользу, которую процессы приносят организации. Он измеряется по шкале от 0 до 100%, что позволяет количественно оценить эффективность процессов в выполнении своих задач для бизнеса. Расчёт таких показателей для основных процессов ITSM (IT Service Management) включает специальные наборы KPI и методологию формирования сбалансированных карт показателей. Результативность определяет, насколько хорошо процессы удовлетворяют потребности бизнеса и обеспечивают ожидаемую ценность.

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

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

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

Типовые процессы тесно связаны с методологией ITIL, особенно с ITIL версии 2, где большое внимание уделялось именно типовым моделям процессов. Книги ITIL содержат описания стандартных процессов управления ИТ-услугами, которые могут быть использованы в качестве основы для создания моделей процессов в организации. Однако важно понимать, что наличие типовых процессов из ITIL не гарантирует успешного внедрения и достижения результата. Типовые процессы ITIL требуют адаптации к конкретной компании, её структуре и особенностям работы. Например, процесс управления изменениями из ITIL может не учитывать необходимость стандартизации изменений, которая должна быть разработана отдельно, или может быть непригоден для управления изменениями в территориально распределенной компании без дополнительной адаптации.

На основе анализа дерева отказов можно точно определить, какая конфигурационная единица (КЕ) влияет на какую функциональность услуги. Поскольку дерево наглядно показывает, какие КЕ и в какой комбинации приводят к отказу конкретной функции, становится возможным оценить критичность времени восстановления каждой КЕ. Например, если отказ определенной КЕ ведет к полной недоступности критически важной функции через оператор «ИЛИ», это означает, что для этой КЕ требуется минимальное RTO. Если же КЕ влияет на функцию только в комбинации с другими отказами через оператор «И», то RTO для такой КЕ может быть более мягким. Таким образом, FTA позволяет связать архитектурную модель с показателями непрерывности, а не устанавливать RTO/RPO на основе общих рекомендаций или произвольных решений.

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

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

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