Обучение важно для ITSM-проектов, так как они направлены на изменение поведения людей: как определяются цели, измеряется прогресс, устанавливаются приоритеты, организуется взаимодействие с клиентами и определяется ценность работы. Обучение помогает формировать знания и навыки сотрудников, что напрямую влияет на их поведение. Оно должно охватывать не только технические аспекты («как делать»), но и объяснять причины изменений («зачем» и «почему именно так»), что особенно важно для ИТ-специалистов как интеллектуальных работников.

Основными факторами определяющими возможность привлечения внешних специалистов в данных областях являются: специфичность и критичность задач для продукта, необходимость постоянного вовлечения, а также возможность стандартизации и автоматизации процессов. Для 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.

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

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

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

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

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

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