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

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

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

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

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

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

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

В области профессионального управления аутсорсингом существуют различные программы сертификации. Одной из наиболее известных является сертификация «Certified Outsourcing Professional» (COP), предлагаемая Международной ассоциацией профессионалов в области аутсорсинга (IAOP). IAOP также предлагает сертификации разного уровня, основанные на их своде знаний OPBOK. Дополнительно, в области управления услугами при работе с несколькими поставщиками существует сертификация, связанная с методологией SIAM. Эти сертификации подтверждают знание лучших практик, стандартов и методологий в управлении аутсорсингом и повышают профессиональную квалификацию специалистов в этой области.

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

С 2016 года команда разрабатывала курс "Основы DevOps", а с 2017 года начали его проведение. К концу 2017 года первая версия курса была полностью переработана, что позволило улучшить структуру и содержание программы. Это было связано с тем, что DevOps была относительно новой темой для команды и требовалось лучше понять, насколько она релевантна целевой аудитории.