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

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

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

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

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

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

Основными факторами определяющими возможность привлечения внешних специалистов в данных областях являются: специфичность и критичность задач для продукта, необходимость постоянного вовлечения, а также возможность стандартизации и автоматизации процессов. Для Compliance и Security, которые требуют глубокой экспертизы и тесной интеграции с текущими процессами, внешние специалисты могут быть эффективны только при наличии четких SLA и понимания требований. В случае с UX, если продукт не требует постоянного взаимодействия с пользовательским интерфейсом, можно воспользоваться услугами фрилансеров или узко-специализированных компаний для отдельных проектов. Что касается CI/CD, автоматизированные процессы и использование облачных сервисов позволяют минимизировать прямое участие разработчиков, но требуют от команды базовой компетенции в настройке и поддержании pipeline.

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

Публикация Risk Scenarios Using COBIT 5 for Risk существенно расширяет возможности COBIT 5 for Risk, предоставляя подробное описание ранее заявленных сценариев рисков в соответствии с шаблоном профиля риска (Risk Profile). Включает в себя конкретные примеры реализации рисков в организациях, детальное описание каждого из пяти компонентов структуры сценария, анализ влияния на три ключевые области (получение ценности от ИТ, выполнение программ и проектов, эксплуатация ИТ-услуг), указание применимых стратегий реагирования и применение семи факторов влияния для снижения рисков с оценкой их эффективности. Документ содержит почти двести страниц детального анализа, что делает его самым подробным и актуальным описанием типовых ИТ-рисков от ISACA.

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