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

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

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

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

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

Стандарт INCITS 494-2012 представляет собой расширение основного стандарта INCITS 359-2012, разработанное для устранения критики 'чистого' RBAC за его негибкость в условиях изменчивого окружения. В то время как INCITS 359-2012 описывает базовую модель RBAC с её компонентами, INCITS 494-2012 расширяет возможности RBAC в части обработки динамических ограничений. Он позволяет внешним политикам и правилам создавать ограничения на уровне ядра RBAC, которые могут применяться к базовым множествам (пользователям, ролям, операциям, объектам и правам доступа). Стандарт 494-2012 вводит обработку не только разделения обязанностей, но и других типов ограничений, таких как время суток, местоположение и т.д.

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

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

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

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