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

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

Outcome зависит от субъективного восприятия потребителя и часто выражается в нематериальных или долгосрочных эффектах, которые сложно зафиксировать количественно. В то время как Output обычно имеет чёткие количественные параметры (например, сроки доставки, объём функционала), что позволяет легко его измерять и отчитываться о нём. Для оценки Outcome необходимо собирать обратную связь, проводить опросы удовлетворённости или анализировать поведение клиентов.

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

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

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

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

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

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

При изменении бизнес-процессов: 1) Анализировать поддерживаемые системы на предмет появления новых объектов или операций, требующих добавления/изменения системных ролей. 2) Связывать новые роли с исполнителями (должностями или подразделениями), так как сами исполнители могут измениться. Например, если внедряется новый этап в цепочке согласования документов, необходимо создать роль 'Согласующий по новому направлению' и закрепить её за соответствующими сотрудниками. Акцент делается не на соответствие старых и новых ролей, а на актуализацию распределения прав в рамках изменённых процессов.