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

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

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

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

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

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

Согласно ITIL, в управлении мощностями выделяются три подпроцесса: Business Capacity Management (управление бизнес-мощностями), Service Capacity Management (управление сервисной мощностью) и Resource Capacity Management (управление ресурсной мощностью). Первый подпроцесс связан с прогнозированием и управлением мощностью на уровне бизнеса, второй – на уровне предоставляемых ИТ-услуг, третий – на уровне физических и виртуальных ресурсов.

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

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

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