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

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

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

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

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

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

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

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

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

Для управления сложностью микросервисной архитектуры рекомендуется применять два ключевых процесса ITIL: управление проблемами и управление конфигурациями. Управление конфигурациями позволяет сохранять информацию о всех компонентах системы, их параметрах и зависимостях, что помогает поддерживать обзор всей архитектуры. Управление проблемами помогает анализировать и устранять корневые причины инцидентов, что особенно важно при диагностике сложных взаимодействий между микросервисами. Эти процессы позволяют сохранить систему в более детерминированном состоянии и избегать перехода в сложный (Complex) домен, где управление становится значительно труднее.